idnits 2.17.1 draft-bryant-mpls-rfc6374-sfl-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 (August 09, 2016) is 2816 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) == Unused Reference: 'RFC3032' is defined on line 298, but no explicit reference was found in the text == Outdated reference: A later version (-09) exists of draft-bryant-mpls-sfl-control-00 == Outdated reference: A later version (-07) exists of draft-ietf-mpls-flow-ident-01 Summary: 0 errors (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 MPLS S. Bryant 3 Internet-Draft Independent 4 Intended status: Standards Track G. Swallow 5 Expires: February 10, 2017 S. Sivabalan 6 Cisco Systems 7 G. Mirsky 8 Ericsson 9 M. Chen 10 Z. Li 11 Huawei 12 August 09, 2016 14 RFC6374 Synonymous Flow Labels 15 draft-bryant-mpls-rfc6374-sfl-01 17 Abstract 19 This document describes a method of providing flow identification 20 information when making RFC6374 performance measurements. This 21 allows RFC6374 measurements to be made on multi-point to point LSPs 22 and allows the measurement of flows within an MPLS construct using 23 RFC6374. 25 Status of This Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at http://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on February 10, 2017. 42 Copyright Notice 44 Copyright (c) 2016 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (http://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 60 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3 61 3. RFC6374 Packet Loss Measurement with SFL . . . . . . . . . . 3 62 3.1. RFC6374 SFL TLV . . . . . . . . . . . . . . . . . . . . . 5 63 4. The Application of SFL to other PM Types . . . . . . . . . . 6 64 5. Privacy Considerations . . . . . . . . . . . . . . . . . . . 6 65 6. Security Considerations . . . . . . . . . . . . . . . . . . . 7 66 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 67 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 68 8.1. Normative References . . . . . . . . . . . . . . . . . . 7 69 8.2. Informative References . . . . . . . . . . . . . . . . . 7 70 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 72 1. Introduction 74 [I-D.ietf-mpls-flow-ident] describes the requirement for introducing 75 flow identities when using RFC6374 [RFC6374] packet Loss Measurements 76 (LM). In summary RFC6374 uses the LM packet as the packet accounting 77 demarcation point. Unfortunately this gives rise to a number of 78 problems that may lead to significant packet accounting errors in 79 certain situations. For example: 81 1. Where a flow is subjected to Equal Cost Multi-Path (ECMP) 82 treatment packets can arrive out of order with respect to the LM 83 packet. 85 2. Where a flow is subjected to ECMP treatment, packets can arrive 86 at different hardware interfaces, thus requiring reception of an 87 LM packet on one interface to trigger a packet accounting action 88 on a different interface which may not be co-located with it. 89 This is a difficult technical problem to address with the 90 required degree of accuracy. 92 3. Even where there is no ECMP (for example on RSVP-TE, MPLS-TP LSPs 93 and PWs) local processing may be distributed over a number of 94 processor cores, leading to synchronization problems. 96 4. Link aggregation techniques may also lead to synchronization 97 issues. 99 5. Some forwarder implementations have a long pipeline between 100 processing a packet and incrementing the associated counter again 101 leading to synchronization difficulties. 103 An approach to mitigating these synchronization issue is described in 104 [I-D.tempia-ippm-p3m] and 105 [I-D.chen-ippm-coloring-based-ipfpm-framework] in which packets are 106 batched by the sender and each batch is marked in some way such that 107 adjacent batches can be easily recognized by the receiver. 109 An additional problem arises where the LSP is a multi-point to point 110 LSP, since MPLS does not include a source address in the packet. 111 Network management operations require the measurement of packet loss 112 between a source and destination. It is thus necessary to introduce 113 some source specific information into the packet to identify packet 114 batches from a specific source. 116 {{I-D.ietf-mpls-sfl-framework specifies a method of encoding per flow 117 instructions in an MPLS label stack using a technique called 118 Synonymous Flow Labels (SFL) in which labels which mimic the 119 behaviour of other labels provide the packet batch identifiers and 120 enable the per batch packet accounting. This memo specifies how SFLs 121 are used to perform RFC6374 performance measurements. 123 2. Requirements Language 125 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 126 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 127 "OPTIONAL" in this document are to be interpreted as described in 128 [RFC2119]. 130 3. RFC6374 Packet Loss Measurement with SFL 132 The packet format of an RFC6374 Query message using SFLs is shown in 133 Figure 1. 135 +-------------------------------+ 136 | | 137 | LSP | 138 | Label | 139 +-------------------------------+ 140 | | 141 | Synonymous Flow | 142 | Label | 143 +-------------------------------+ 144 | | 145 | | 146 | RFC6374 Measurement Message | 147 | | 148 | +-------------------------+ | 149 | | | | 150 | | RFC6374 Fixed | | 151 | | Header | | 152 | | | | 153 | +-------------------------+ | 154 | | | | 155 | | Optional SFL TLV | | 156 | | | | 157 | +-------------------------+ | 158 | | | | 159 | | Optional Return | | 160 | | Information | | 161 | | | | 162 | +-------------------------+ | 163 | | 164 +-------------------------------+ 166 Figure 1: RFC6734 Query Packet with SFL 168 The MPLS label stack is exactly the same as that used for the user 169 data service packets being instrumented except for the replacement of 170 the appropriate label with an SFL . The RFC6374 measurement message 171 consists of the three components, the RFC6374 fixed header as 172 specified in [RFC6374] carried over the ACH channel type specified 173 the type of measurement being made (currently: loss, delay or loss 174 and delay) as specified in RFC6374. 176 Two optional TLVs MAY also be carried if needed. The first is the 177 SFL TLV specified in Section 3.1. This is used to provide the 178 implementation with a reminder of the SFL that was used to carry the 179 RFC6374 message. This is needed because a number of MPLS 180 implementations do not provide the MPLS label stack to the MPLS OAM 181 handler. This TLV is required if RFC6374 messages are sent over UDP 182 [RFC7876]. This TLV MUST be included unless, by some method outside 183 the scope of this document, it is known that this information is not 184 needed by the RFC6374 Responder. 186 The second set of information that may be needed is the return 187 information that allows the responder send the RFC6374 response to 188 the Querier. This is not needed if the response is requested in-band 189 and the MPLS construct being measured is a point to point LSP, but 190 otherwise MUST be carried. The return address TLV is defined in 191 RFC6378 and the optional UDP Return Object is defined in [RFC7876]. 193 3.1. RFC6374 SFL TLV 195 [Editor's Note we need to review the following in the light of 196 further thoughts on the associated signaling protocol(s). I am 197 fairly confident that we need all the fields other than SFL Batch and 198 SFL Index. The Index is useful in order to map between the label and 199 information associated with the FEC. The batch is part of the 200 lifetime management process.] 202 The required RFC6374 SFL TLV is shown in Figure 2. This contains the 203 SFL that was carried in the label stack, the FEC that was used to 204 allocate the SFL and the index into the batch of SLs that were 205 allocated for the FEC that corresponds to this SFL. 207 0 1 2 3 208 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 209 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 210 | Type | Length |MBZ| SFL Batch | SFL Index | 211 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 212 | SFL | Reserved | 213 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 214 | FEC | 215 . . 216 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 218 Figure 2: SFL TLV 220 Where: 222 Type Type is set to Synonymous Flow Label (SFL-TLV). 224 Length The length of the TLV as specified in RFC6374. 226 MBZ MUST be sent as zero and ignored on receive. 228 SFL Batch The SFL batch that this SFL was allocated as part 229 of see [I-D.bryant-mpls-sfl-control] 231 SPL Index The index into the list of SFLs that were assigned 232 against the FEC that corresponds to the SFL. 234 SFL The SFL used to deliver this packet. This is an MPLS 235 label which is a component of a label stack entry as 236 defined in Section 2.1 of RFC3032. 238 Reserved MUST be sent as zero and ignored on receive. 240 FEC The Forwarding Equivalence Class that was used to 241 request this SFL. This is encoded as per 242 Section 3.4.1 of TBD 244 This information is needed to allow for operation with hardware that 245 discards the MPLS label stack before passing the remainder of the 246 stack to the OAM handler. By providing both the SFL and the FEC plus 247 index into the array of allocated SFLs a number of implementation 248 types are supported. 250 4. The Application of SFL to other PM Types 252 SFL can be used to enable other types of PM in addition to loss. 253 Delay, Delay Variation and Throughput may be calculated based on 254 measurement results collected through Loss and Delay Measurement test 255 sessions. Further details will be provided in a future version of 256 this draft. 258 5. Privacy Considerations 260 The inclusion of originating and/or flow information in a packet 261 provides more identity information and hence potentially degrades the 262 privacy of the communication. Whilst the inclusion of the additional 263 granularity does allow greater insight into the flow characteristics 264 it does not specifically identify which node originated the packet 265 other than by inspection of the network at the point of ingress, or 266 inspection of the control protocol packets. This privacy threat may 267 be mitigated by encrypting the control protocol packets, regularly 268 changing the synonymous labels and by concurrently using a number of 269 such labels. 271 6. Security Considerations 273 The issue noted in Section 5 is a security consideration. There are 274 no other new security issues associated with the MPLS dataplane. Any 275 control protocol used to request SFLs will need to ensure the 276 legitimacy of the request. 278 7. IANA Considerations 280 IANA is request to allocate a new TLV from the 0-127 range on the 281 MPLS Loss/Delay Measurement TLV Object Registry: 283 Type Description Reference 284 ---- --------------------------------- --------- 285 TBD Synonymous Flow Label This 287 A value of 4 is recommended. 289 8. References 291 8.1. Normative References 293 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 294 Requirement Levels", BCP 14, RFC 2119, 295 DOI 10.17487/RFC2119, March 1997, 296 . 298 [RFC3032] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y., 299 Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack 300 Encoding", RFC 3032, DOI 10.17487/RFC3032, January 2001, 301 . 303 [RFC7876] Bryant, S., Sivabalan, S., and S. Soni, "UDP Return Path 304 for Packet Loss and Delay Measurement for MPLS Networks", 305 RFC 7876, DOI 10.17487/RFC7876, July 2016, 306 . 308 8.2. Informative References 310 [I-D.bryant-mpls-sfl-control] 311 Bryant, S., Swallow, G., and S. Sivabalan, "A Control 312 Protocol for Synonymous Flow Labels", draft-bryant-mpls- 313 sfl-control-00 (work in progress), March 2015. 315 [I-D.chen-ippm-coloring-based-ipfpm-framework] 316 Chen, M., Zheng, L., Mirsky, G., Fioccola, G., and T. 317 Mizrahi, "IP Flow Performance Measurement Framework", 318 draft-chen-ippm-coloring-based-ipfpm-framework-06 (work in 319 progress), March 2016. 321 [I-D.ietf-mpls-flow-ident] 322 Bryant, S., Pignataro, C., Chen, M., Li, Z., and G. 323 Mirsky, "MPLS Flow Identification Considerations", draft- 324 ietf-mpls-flow-ident-01 (work in progress), June 2016. 326 [I-D.tempia-ippm-p3m] 327 Capello, A., Cociglio, M., Fioccola, G., Castaldelli, L., 328 and A. Bonda, "A packet based method for passive 329 performance monitoring", draft-tempia-ippm-p3m-03 (work in 330 progress), March 2016. 332 [RFC6374] Frost, D. and S. Bryant, "Packet Loss and Delay 333 Measurement for MPLS Networks", RFC 6374, 334 DOI 10.17487/RFC6374, September 2011, 335 . 337 Authors' Addresses 339 Stewart Bryant 340 Independent 342 Email: stewart.bryant@gmail.com 344 George Swallow 345 Cisco Systems 347 Email: swallow@cisco.com 349 Siva Sivabalan 350 Cisco Systems 352 Email: msiva@cisco.com 354 Greg Mirsky 355 Ericsson 357 Email: gregory.mirsky@ericsson.com 358 Mach(Guoyi) Chen 359 Huawei 361 Email: mach.chen@huawei.com 363 Zhenbin(Robin) Li 364 Huawei 366 Email: lizhenbin@huawei.com