idnits 2.17.1 draft-mirsky-sfc-pmamm-02.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 (September 12, 2017) is 2410 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 (-28) exists of draft-ietf-sfc-nsh-20 == Outdated reference: A later version (-14) exists of draft-ietf-ippm-alt-mark-10 Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). 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: March 16, 2018 Telecom Italia 6 T. Mizrahi 7 Marvell 8 September 12, 2017 10 Performance Measurement (PM) with Alternate Marking Method in Service 11 Function Chaining (SFC) Domain 12 draft-mirsky-sfc-pmamm-02 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 March 16, 2018. 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 (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. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 7 68 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 69 8.1. Normative References . . . . . . . . . . . . . . . . . . 7 70 8.2. Informative References . . . . . . . . . . . . . . . . . 7 71 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 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). 78 [I-D.ietf-ippm-alt-mark] describes passive performance measurement 79 method, which can be used to measure packet loss, latency and jitter 80 on live traffic. Because this method is based on marking consecutive 81 batches of packets the method often referred as Alternate Marking 82 Method (AMM). 84 This document defines how the alternate marking method can be used to 85 measure packet loss and delay metrics of a service flow over e2e or 86 any segment of the SFC. 88 2. Conventions used in this document 90 2.1. Terminology 92 MM: Marking Method 94 OAM: Operations, Administration and Maintenance 96 SFC: Service Function Chain 97 SF: Service Function 99 SFF: Service Function Forwarder 101 SFP: Service Function Path 103 NSH: Network Service Header 105 2.2. Requirements Language 107 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 108 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 109 "OPTIONAL" in this document are to be interpreted as described in BCP 110 14 [RFC2119] [RFC8174] when, and only when, they appear in all 111 capitals, as shown here. 113 3. Mark Field in NSH Base Header 115 [I-D.ietf-sfc-nsh] defines format of the Network Service Header 116 (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|R| TTL | Length | M |R|R|MD Type| Proto | 122 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 124 Figure 1: NSH Base format 126 This document defines two bit long field, referred as Mark field (M 127 in Figure 1, as part of NSH Base and designated for the alternate 128 marking performance measurement method [I-D.ietf-ippm-alt-mark]. The 129 Mark field MUST NOT be used in defining forwarding and/or quality of 130 service treatment of a SFC packet. The Mark field MUST be used only 131 for the performance measurement of data traffic in SFC layer. 132 Because setting of the field to any value does not affect forwarding 133 and/or quality of service treatment of a packet, the alternate 134 marking method in SFC layer can be viewed as true example of passive 135 performance measurement method. 137 The Figure 2 displays format of the Mark field. 139 0 140 0 1 141 +-+-+-+-+ 142 | L | D | 143 +-+-+-+-+ 145 Figure 2: Mark field format 147 where: 149 o L- Loss flag; 151 o D - Delay flag. 153 4. Theory of Operation 155 The marking method can be successfully used in the SFC. Without 156 limiting any generality consider SFC presented in Figure 3. Any 157 combination of markings, Loss and/or Delay, can be applied to a 158 service flow by any component of the SFC at either ingress or egress 159 point to perform node, link, segment or end-to-end measurement to 160 detect performance degradation defect and localize it efficiently. 162 +---+ +---+ +---+ +---+ +---+ +---+ 163 |SF1| |SF2| |SF3| |SF4| |SF5| |SF6| 164 +---+ +---+ +---+ +---+ +---+ +---+ 165 \ / \ / \ / 166 +----------+ +----+ +----+ +----+ 167 |Classifier|---|SFF1|---------|SFF2|---------|SFF3| 168 +----------+ +----+ +----+ +----+ 170 Figure 3: SFC network 172 Using the marking method a component of the SFC creates distinct sub- 173 flows in the particular service traffic over SFC. Each sub-flow 174 consists of consecutive blocks that are unambiguously recognizable by 175 a monitoring point at any component of the SFC and can be measured to 176 calculate packet loss and/or packet delay metrics. 178 4.1. Single Mark Enabled Measurement 180 As explained in the [I-D.ietf-ippm-alt-mark], marking can be applied 181 to delineate blocks of packets based either on equal number of 182 packets in a block or based on equal time interval. The latter 183 method offers better control as it allows better account for 184 capabilities of downstream nodes to report statistics related to 185 batches of packets and, at the same time, time resolution that 186 affects defect detection interval. 188 If the Single Mark measurement used, then the Delay flag Figure 2 189 MUST be set to zero on transmit and ignored on reception by 190 monitoring point. 192 The Loss flag is used to create alternate flows to measure the packet 193 loss by switching value of the Loss flag every N-th packet or at 194 certain time intervals. Delay metrics MAY be calculated with the 195 alternate flow using any of the following methods: 197 o First/Last Packet Delay calculation: whenever the marking, i.e. 198 value of Loss flag, changes a component of the SFC can store the 199 timestamp of the first/last packet of the block. The timestamp 200 can be compared with the timestamp of the packet that arrived in 201 the same order through a monitoring point at downstream component 202 of the SFC to compute packet delay. Because timestamps collected 203 based on order of arrival this method is sensitive to packet loss 204 and re-ordering of packets 206 o Average Packet Delay calculation: an average delay is calculated 207 by considering the average arrival time of the packets within a 208 single block. A component of the SFC may collect timestamps for 209 each packet received within a single block. Average of the 210 timestamp is the sum of all the timestamps divided by the total 211 number of packets received. Then difference between averages 212 calculated at two monitoring points is the average packet delay on 213 that segment. This method is robust to out of order packets and 214 also to packet loss (only a small error is introduced). This 215 method only provides single metric for the duration of the block 216 and it doesn't give the minimum and maximum delay values. This 217 limitation could be overcome by reducing the duration of the block 218 by means of an highly optimized implementation of the method. 220 4.2. Double Mark Enabled Measurement 222 Double Mark method allows measurement of minimum and maximum delays 223 for the monitored flow but it requires more nodal and network 224 resources. If the Double Mark method used, then the Loss flag MUST 225 be used to create the alternate flow, i.e. mark larger batches of 226 packets. The Delay flag MUST be used to mark single packets to 227 measure delay jitter. 229 The first marking (Loss flag alternation) is needed for packet loss 230 and also for average delay measurement. The second marking (Delay 231 flag is put to one) creates a new set of marked packets that are 232 fully identified over the SFC, so that a component can store the 233 timestamps of these packets; these timestamps can be compared with 234 the timestamps of the same packets on another component of the SFC to 235 compute packet delay values for each packet. The number of 236 measurements can be easily increased by changing the frequency of the 237 second marking. But the frequency of the second marking must be not 238 too high in order to avoid out of order issues. This method is 239 useful to have not only the average delay but also the minimum and 240 maximum delay values and, in wider terms, to know more about the 241 statistic distribution of delay values. 243 4.3. Residence Time Measurement with the Alternate Marking Method 245 Residence time is the variable part of the propagation delay that a 246 packet experiences traversing a network, e.g. SFC. Residence Time 247 over an SFC is the sum of the nodal residence times, i.e. periods 248 that the packet spent in each of SFFs that compose the SFC. The 249 nodal residence time in SFC itself is the sum of sub-nodal residence 250 times that the packet spent in each of SFs that are part of the given 251 SFC and are mapped to the SFF. The residence time and deviation of 252 the residence time metrics may include any combination of minimum, 253 maximum, values over measurement period, as well as mean, median, 254 percentile. These metrics may be used to evaluate performance of the 255 SFC and its elements before and during its operation. 257 Use of the specially marked packets simplifies residence time 258 measurement and correlation of the measured metrics over the SFC end- 259 to-end. For example, the alternate marking method may be used as 260 described in Section 4.2 to identify packets in the data flow to be 261 used to measure the residence time. The nodal and sub-nodal 262 residence time metrics can be locally calculated and then collected 263 using either in-band or out-band OAM mechanisms. 265 5. IANA Considerations 267 5.1. Mark Field in NSH Base Header 269 This document requests IANA to allocate Mark field as two bits-long 270 field from NSH Base Header Reserved Bits [I-D.ietf-sfc-nsh]. 272 This document requests IANA to register values of the Mark field of 273 NSH as the following: 275 +--------------+---------+--------------------------+---------------+ 276 | Bit Position | Marking | Description | Reference | 277 +--------------+---------+--------------------------+---------------+ 278 | 0 | S | Single Mark Measurement | This document | 279 | 1 | D | Double Mark Measurement | This document | 280 +--------------+---------+--------------------------+---------------+ 282 Table 1: Mark field of SFC NSH 284 6. Security Considerations 286 This document lists the OAM requirement for SFC domain and does not 287 raise any security concerns or issues in addition to ones common to 288 networking and SFC. 290 7. Acknowledgement 292 TBD 294 8. References 296 8.1. Normative References 298 [I-D.ietf-sfc-nsh] 299 Quinn, P., Elzur, U., and C. Pignataro, "Network Service 300 Header (NSH)", draft-ietf-sfc-nsh-20 (work in progress), 301 September 2017. 303 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 304 Requirement Levels", BCP 14, RFC 2119, 305 DOI 10.17487/RFC2119, March 1997, 306 . 308 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 309 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 310 May 2017, . 312 8.2. Informative References 314 [I-D.ietf-ippm-alt-mark] 315 Fioccola, G., Capello, A., Cociglio, M., Castaldelli, L., 316 Chen, M., Zheng, L., Mirsky, G., and T. Mizrahi, 317 "Alternate Marking method for passive and hybrid 318 performance monitoring", draft-ietf-ippm-alt-mark-10 (work 319 in progress), September 2017. 321 [RFC7665] Halpern, J., Ed. and C. Pignataro, Ed., "Service Function 322 Chaining (SFC) Architecture", RFC 7665, 323 DOI 10.17487/RFC7665, October 2015, 324 . 326 Authors' Addresses 328 Greg Mirsky 329 ZTE Corp. 331 Email: gregimirsky@gmail.com 333 Giuseppe Fioccola 334 Telecom Italia 336 Email: giuseppe.fioccola@telecomitalia.it 338 Tal Mizrahi 339 Marvell 340 6 Hamada St. 341 Yokneam 342 Israel 344 Email: talmi@marvell.com