idnits 2.17.1 draft-mirsky-sfc-pmamm-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 (June 28, 2017) is 2494 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-12 == Outdated reference: A later version (-14) exists of draft-ietf-ippm-alt-mark-05 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: December 30, 2017 Telecom Italia 6 T. Mizrahi 7 Marvell 8 June 28, 2017 10 Performance Measurement (PM) with Alternate Marking Method in Service 11 Function Chaining (SFC) Domain 12 draft-mirsky-sfc-pmamm-01 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 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 December 30, 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. 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 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 63 5.1. Mark Field in NSH Base Header . . . . . . . . . . . . . . 6 64 6. Security Considerations . . . . . . . . . . . . . . . . . . . 6 65 7. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 6 66 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 67 8.1. Normative References . . . . . . . . . . . . . . . . . . 6 68 8.2. Informative References . . . . . . . . . . . . . . . . . 7 69 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 71 1. Introduction 73 [RFC7665] introduced architecture of a Service Function Chain (SFC) 74 in the network and defined its components as classifier, Service 75 Function Forwarder (SFF), and Service Function (SF). 76 [I-D.ietf-ippm-alt-mark] describes passive performance measurement 77 method, which can be used to measure packet loss, latency and jitter 78 on live traffic. Because this method is based on marking consecutive 79 batches of packets the method often referred as Alternate Marking 80 Method (AMM). 82 This document defines how the alternate marking method can be used to 83 measure packet loss and delay metrics of a service flow over e2e or 84 any segment of the SFC. 86 2. Conventions used in this document 88 2.1. Terminology 90 MM: Marking Method 92 OAM: Operations, Administration and Maintenance 94 SFC: Service Function Chain 96 SF: Service Function 97 SFF: Service Function Forwarder 99 SFP: Service Function Path 101 NSH: Network Service Header 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 BCP 108 14 [RFC2119] [RFC8174] when, and only when, they appear in all 109 capitals, as shown here. 111 3. Mark Field in NSH Base Header 113 [I-D.ietf-sfc-nsh] defines format of the Network Service Header 114 (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 two bit long field, referred as Mark field (M 125 in Figure 1, as part of NSH Base and designated for the alternate 126 marking performance measurement method [I-D.ietf-ippm-alt-mark]. The 127 Mark field MUST NOT be used in defining forwarding and/or quality of 128 service treatment of a SFC packet. The Mark field MUST be used only 129 for the performance measurement of data traffic in SFC layer. 130 Because setting of the field to any value does not affect forwarding 131 and/or quality of service treatment of a packet, the alternate 132 marking method in SFC layer can be viewed as true example of passive 133 performance measurement method. 135 The Figure 2 displays format of the Mark field. 137 0 138 0 1 139 +-+-+-+-+ 140 | S | D | 141 +-+-+-+-+ 143 Figure 2: Mark field format 145 where: 147 o S- Single mark method; 149 o D - Double mark method. 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 [I-D.ietf-ippm-alt-mark], marking can be applied 179 to delineate blocks of packets based either on equal number of 180 packets in a block or based on equal time interval. The latter 181 method offers better control as it allows better account for 182 capabilities of downstream nodes to report statistics related to 183 batches of packets and, at the same time, time resolution that 184 affects defect detection interval. 186 If the Single Mark measurement used, then the D flag MUST be set to 187 zero on transmit and ignored by monitoring point. 189 The S flag is used to create alternate flows to measure the packet 190 loss by switching value of the S flag every N-th packet or at certain 191 time intervals. Delay metrics MAY be calculated with the alternate 192 flow using any of the following methods: 194 o First/Last Packet Delay calculation: whenever the marking, i.e. 195 value of S flag, changes a component of the SFC can store the 196 timestamp of the first/last packet of the block. The timestamp 197 can be compared with the timestamp of the packet that arrived in 198 the same order through a monitoring point at downstream component 199 of the SFC to compute packet delay. Because timestamps collected 200 based on order of arrival this method is sensitive to packet loss 201 and re-ordering of packets 203 o Average Packet Delay calculation: an average delay is calculated 204 by considering the average arrival time of the packets within a 205 single block. A component of the SFC may collect timestamps for 206 each packet received within a single block. Average of the 207 timestamp is the sum of all the timestamps divided by the total 208 number of packets received. Then difference between averages 209 calculated at two monitoring points is the average packet delay on 210 that segment. This method is robust to out of order packets and 211 also to packet loss (only a small error is introduced). This 212 method only provides single metric for the duration of the block 213 and it doesn't give the minimum and maximum delay values. This 214 limitation could be overcome by reducing the duration of the block 215 by means of an highly optimized implementation of the method. 217 4.2. Double Mark Enabled Measurement 219 Double Mark method allows measurement of minimum and maximum delays 220 for the monitored flow but it requires more nodal and network 221 resources. If the Double Mark method used, then the S flag MUST be 222 used to create the alternate flow, i.e. mark larger batches of 223 packets. The D flag MUST be used to mark single packets to measure 224 delay jitter. 226 The first marking (S flag alternation) is needed for packet loss and 227 also for average delay measurement. The second marking (D flag is 228 put to one) creates a new set of marked packets that are fully 229 identified over the SFC, so that a component can store the timestamps 230 of these packets; these timestamps can be compared with the 231 timestamps of the same packets on another component of the SFC to 232 compute packet delay values for each packet. The number of 233 measurements can be easily increased by changing the frequency of the 234 second marking. But the frequency of the second marking must be not 235 too high in order to avoid out of order issues. This method is 236 useful to have not only the average delay but also the minimum and 237 maximum delay values and, in wider terms, to know more about the 238 statistic distribution of delay values. 240 5. IANA Considerations 242 5.1. Mark Field in NSH Base Header 244 This document requests IANA to allocate Mark field as two bits-long 245 field from NSH Base Header Reserved Bits [I-D.ietf-sfc-nsh]. 247 This document requests IANA to register values of the Mark field of 248 NSH as the following: 250 +--------------+---------+--------------------------+---------------+ 251 | Bit Position | Marking | Description | Reference | 252 +--------------+---------+--------------------------+---------------+ 253 | 0 | S | Single Mark Measurement | This document | 254 | 1 | D | Double Mark Measurement | This document | 255 +--------------+---------+--------------------------+---------------+ 257 Table 1: Mark field of SFC NSH 259 6. Security Considerations 261 This document lists the OAM requirement for SFC domain and does not 262 raise any security concerns or issues in addition to ones common to 263 networking and SFC. 265 7. Acknowledgement 267 TBD 269 8. References 271 8.1. Normative References 273 [I-D.ietf-sfc-nsh] 274 Quinn, P. and U. Elzur, "Network Service Header", draft- 275 ietf-sfc-nsh-12 (work in progress), February 2017. 277 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 278 Requirement Levels", BCP 14, RFC 2119, 279 DOI 10.17487/RFC2119, March 1997, 280 . 282 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 283 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 284 May 2017, . 286 8.2. Informative References 288 [I-D.ietf-ippm-alt-mark] 289 Fioccola, G., Capello, A., Cociglio, M., Castaldelli, L., 290 Chen, M., Zheng, L., Mirsky, G., and T. Mizrahi, 291 "Alternate Marking method for passive and hybrid 292 performance monitoring", draft-ietf-ippm-alt-mark-05 (work 293 in progress), June 2017. 295 [RFC7665] Halpern, J., Ed. and C. Pignataro, Ed., "Service Function 296 Chaining (SFC) Architecture", RFC 7665, 297 DOI 10.17487/RFC7665, October 2015, 298 . 300 Authors' Addresses 302 Greg Mirsky 303 ZTE Corp. 305 Email: gregimirsky@gmail.com 307 Giuseppe Fioccola 308 Telecom Italia 310 Email: giuseppe.fioccola@telecomitalia.it 312 Tal Mizrahi 313 Marvell 314 6 Hamada St. 315 Yokneam 316 Israel 318 Email: talmi@marvell.com