--- 1/draft-ietf-mpls-rfc6374-sfl-01.txt 2018-06-20 05:13:19.586970468 -0700 +++ 2/draft-ietf-mpls-rfc6374-sfl-02.txt 2018-06-20 05:13:19.646971898 -0700 @@ -1,26 +1,27 @@ MPLS Working Group S. Bryant Internet-Draft M. Chen Intended status: Standards Track Z. Li -Expires: June 8, 2018 Huawei +Expires: December 22, 2018 Huawei G. Swallow + Southend Technical Center S. Sivabalan Cisco Systems G. Mirsky ZTE Corp. G. Fioccola Telecom Italia - December 05, 2017 + June 20, 2018 RFC6374 Synonymous Flow Labels - draft-ietf-mpls-rfc6374-sfl-01 + draft-ietf-mpls-rfc6374-sfl-02 Abstract This document describes a method of making RFC6374 performance measurements on flows carried over an MPLS Label Switched path. This allows loss and delay measurements to be made on multi-point to point LSPs and allows the measurement of flows within an MPLS construct using RFC6374. Status of This Memo @@ -31,25 +32,25 @@ Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." - This Internet-Draft will expire on June 8, 2018. + This Internet-Draft will expire on December 22, 2018. Copyright Notice - Copyright (c) 2017 IETF Trust and the persons identified as the + Copyright (c) 2018 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as @@ -72,40 +73,40 @@ 8. Sampled Measurement . . . . . . . . . . . . . . . . . . . . . 13 9. Carrying RFC6374 Packets over an LSP using an SFL . . . . . . 13 9.1. RFC6374 SFL TLV . . . . . . . . . . . . . . . . . . . . . 15 10. Applicability to Pro-active and On-demand Measurement . . . . 16 11. RFC6374 Combined Loss-Delay Measurement . . . . . . . . . . . 16 12. Privacy Considerations . . . . . . . . . . . . . . . . . . . 16 13. Security Considerations . . . . . . . . . . . . . . . . . . . 17 14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 14.1. Allocation of PW Associated Channel Type . . . . . . . . 17 14.2. MPLS Loss/Delay TLV Object . . . . . . . . . . . . . . . 17 - 15. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 - 15.1. Normative References . . . . . . . . . . . . . . . . . . 17 + 15. References . . . . . . . . . . . . . . . . . . . . . . . . . 18 + 15.1. Normative References . . . . . . . . . . . . . . . . . . 18 15.2. Informative References . . . . . . . . . . . . . . . . . 18 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19 1. Introduction [RFC6374] was originally designed for use as an OAM protocol for use with MPLS Transport Profile (MPLS-TP) [RFC5921] LSPs. MPLS-TP only supports point-to-point and point-to-multi-point LSPs. This document describes how to use RFC6374 in the general MPLS case, and also introduces a number of more sophisticated measurements of applicability to both cases. - [I-D.ietf-mpls-flow-ident] describes the requirement for introducing - flow identities when using RFC6374 [RFC6374] packet Loss Measurements - (LM). In summary RFC6374 uses the loss-measurement (LM) packet as - the packet accounting demarcation point. Unfortunately this gives - rise to a number of problems that may lead to significant packet - accounting errors in certain situations. For example: + [RFC8372] describes the requirement for introducing flow identities + when using RFC6374 [RFC6374] packet Loss Measurements (LM). In + summary RFC6374 uses the loss-measurement (LM) packet as the packet + accounting demarcation point. Unfortunately this gives rise to a + number of problems that may lead to significant packet accounting + errors in certain situations. For example: 1. Where a flow is subjected to Equal Cost Multi-Path (ECMP) treatment packets can arrive out of order with respect to the LM packet. 2. Where a flow is subjected to ECMP treatment, packets can arrive at different hardware interfaces, thus requiring reception of an LM packet on one interface to trigger a packet accounting action on a different interface which may not be co-located with it. This is a difficult technical problem to address with the @@ -116,68 +117,68 @@ processor cores, leading to synchronization problems. 4. Link aggregation techniques may also lead to synchronization issues. 5. Some forwarder implementations have a long pipeline between processing a packet and incrementing the associated counter again leading to synchronization difficulties. An approach to mitigating these synchronization issue is described in - [I-D.tempia-ippm-p3m] and - [I-D.chen-ippm-coloring-based-ipfpm-framework] in which packets are - batched by the sender and each batch is marked in some way such that - adjacent batches can be easily recognized by the receiver. + [RFC8321] in which packets are batched by the sender and each batch + is marked in some way such that adjacent batches can be easily + recognized by the receiver. An additional problem arises where the LSP is a multi-point to point LSP, since MPLS does not include a source address in the packet. Network management operations require the measurement of packet loss between a source and destination. It is thus necessary to introduce some source specific information into the packet to identify packet batches from a specific source. - [I-D.bryant-mpls-sfl-framework] describes a method of encoding per - flow instructions in an MPLS label stack using a technique called + [I-D.ietf-mpls-sfl-framework] describes a method of encoding per flow + instructions in an MPLS label stack using a technique called Synonymous Flow Labels (SFL) in which labels which mimic the behaviour of other labels provide the packet batch identifiers and enable the per batch packet accounting. This memo specifies how SFLs are used to perform RFC6374 packet loss and RFC6374 delay measurements. 2. Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and - "OPTIONAL" in this document are to be interpreted as described in - [RFC2119]. + "OPTIONAL" in this document are to be interpreted as described in BCP + 14 [RFC2119] [RFC8174] when, and only when, they appear in all + capitals, as shown here. 3. RFC6374 Packet Loss Measurement with SFL The data service packets of the flow being instrumented are grouped into batches, and all the packets within a batch are marked with the - SFL [I-D.ietf-mpls-flow-ident] corresponding to that batch. The - sender counts the number of packets in the batch. When the batch has - completed and the sender is confident that all of the packets in that - batch will have been received, the sender issues an RFC6374 Query - message to determine the number actually received and hence the - number of packets lost. The RFC6374 Query message is sent using the - same SFL as the co-responding batch of data service packets. The - format of the Query and Response packet is described in Section 9. + SFL [RFC8372] corresponding to that batch. The sender counts the + number of packets in the batch. When the batch has completed and the + sender is confident that all of the packets in that batch will have + been received, the sender issues an RFC6374 Query message to + determine the number actually received and hence the number of + packets lost. The RFC6374 Query message is sent using the same SFL + as the co-responding batch of data service packets. The format of + the Query and Response packet is described in Section 9. 4. RFC6374 Single Packet Delay Measurement RFC6374 describes how to measure the packet delay by measuring the transit time of an RFC6374 packet over an LSP. Such a packet may not need to be carried over an SFL since the delay over a particular LSP should be a function of the TC bits. - However where SFLs are being used to monitor packet loss or where + However, where SFLs are being used to monitor packet loss or where label inferred scheduling is used [RFC3270] then the SFL would be REQUIRED to ensure that the RFC6374 packet which was being used as a proxy for a data service packet experienced a representative delay. The format of an RFC6374 packet carried over the LSP using an SFL is shown in Section 9. 5. Data Service Packet Delay Measurement Where it is desired to more thoroughly instrument a packet flow and to determine the delay of a number of packets it is undesirable to @@ -219,21 +220,21 @@ In case 1 of Figure 1 we show the case were loss measurement alone is being carried out on the flow under analysis. For illustrative purposes consider that in the time interval being analyzed, 10 packets always flow. Now consider case 2 of Figure 1 where a small batch of packets need to analyzed for delay. These are marked with a different SFL type indicating that they are to be monitored for both loss and delay. The SFL=A indicates loss batch A, SFL=D indicates a batch of packets that are to be instrumented for delay, but SFL D is synonymous with - SFL A, which in turn is synonymous with the underlying FEC. Thus a + SFL A, which in turn is synonymous with the underlying FEC. Thus, a packet marked D will be accumulated into the A loss batch, into the delay statistics and will be forwarded as normal. Whether the packet is actually counted twice (for loss and delay) or whether the two counters are reconciled during reporting is a local matter. Now consider case 3 of Figure 1 where a small batch of packets are marked for delay across a loss batch boundary. These packets need to considered as part of batch A or a part of batch B, and any RFC6374 Query needs to take place after all the packets A or D (which ever option is chosen) have arrived at the receiving LSR. @@ -361,21 +361,21 @@ the Query message), then the Responder MUST respond with 0 packets in each bucket until it has been configured for a full measurement period. This indicates that it was configured at the time of the last response message, and thus the response is valid for the whole interval. As per the [RFC6374] convention the Number of pkts in Bucket fields are included in the Query message and set to zero. Out of band configuration is permitted by this mode of operation. Note this is a departure from the normal fixed format used in - RFC6374. We need to establish if this is problematic or not. + RFC6374. This RFC6374 message is carried over an LSP in the way described in [RFC6374] and over an LSP with an SFL as described in Section 9. 7.2. Method 2 Classic Standard Deviation In this method, provision is made for reporting the following delay characteristics: 1. Number of packets in the batch (n). @@ -396,23 +396,21 @@ Characteristics 1, 2 and 5 can be used to calculate the variance of the inter-packet gap and hence the standard deviation giving a view of the distribution of packet delays and hence the jitter. The equation for the variance (var) is given by: var = (SS - S*S/n)/(n-1) There is some concern over the use of this algorithm for measuring variance, because SS and S*S/n can be similar numbers, particularly where variance is low. However the method commends it self by not - requiring a division in the hardware. A future version of this - document will look at using improved statistical methods such as the - assumed mean. + requiring a division in the hardware. 7.2.1. RFC6374 Multi-Packet Delay Measurement Message Format The packet format of an RFC6374 Multi-Packet Delay Measurement Message is shown below: 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Version| Flags | Control Code | Message Length | @@ -465,30 +463,30 @@ If detailed packet delay measurement is required then it might be possible to record the inter-packet gap for each packet pair. In other that exception cases of slow flows or small batch sizes, this would create a large demand on storage in the instrumentation system, bandwidth to such a storage system and bandwidth to the analytics system. Such a measurement technique is outside the scope of this document. 7.4. Average Delay - Introduced in [I-D.ietf-ippm-alt-mark] is the concept of a one way - delay measurement in which the average time of arrival of a set of - packets is measured. In this approach the packet is time-stamped at - arrival and the Responder returns the sum of the time-stamps and the - number of times-tamps. From this the analytics engine can determine - the mean delay. An alternative model is that the Responder returns - the time stamp of the first and last packet and the number of - packets. This method has the advantage of allowing the average delay - to be determined at a number of points along the packet path and - allowing the components of the delay to be characterized. + Introduced in [RFC8321] is the concept of a one way delay measurement + in which the average time of arrival of a set of packets is measured. + In this approach the packet is time-stamped at arrival and the + Responder returns the sum of the time-stamps and the number of times- + tamps. From this the analytics engine can determine the mean delay. + An alternative model is that the Responder returns the time stamp of + the first and last packet and the number of packets. This method has + the advantage of allowing the average delay to be determined at a + number of points along the packet path and allowing the components of + the delay to be characterized. The packet format of an RFC6374 Average Delay Measurement Message is shown below: 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Version| Flags | Control Code | Message Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | QTF | RTF | RPTF | Reserved | @@ -531,29 +529,29 @@ This RFC6374 message is carried over an LSP in the way described in [RFC6374] and over an LSP with an SFL as described in Section 9. As is the convention with RFC6374, the Query message contains placeholders for the Response message. The placeholders are sent as zero. 8. Sampled Measurement In the discussion so far it has been assumed that we would measure the delay characteristics of every packet in a delay measurement - interval defined by an SL of constant colour. In - [I-D.ietf-ippm-alt-mark] the concept of a sampled measurement is - considered. That is the Responder only measures a packet at the - start of a group of packets being marked for delay measurement by a - particular colour, rather than every packet in the marked batch. A - measurement interval is not defined by the duration of a marked batch - of packets but the interval between a pair of RFC6374 packets taking - a readout of the delay characteristic. This approach has the - advantage that the measurement is not impacted by ECMP effects. + interval defined by an SL of constant colour. In [RFC8321] the + concept of a sampled measurement is considered. That is the + Responder only measures a packet at the start of a group of packets + being marked for delay measurement by a particular colour, rather + than every packet in the marked batch. A measurement interval is not + defined by the duration of a marked batch of packets but the interval + between a pair of RFC6374 packets taking a readout of the delay + characteristic. This approach has the advantage that the measurement + is not impacted by ECMP effects. 9. Carrying RFC6374 Packets over an LSP using an SFL The packet format of an RFC6374 Query message using SFLs is shown in Figure 5. +-------------------------------+ | | | LSP | | Label | @@ -731,20 +729,23 @@ IANA is request to allocate a new TLV from the 0-127 range on the MPLS Loss/Delay Measurement TLV Object Registry: Type Description Reference ---- --------------------------------- --------- TBD Synonymous Flow Label This A value of 4 is recommended. + RFC Editor please delete this line + [RFC3032][I-D.bryant-mpls-sfl-control] + 15. References 15.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC3032] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y., @@ -760,68 +761,58 @@ [RFC6374] Frost, D. and S. Bryant, "Packet Loss and Delay Measurement for MPLS Networks", RFC 6374, DOI 10.17487/RFC6374, September 2011, . [RFC7876] Bryant, S., Sivabalan, S., and S. Soni, "UDP Return Path for Packet Loss and Delay Measurement for MPLS Networks", RFC 7876, DOI 10.17487/RFC7876, July 2016, . + [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC + 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, + May 2017, . + 15.2. Informative References [I-D.bryant-mpls-sfl-control] Bryant, S., Swallow, G., and S. Sivabalan, "MPLS Flow Identification Considerations", draft-bryant-mpls-sfl- control-02 (work in progress), October 2017. - [I-D.bryant-mpls-sfl-framework] + [I-D.ietf-mpls-sfl-framework] Bryant, S., Chen, M., Li, Z., Swallow, G., Sivabalan, S., and G. Mirsky, "Synonymous Flow Label Framework", draft- - bryant-mpls-sfl-framework-05 (work in progress), June - 2017. - - [I-D.chen-ippm-coloring-based-ipfpm-framework] - Chen, M., Zheng, L., Mirsky, G., Fioccola, G., and T. - Mizrahi, "IP Flow Performance Measurement Framework", - draft-chen-ippm-coloring-based-ipfpm-framework-06 (work in - progress), March 2016. - - [I-D.ietf-ippm-alt-mark] - Fioccola, G., Capello, A., Cociglio, M., Castaldelli, L., - Chen, M., Zheng, L., Mirsky, G., and T. Mizrahi, - "Alternate Marking method for passive and hybrid - performance monitoring", draft-ietf-ippm-alt-mark-13 (work - in progress), October 2017. - - [I-D.ietf-mpls-flow-ident] - Bryant, S., Pignataro, C., Chen, M., Li, Z., and G. - Mirsky, "MPLS Flow Identification Considerations", draft- - ietf-mpls-flow-ident-05 (work in progress), July 2017. - - [I-D.tempia-ippm-p3m] - Capello, A., Cociglio, M., Fioccola, G., Castaldelli, L., - and A. Bonda, "A packet based method for passive - performance monitoring", draft-tempia-ippm-p3m-03 (work in - progress), March 2016. + ietf-mpls-sfl-framework-03 (work in progress), June 2018. [RFC3270] Le Faucheur, F., Wu, L., Davie, B., Davari, S., Vaananen, P., Krishnan, R., Cheval, P., and J. Heinanen, "Multi- Protocol Label Switching (MPLS) Support of Differentiated Services", RFC 3270, DOI 10.17487/RFC3270, May 2002, . [RFC5921] Bocci, M., Ed., Bryant, S., Ed., Frost, D., Ed., Levrau, L., and L. Berger, "A Framework for MPLS in Transport Networks", RFC 5921, DOI 10.17487/RFC5921, July 2010, . + [RFC8321] Fioccola, G., Ed., Capello, A., Cociglio, M., Castaldelli, + L., Chen, M., Zheng, L., Mirsky, G., and T. Mizrahi, + "Alternate-Marking Method for Passive and Hybrid + Performance Monitoring", RFC 8321, DOI 10.17487/RFC8321, + January 2018, . + + [RFC8372] Bryant, S., Pignataro, C., Chen, M., Li, Z., and G. + Mirsky, "MPLS Flow Identification Considerations", + RFC 8372, DOI 10.17487/RFC8372, May 2018, + . + Authors' Addresses Stewart Bryant Huawei Email: stewart.bryant@gmail.com Mach Chen Huawei @@ -824,25 +815,25 @@ Mach Chen Huawei Email: mach.chen@huawei.com Zhenbin Li Huawei Email: lizhenbin@huawei.com + George Swallow - Cisco Systems + Southend Technical Center Email: swallow.ietf@gmail.com - Siva Sivabalan Cisco Systems Email: msiva@cisco.com Gregory Mirsky ZTE Corp. Email: gregimirsky@gmail.com