idnits 2.17.1 draft-bryant-mpls-rfc6374-sfl-00.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 (October 18, 2015) is 3107 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 (-05) exists of draft-ietf-mpls-rfc6374-udp-return-path-04 == Outdated reference: A later version (-03) exists of draft-bryant-mpls-flow-ident-02 == Outdated reference: A later version (-06) exists of draft-chen-ippm-coloring-based-ipfpm-framework-04 == Outdated reference: A later version (-03) exists of draft-tempia-ippm-p3m-01 Summary: 0 errors (**), 0 flaws (~~), 5 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 MPLS S. Bryant 3 Internet-Draft G. Swallow 4 Intended status: Standards Track S. Sivabalan 5 Expires: April 20, 2016 Cisco Systems 6 G. Mirsky 7 Ericsson 8 M. Chen 9 Z. Li 10 Huawei 11 October 18, 2015 13 RFC6374 Synonymous Flow Labels 14 draft-bryant-mpls-rfc6374-sfl-00 16 Abstract 18 This document describes a method of providing flow identification 19 information when making RFC6374 performance measurements. This 20 allows RFC6374 measurements to be made on multi-point to point LSPs 21 and allows the measurement of flows within an MPLS construct using 22 RFC6374. 24 Status of This Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at http://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on April 20, 2016. 41 Copyright Notice 43 Copyright (c) 2015 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (http://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 59 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3 60 3. RFC6374 Packet Loss Measurement with SFL . . . . . . . . . . 3 61 3.1. RFC6374 SFL TLV . . . . . . . . . . . . . . . . . . . . . 5 62 4. The Application of SFL to other PM Types . . . . . . . . . . 6 63 5. Privacy Considerations . . . . . . . . . . . . . . . . . . . 6 64 6. Security Considerations . . . . . . . . . . . . . . . . . . . 6 65 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 66 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7 67 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 68 9.1. Normative References . . . . . . . . . . . . . . . . . . 7 69 9.2. Informative References . . . . . . . . . . . . . . . . . 7 70 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 72 1. Introduction 74 [I-D.bryant-mpls-flow-ident] describes the requirement for 75 introducing flow identities when using RFC6374 [RFC6374] packet Loss 76 Measurements (LM). In summary RFC6374 uses the LM packet as the 77 packet accounting demarcation point. Unfortunately this gives rise 78 to a number of problems that may lead to significant packet 79 accounting errors in 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 draft-bryant-mpls-sfl-framework specifies a method of encoding per 117 flow 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 (draft-bryant-mpls-RFC6374-over-udp). This TLV MUST be included 183 unless, by some method outside the scope of this document, it is 184 known that this information is not 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 192 [I-D.ietf-mpls-rfc6374-udp-return-path]. 194 3.1. RFC6374 SFL TLV 196 [Editor's Note we need to review the following in the light of 197 further thoughts on the associated signaling protocol(s). I am 198 fairly confident that we need all the fields other than SFL Batch and 199 SFL Index. The Index is useful in order to map between the label and 200 information associated with the FEC. The batch is part of the 201 lifetime management process] 203 The required RFC6374 SFL TLV is shown in Figure 2. This contains the 204 SFL that was carried in the label stack, the FEC that was used to 205 allocate the SFL and the index into the batch of SLs that were 206 allocated for the FEC that corresponds to this SFL. 208 0 1 2 3 209 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 210 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 211 | Type | Length |MBZ| SFL Batch | SFL Index | 212 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 213 | SFL | Reserved | 214 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 215 | FEC | 216 . . 217 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 219 Figure 2: SFL TLV 221 Where: 223 Type Type is set to Synonymous Flow Label (SFL-TLV). 225 Length The length of the TLV as specified in [RFC6374]. 227 MBZ MUST be sent as zero and ignored on receive. 229 SFL Batch The SFL batch that this SFL was allocated as part of 230 (see draft-bryant-mpls-sfl-control) 232 SPL Index The index into the list of SFLs that were assigned 233 against the FEC that corresponds to the SFL. 235 SFL The SFL used to deliver this packet. This is an MPLS 236 label which is a component of a label stack entry as 237 defined in Section 2.1 of [RFC3032]. 239 Reserved MUST be sent as zero and ignored on receive. 241 FEC The Forwarding Equivalence Class that was used to 242 request this SFL. This is encoded as per 243 Section 3.4.1 of 245 This information is needed to allow for operation with hardware that 246 discards the MPLS label stack before passing the remainder of the 247 stack to the OAM handler. By providing both the SFL and the FEC plus 248 index into the array of allocated SFLs a number of implementation 249 types are supported. 251 4. The Application of SFL to other PM Types 253 SFL can be used to enable other types of PM in addition to loss. 254 Delay, Delay Variation and Throughput may be calculated based on 255 measurement results collected through Loss and Delay Measurement test 256 sessions. Further details will be provided in a future version of 257 this draft. 259 5. Privacy Considerations 261 The inclusion of originating and/or flow information in a packet 262 provides more identity information and hence potentially degrades the 263 privacy of the communication. Whilst the inclusion of the additional 264 granularity does allow greater insight into the flow characteristics 265 it does not specifically identify which node originated the packet 266 other than by inspection of the network at the point of ingress, or 267 inspection of the control protocol packets. This privacy threat may 268 be mitigated by encrypting the control protocol packets, regularly 269 changing the synonymous labels and by concurrently using a number of 270 such labels. 272 6. Security Considerations 274 The issue noted in Section 5 is a security consideration. There are 275 no other new security issues associated with the MPLS dataplane. Any 276 control protocol used to request SFLs will need to ensure the 277 legitimacy of the request. 279 7. IANA Considerations 281 IANA is request to allocate a new TLV from the 0-127 range on the 282 MPLS Loss/Delay Measurement TLV Object Registry: 284 Type Description Reference 285 ---- --------------------------------- --------- 286 TBD Synonymous Flow Label This 288 A value of 4 is recommended. 290 8. Acknowledgements 292 TBD 294 9. References 296 9.1. Normative References 298 [I-D.ietf-mpls-rfc6374-udp-return-path] 299 Bryant, S., Sivabalan, S., and S. Soni, "RFC6374 UDP 300 Return Path", draft-ietf-mpls-rfc6374-udp-return-path-04 301 (work in progress), August 2015. 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 [RFC3032] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y., 309 Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack 310 Encoding", RFC 3032, DOI 10.17487/RFC3032, January 2001, 311 . 313 9.2. Informative References 315 [I-D.bryant-mpls-flow-ident] 316 Bryant, S., Pignataro, C., Chen, M., Li, Z., and G. 317 Mirsky, "MPLS Flow Identification", draft-bryant-mpls- 318 flow-ident-02 (work in progress), September 2015. 320 [I-D.chen-ippm-coloring-based-ipfpm-framework] 321 Chen, M., Zheng, L., Mirsky, G., and G. Fioccola, "IP Flow 322 Performance Measurement Framework", draft-chen-ippm- 323 coloring-based-ipfpm-framework-04 (work in progress), July 324 2015. 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-01 (work in 330 progress), September 2015. 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 Cisco Systems 342 Email: stbryant@cisco.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 359 Mach(Guoyi) Chen 360 Huawei 362 Email: mach.chen@huawei.com 363 Zhenbin(Robin) Li 364 Huawei 366 Email: lizhenbin@huawei.com