idnits 2.17.1 draft-mirsky-sfc-pmamm-09.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 20, 2019) is 1589 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: June 22, 2020 Huawei Technologies 6 T. Mizrahi 7 Huawei Network.IO Innovation Lab 8 December 20, 2019 10 Performance Measurement (PM) with Alternate Marking Method in Service 11 Function Chaining (SFC) Domain 12 draft-mirsky-sfc-pmamm-09 14 Abstract 16 This document describes how the alternate marking method can be used 17 as the efficient performance measurement method taking advantage of 18 the actual data flows in a Service Function 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 June 22, 2020. 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 . . . . . . . . . . . . . . . . . . . . . . . 8 74 1. Introduction 76 [RFC7665] introduced the architecture of a Service Function Chain 77 (SFC) in the network and defined its components as classifier, 78 Service Function Forwarder (SFF), and Service Function (SF). 79 [RFC8321] describes the hybrid performance measurement method, which 80 can be used to measure packet loss, latency, and jitter on live 81 traffic. Because this method is based on marking consecutive batches 82 of 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 |U|U|U|U|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 be set to 0 at initialization of NSH and ignored on the 130 receipt when the method is not in use. The Mark field MUST NOT be 131 used in defining forwarding and/or quality of service treatment of an 132 SFC packet. The Mark field MUST be used only for the performance 133 measurement of data traffic in the SFC layer. Though the setting of 134 the field to any value likely not affect forwarding and/or quality of 135 service treatment of a packet, the alternate marking method in SFC 136 layer is characterized as an example of a hybrid performance 137 measurement method according to [RFC7799]. 139 4. Theory of Operation 141 The marking method can be successfully used in the SFC. Without 142 limiting any generality consider SFC presented in Figure 2. Any 143 combination of markings, Loss and/or Delay, can be applied to a 144 service flow by any component of the SFC at either ingress or egress 145 point to perform node, link, segment or end-to-end measurement to 146 detect performance degradation defect and localize it efficiently. 148 +---+ +---+ +---+ +---+ +---+ +---+ 149 |SF1| |SF2| |SF3| |SF4| |SF5| |SF6| 150 +---+ +---+ +---+ +---+ +---+ +---+ 151 \ / \ / \ / 152 +----------+ +----+ +----+ +----+ 153 |Classifier|---|SFF1|---------|SFF2|---------|SFF3| 154 +----------+ +----+ +----+ +----+ 156 Figure 2: SFC network 158 Using the marking method, a component of the SFC creates distinct 159 sub-flows in the particular service traffic over SFC. Each sub-flow 160 consists of consecutive blocks that are unambiguously recognizable by 161 a monitoring point at any component of the SFC and can be measured to 162 calculate packet loss and/or packet delay metrics. 164 4.1. Single Mark Enabled Measurement 166 As explained in the [RFC8321], marking can be applied to delineate 167 blocks of packets based either on the equal number of packets in a 168 block or based on the same time interval. The latter method offers 169 better control as it allows a better account for capabilities of 170 downstream nodes to report statistics related to batches of packets 171 and, at the same time, time resolution that affects defect detection 172 interval. 174 The Loss flag is used to create distinctive flows to measure the 175 packet loss by switching the value of the Loss flag every N-th packet 176 or at specified time intervals. Delay metrics MAY be calculated with 177 the alternate flow using any of the following methods: 179 o First/Last Packet Delay calculation: whenever the marking, i.e., 180 the value of Loss flag changes a component of the SFC can store 181 the timestamp of the first/last packet of the block. The 182 timestamp can be compared with the timestamp of the packet that 183 arrived in the same order through a monitoring point at a 184 downstream component of the SFC to compute packet delay. Because 185 timestamps collected based on the order of arrival, this method is 186 sensitive to packet loss and re-ordering of packets 188 o Average Packet Delay calculation: an average delay is calculated 189 by considering the average arrival time of the packets within a 190 single block. A component of the SFC may collect timestamps for 191 each packet received within a single block. Average of the 192 timestamp is the sum of all the timestamps divided by the total 193 number of packets received. Then the difference between averages 194 calculated at two monitoring points is the average packet delay on 195 that segment. This method is robust to out of order packets and 196 also to packet loss (only a small error is introduced). This 197 method only provides a single metric for the duration of the 198 block, and it doesn't give the minimum and maximum delay values. 199 Highly optimized implementation of the method can reduce the 200 duration of the block and thus overcome the limitation. 202 4.2. Double Mark Enabled Measurement 204 Double Mark method allows measurement of minimum and maximum delays 205 for the monitored flow, but it requires more nodal and network 206 resources. If the Double Mark method used, then the Loss flag MUST 207 be used to create the alternate flow, i.e., mark more substantia 208 batches of packets. The Delay flag MUST be used to denote single 209 packets to measure delay jitter. 211 The first marking (Loss flag alternation) is needed for packet loss 212 and also for average delay measurement. The second marking (Delay 213 flag is put to one) creates a new set of marked packets that are 214 fully identified over the SFC, so that a component can store the 215 timestamps of these packets; these timestamps can be compared with 216 the timestamps of the same packets on another element of the SFC to 217 compute packet delay values for each packet. The number of 218 measurements can be easily increased by changing the frequency of the 219 second marking. But the rate of the second marking must be not too 220 high to avoid out of order issues. This method supports the 221 calculation of not only the average delay but also the minimum and 222 maximum delay values and, in broader terms, to know more about the 223 statistic distribution of delay values. 225 4.3. Multiplexed Mark Enabled Measurement 227 There is also a scheme that provides the benefits of Double Mark 228 method, but uses only one bit like Single Mark. This methodology is 229 described in [I-D.mizrahi-ippm-compact-alternate-marking]. The 230 concept is that in the middle of each block of packets with a certain 231 value of the L flag, a single packet has the L flag inverted. So, by 232 examining the stream, the packets with the inverted bit can be easily 233 identified and employed for delay measurement. This Alternate 234 Marking variation is advantageous because it requires only one bit 235 from each packet, and such bits are always in short supply. 237 4.4. Residence Time Measurement with the Alternate Marking Method 239 Residence time is the variable part of the propagation delay that a 240 packet experiences while traversing a network, e.g., SFC. Residence 241 Time over an SFC is the sum of the nodal residence times, i.e., 242 periods that the packet spent in each of SFFs that compose the SFC. 243 The nodal residence time in SFC itself is the sum of sub-nodal 244 residence times that the packet spent in each of SFs that are part of 245 the given SFC and are mapped to the SFF. The residence time and 246 deviation of the residence time metrics may include any combination 247 of minimum, maximum, values over measurement period, as well as mean, 248 median, percentile. These metrics may be used to evaluate the 249 performance of the SFC and its elements before and during its 250 operation. 252 Use of the specially marked packets simplifies residence time 253 measurement and correlation of the measured metrics over the SFC end- 254 to-end. For example, the alternate marking method may be used as 255 described in Section 4.2 to identify packets in the data flow to be 256 used to measure the residence time. The nodal and sub-nodal 257 residence time metrics can be locally calculated and then collected 258 using either in-band or out-band OAM mechanisms. 260 5. IANA Considerations 262 5.1. Mark Field in NSH Base Header 264 This document requests IANA to allocate the one-bit field from NSH 265 Base Header Bits [RFC8300] as the Mark field of NSH as the following: 267 +--------------+-------------+---------------+ 268 | Bit Position | Description | Reference | 269 +--------------+-------------+---------------+ 270 | TBA | Mark field | This document | 271 +--------------+-------------+---------------+ 273 Table 1: Mark field of SFC NSH 275 6. Security Considerations 277 This document lists the OAM requirement for SFC domain and does not 278 raise any security concerns or issues in addition to ones common to 279 networking and SFC. 281 7. Acknowledgment 283 TBD 285 8. References 287 8.1. Normative References 289 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 290 Requirement Levels", BCP 14, RFC 2119, 291 DOI 10.17487/RFC2119, March 1997, 292 . 294 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 295 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 296 May 2017, . 298 [RFC8300] Quinn, P., Ed., Elzur, U., Ed., and C. Pignataro, Ed., 299 "Network Service Header (NSH)", RFC 8300, 300 DOI 10.17487/RFC8300, January 2018, 301 . 303 8.2. Informative References 305 [I-D.mizrahi-ippm-compact-alternate-marking] 306 Mizrahi, T., Arad, C., Fioccola, G., Cociglio, M., Chen, 307 M., Zheng, L., and G. Mirsky, "Compact Alternate Marking 308 Methods for Passive and Hybrid Performance Monitoring", 309 draft-mizrahi-ippm-compact-alternate-marking-05 (work in 310 progress), July 2019. 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 [RFC7799] Morton, A., "Active and Passive Metrics and Methods (with 318 Hybrid Types In-Between)", RFC 7799, DOI 10.17487/RFC7799, 319 May 2016, . 321 [RFC8321] Fioccola, G., Ed., Capello, A., Cociglio, M., Castaldelli, 322 L., Chen, M., Zheng, L., Mirsky, G., and T. Mizrahi, 323 "Alternate-Marking Method for Passive and Hybrid 324 Performance Monitoring", RFC 8321, DOI 10.17487/RFC8321, 325 January 2018, . 327 Authors' Addresses 329 Greg Mirsky 330 ZTE Corp. 332 Email: gregimirsky@gmail.com 334 Giuseppe Fioccola 335 Huawei Technologies 337 Email: giuseppe.fioccola@huawei.com 339 Tal Mizrahi 340 Huawei Network.IO Innovation Lab 341 Israel 343 Email: tal.mizrahi.phd@gmail.com