RFC 9571
Extension of RFC 6374-Based Performance Measurement Using Synonymous Flow Labels
Heading β¨
Okay bestie, this is RFC 9571, a Standards Track doc from May 2024 πΈ Its title is Extension of RFC 6374-Based Performance Measurement Using Synonymous Flow Labels. The main author is S. Bryant, Ed. from the University of Surrey, who's editing the doc. The rest of the crew is G. Swallow (Independent), M. Chen (Huawei), G. Fioccola (Huawei Technologies), and G. Mirsky (ZTE Corp.). The ISSN is 2070-1721. The header doesn't list any Obsoletes or Updates, so it's not replacing or changing any other RFC π
Abstract
okay so RFC 6374 is all about measuring loss and delay on Label Switched Paths (LSPs), mostly the ones used in MPLS Transport Profile (MPLS-TP) networks π¦ This doc takes those same performance measurements from flows on MPLS-TP and extends them to flows on generic MPLS LSPs π₯ It also lets loss and delay get measured on multipoint-to-point LSPs, and it adds some extra techniques so you can run more sophisticated measurements in both MPLS-TP and generic MPLS networks. We're literally leveling up the whole toolkit β¨
Status of This Memo
This is an Internet Standards Track document π
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community, and it went through public review and got approved for publication by the Internet Engineering Steering Group (IESG). If you want more info on Internet Standards, check out Section 2 of RFC 7841 π«Ά
For the current status of this document, any errata, and how to send feedback, go to https://www.rfc-editor.org/info/rfc9571 π
Copyright Notice
Copyright (c) 2024 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 (https://trustee.ietf.org/license-info) as they stand on the publication date. Please read these carefully, because they spell out your rights and restrictions for this document. Any Code Components pulled out of this document have to include the Revised BSD License text described in Section 4.e of the Trust Legal Provisions, and they come without warranty as described in the Revised BSD License π
Table of Contents
1. Introduction
2. Requirements Language
3. Packet Loss Measurement Using SFL
4. Single Packet Delay Measurement Using SFL
5. Data Service Packet Delay Measurement
6. Some Simplifying Rules
7. Multiple Packet Delay Characteristics
7.1. Method 1: Time Buckets
7.2. Method 2: Classic Standard Deviation
7.2.1. Multi-packet Delay Measurement Message Format
7.3. Per-Packet Delay Measurement
7.4. Average Delay
8. Sampled Measurement
9. Carrying Packets over an LSP Using an SFL
9.1. Extending RFC 6374 with SFL TLV
10. Combined Loss/Delay Measurement Using SFL
11. Privacy Considerations
12. Security Considerations
13. IANA Considerations
13.1. Allocation of MPLS Generalized Associated Channel (G-ACh)
Types
13.2. Allocation of MPLS Loss/Delay TLV Object
14. References
14.1. Normative References
14.2. Informative References
Acknowledgments
Contributors
Authors' Addresses1. Introduction β¨
okay so [RFC6374] was first built as an Operations, Administration, and Maintenance (OAM) protocol for MPLS Transport Profile (MPLS-TP) [RFC5921] LSPs π MPLS-TP only handles point-to-point and point-to-multipoint LSPs. This document explains how to use [RFC6374] in the generic MPLS case too, and it adds a bunch of more sophisticated measurements that work for both cases π¦
[RFC8372] lays out the need for flow identities when you use the packet loss measurements from [RFC6374]. The short version: [RFC6374] treats the loss measurement (LM) message as the packet accounting demarcation point, and that causes trouble that can mess up packet accounting in certain situations π For example:
- When a flow gets Equal-Cost Multipath (ECMP) treatment, packets can arrive out of order compared to the LM packet.
- When a flow gets ECMP treatment, packets can land on different hardware interfaces. So getting an LM packet on one interface has to trigger a packet accounting action on a different interface that might not even be co-located with it. This is a seriously hard technical problem to solve with the accuracy you need π
- Even without ECMP (for example, on RSVP-TE, MPLS-TP LSPs, and pseudowires (PWs)), local processing can be spread across several processor cores, which leads to synchronization problems.
- Link aggregation techniques [RFC7190] can also cause synchronization issues.
- Some forwarder implementations have a long pipeline between processing a packet and incrementing its associated counter, and that's another source of synchronization headaches.
One way to handle these synchronization issues is described in [RFC9341]. The packets get batched by the sender, and each batch gets marked somehow so the receiver can easily tell adjacent batches apart π§
There's also an extra problem when the LSP is multipoint-to-point, because MPLS doesn't include a source address in the packet π Network management operations need to measure packet loss between a source and a destination, so some source-specific information has to go into the packet to identify packet batches from a specific source.
[RFC8957] describes a way to encode per-flow instructions in an MPLS label stack using Synonymous Flow Labels (SFLs). Basically, labels that mimic the behavior of other labels provide the packet batch identifiers and let you do per-batch packet accounting πΈ This memo spells out how SFLs get used to perform packet loss and delay measurements as described in [RFC6374].
When this document uses the terms "performance measurement method," "Query," "packet," or "message," they mean a performance measurement method, Query, packet, or message as specified in [RFC6374] π
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 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here π
3. Packet Loss Measurement Using SFL β¨
The data service packets of the flow being instrumented get grouped into batches, and every packet in a batch is marked with the SFL [RFC8372] that matches that batch π¦ The sender counts how many packets are in the batch. Once the batch is done and the sender is confident that all of its packets have been received, the sender issues a Query message to find out how many actually arrived, and that tells it how many packets got lost π₯ The Query message is sent using the same SFL as the corresponding batch of data service packets. The format of the Query and Response packets is described in Section 9.
4. Single Packet Delay Measurement Using SFL π
[RFC6374] explains how to measure packet delay by measuring the transit time of a packet over an LSP π That kind of packet doesn't necessarily need to be carried over an SFL, since the delay over a particular LSP should be a function of the Traffic Class (TC) bits.
But when SFLs are being used to monitor packet loss, or when label-inferred scheduling is used [RFC3270], the SFL would be REQUIRED so the packet acting as a proxy for a data service packet gets a representative delay π«Ά The format of a packet carried over the LSP using an SFL is shown in Section 9.
5. Data Service Packet Delay Measurement β¨
Okay so, if you want to really dig into a packet flow and figure out the delay on a whole bunch of packets, sending a ton of proxy data service packets (see Section 4) is a big no-no π ββοΈ. So we need a way to measure the delay characteristics of a batch of packets directly. Main character energy π
Loss needs to be measured over long intervals, so the batch times for the two measurement types won't necessarily line up. That's why we use a technique that lets both measurements run at the same time while still being pretty independent of each other π¦. The independence part comes from the fact that the two batches can overlap in time. When that happens, either the delay batch gets cut short, or the loss time gets extended so all the counters can still be reconciled correctly π
Here's the situation in Figure 1 π
(Case 1) AAAAAAAAAABBBBBBBBBBAAAAAAAAAABBBBBBBBBB
SFL marking of a packet batch for loss measurement
(Case 2) AADDDDAAAABBBBBBBBBBAAAAAAAAAABBBBBBBBBB
SFL marking of a subset of the packets for delay
(Case 3) AAAAAAAADDDDBBBBBBBBAAAAAAAAAABBBBBBBBBB
SFL marking of a subset of the packets across a packet loss
measurement boundary
(Case 4) AACDCDCDAABBBBBBBBBBAAAAAAAAAABBBBBBBBBB
A case of multiple delay measurements within a packet loss
measurement
where
A and B are packets where loss is being measured.
C and D are packets where loss and delay are being measured.
Figure 1: Query Packet with SFLIn Case 1, we've got loss measurement all by itself on the flow being analyzed. Just for illustration, say there are 10 packets in each flow during the time interval being analyzed πΈ
Now Case 2, where we need to analyze a small batch of packets for delay π These get marked with a different SFL type, which means they're being monitored for both loss and delay. SFL=A is loss batch A, and SFL=D is a batch of packets being instrumented for delay. But SFL D is synonymous with SFL A, and SFL A is synonymous with the underlying Forwarding Equivalence Class (FEC) π§ So a packet marked "D" gets accumulated into the A loss batch, goes into the delay statistics, and gets forwarded as normal β¨ Whether it gets counted twice (once for loss and once for delay), or the two counters get reconciled during reporting, is up to whoever's running the system. That's a local matter π
Now Case 3, where a small batch gets marked for delay across a loss batch boundary π These packets have to count as part of batch A or part of batch B. And any Query has to wait until all the packets A or D (whichever option was chosen) have shown up at the receiving Label Switching Router (LSR) π«Ά
Now Case 4 π₯ This is where we want to take a bunch of delay measurements inside a batch of packets that we're already measuring for loss. To pull that off, we need two SFLs for delay (C and D), and we alternate between them, delay-batch by delay-batch, so we can measure the delay characteristics of the different batches of packets π
6. Some Simplifying Rules
There are so many ways to mix up overlapping measurement types, whether it's loss, delay, loss and delay together, or batch overlap. If we allowed every single combination, the configuration, testing, and implementation would get super complicated, and that means higher costs π So the following simplifying rules are the default case π
- Any system that needs to measure delay MUST be able to measure loss.
- Any system that is to measure delay MUST be configured to measure loss. Whether the loss statistics actually get collected is a local matter.
- A delay measurement MAY start at any point during a loss measurement batch, subject to rule 4.
- A delay measurement interval MUST be short enough that it will complete before the enclosing loss batch completes.
- The duration of a second delay batch (D in Figure 1) must be such that all packets from the packets belonging to a first delay batch (C in Figure 1) will have been received before the second delay batch completes. This condition is satisfied when the time to send a batch is long compared to the network propagation time, and it's a parameter the network operator can set π§
Since the sender controls both the start and the duration of a loss batch and a delay packet batch, these rules are pretty easy to implement in the control plane π¦
7. Multiple Packet Delay Characteristics
Okay, so there are a bunch of methods that add to the set of measurements originally specified in [RFC6374] π Each one has different characteristics and different processing demands on the packet forwarder. Which one you pick depends on the kind of diagnosis you're after π
Three methods get discussed:
- Time Buckets
- Classic Standard Deviation
- Average Delay
7.1. Method 1: Time Buckets
With this one, the receiving LSR measures the inter-packet gap, sorts the delay into a number of delay buckets, and records how many packets land in each bucket πͺ£ As an example, say the operator cares about packets with a delay of up to 1 ΞΌs, 2 ΞΌs, 4 ΞΌs, 8 ΞΌs, and over 8 ΞΌs. That gives five buckets, and a packet that arrives within 1 ΞΌs bumps up the "up to 1 ΞΌs" bucket counter. Same idea for packets arriving between 1 ΞΌs and 2 ΞΌs, which bump the "2 ΞΌs" counter, and so on β¨ Honestly, for processing and potential parallelism, it might be smarter to increment both the "up to 1 ΞΌs" and "2 ΞΌs" counters when a packet has a delay of 2 ΞΌs relative to its predecessor, and then calculate any more detailed info in the analytics system π§ββοΈ
This method lets the operator see more structure in the jitter than just measuring the average jitter, and it skips the hassle of doing a per-packet multiply π The catch is that the time intervals between buckets will probably need to be programmable by the operator π
The packet format of a Time Bucket Jitter Measurement message looks like this:
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Session Identifier | DS |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Number of | Reserved 1 |
| Buckets | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interval (in 10 ns units) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Number of Pkts in Bucket 1 |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Number of Pkts in Bucket N |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ ~
~ TLV Block ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: Time Bucket Jitter Measurement Message FormatThe Version, Flags, Control Code, Message Length, Querier Timestamp Format (QTF), Responder Timestamp Format (RTF), Responder's Preferred Timestamp Format (RPTF), Session Identifier, Reserved, and Differentiated Services (DS) fields are all defined in Section 3.2 of [RFC6374] π The rest of the fields are unsigned integers, and they work like this:
- Number of Buckets in the measurement.
- Reserved 1 must be sent as zero and ignored on receipt.
- Interval (in 10 ns units) is the inter-packet interval for this bucket.
- Number of Pkts in Bucket 1 is the number of packets found in the first bucket.
- Number of Pkts in Bucket N is the number of packets found in the Nth bucket, where N is the value in the Number of Buckets field.
There will be a number of Interval/Number pairs, depending on how many buckets the Querier specifies π If a message is being used to configure the buckets (so the responder is creating or modifying them according to the intervals in the Query message), then the responder MUST respond with 0 packets in each bucket until it has been configured for a full measurement period π«Ά That tells you it was configured at the time of the last response message, so the response is valid for the whole interval. And as per the convention in [RFC6374], 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 π¦
Heads up, this is a departure from the normal fixed format used in [RFC6374] β οΈ
The Time Bucket Jitter Measurement message gets carried over an LSP the way described in [RFC6374], and over an LSP with an SFL as described in Section 9.
7.2. Method 2: Classic Standard Deviation
This method makes room for reporting the following delay characteristics π
- Number of packets in the batch (n)
- Sum of delays in a batch (S)
- Maximum delay
- Minimum delay
- Sum of squares of inter-packet delay (SumS)
Characteristics 1 and 2 give you the mean delay. Measuring the delay of each pair in the batch is discussed in Section 7.3 π§
Characteristics 3 and 4 give you the outliers π
Characteristics 1, 2, and 5 can be used to calculate the variance of the inter-packet gap. From there, the standard deviation gives you a view of how the packet delays are distributed, and that's how you get the jitter π The equation for the variance (var) is:
var = (SumS - S*S/n)/(n-1)Not gonna lie, there's some concern about using this algorithm for measuring variance, because SumS and S*S/n can be really similar numbers, especially when the variance is low π₯Ί Even so, the method is acceptable, because it doesn't need a division in the hardware π₯
7.2.1. Multi-packet Delay Measurement Message Format
Okay bestie, here's the packet format for a Multi-packet Delay Measurement message π¦β¨
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Session Identifier | DS |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Number of Packets |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sum of Delays for Batch |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Minimum Delay |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Maximum Delay |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sum of squares of Inter-packet delay |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ ~
~ TLV Block ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Figure 3: Multi-packet Delay Measurement Message Format
Okay so the Version, Flags, Control Code, Message Length, QTF, RTF, RPTF, Session Identifier, Reserved, and DS fields are all exactly as defined in Section 3.2 of [RFC6374] π
. The remaining fields work like this:
Number of Packetsis the number of packets in this batch.Sum of Delays for Batchis the duration of the batch, in the time measurement format specified in theRTFfield.Minimum Delayis the minimum inter-packet gap observed during the batch, in the time format specified in theRTFfield.Maximum Delayis the maximum inter-packet gap observed during the batch, in the time format specified in theRTFfield.
The Multi-packet Delay Measurement message gets carried over an LSP the way [RFC6374] describes, and over an LSP with an SFL as described in Section 9 π.
7.3. Per-Packet Delay Measurement
If detailed packet delay measurement is required π, then it might be possible to record the inter-packet gap for each packet pair. But ngl, unless you're dealing with slow flows or small batch sizes, this would make a massive pile of per-packet demand on storage in the instrumentation system π. It would also need a big chunk of bandwidth for that storage system and a big chunk for the analytics system too. Such a measurement technique is outside the scope of this document π.
7.4. Average Delay
Introduced in [RFC9341] is the concept of a one-way delay measurement, where the average time of arrival of a set of packets is measured β¨. Here's the vibe: the packet gets timestamped on arrival, and the responder sends back the sum of the timestamps and the number of timestamps. From that, the analytics engine can figure out the mean delay π. There's also an alternative model where the responder returns the timestamp of the first and last packet, plus the number of packets. This latter method is iconic because it lets the average delay be determined at a number of points along the packet path, and it lets the components of the delay get characterized π§. Unless specifically configured otherwise, the responder may return either or both types of response, and the analytics engine should process the response appropriately π«Ά.
The packet format of an Average Delay Measurement message looks like this:
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Session Identifier | DS |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Number of Packets |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Time of First Packet |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Time of Last Packet |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sum of Timestamps of Batch |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ ~
~ TLV Block ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Figure 4: Average Delay Measurement Message Format
The Version, Flags, Control Code, Message Length, QTF, RTF, RPTF, Session Identifier, and DS fields are as defined in Section 3.2 of [RFC6374] π. The remaining fields are:
Number of Packetsis the number of packets in this batch.Time of First Packetis the time of arrival of the first packet in the batch.Time of Last Packetis the time of arrival of the last packet in the batch.Sum of Timestamps of Batch.
The Average Delay Measurement message gets carried over an LSP the way [RFC6374] describes, and over an LSP with an SFL as described in Section 9. As is the convention with [RFC6374], the Query message holds placeholders for the Response message πΈ. Those placeholders are sent as zero.
8. Sampled Measurement β¨
So far we've been assuming we'd measure the delay characteristics of every packet in a delay measurement interval defined by an SFL of constant color π . In [RFC9341], the concept of a sampled measurement gets considered. Basically, the responder only measures a packet at the start of a group of packets being marked for delay measurement by a particular color, instead of every packet in the marked batch π¦. A measurement interval isn't defined by the duration of a marked batch of packets. It's defined by the interval between a pair of packets taking a readout of the delay characteristic. This approach has the advantage that the measurement is not impacted by ECMP effects π.
This sampled approach may be used if supported by the responder and configured by the operator π.
9. Carrying Packets over an LSP Using an SFL π
We illustrate the packet format of a Query message using SFLs for the case of an MPLS Direct Loss Measurement in Figure 5 π§.
+-------------------------------+
| |
| LSP |
| Label |
+-------------------------------+
| |
| Synonymous Flow |
| Label |
+-------------------------------+
| |
| GAL |
| |
+-------------------------------+
| |
| ACH Type = 0xA |
| |
+-------------------------------+
| |
| Measurement Message |
| |
| +-------------------------+ |
| | | |
| | Fixed-format | |
| | portion of msg | |
| | | |
| +-------------------------+ |
| | | |
| | Optional SFL TLV | |
| | | |
| +-------------------------+ |
| | | |
| | Optional Return | |
| | Information | |
| | | |
| +-------------------------+ |
| |
+-------------------------------+Figure 5: Query Packet with SFL
The MPLS label stack is exactly the same as the one used for the user data service packets being instrumented, except for the inclusion of the Generic Associated Channel Label (GAL) [RFC5586]. The GAL lets the receiver tell normal data packets apart from OAM packets π. Since the packet loss measurements are being made on the data service packets, this is an MPLS Direct Loss Measurement, which gets indicated by the type field in the Associated Channel Header (ACH) (Type = 0x000A) π.
The measurement message has up to three components, like this:
- The fixed-format portion of the message is carried over the ACH channel. The ACH channel type tells you what type of measurement is happening (currently: loss, delay, or loss and delay) π.
- (Optional) The SFL TLV specified in Section 9.1 MAY be carried if needed. It gives the implementation a reminder of the SFL that was used to carry the message. This is needed because a bunch of MPLS implementations don't hand the MPLS label stack over to the MPLS OAM handler π. This TLV is required if messages are sent over UDP [RFC7876]. This TLV MUST be included unless, by some method outside the scope of this document, it is known that this information is not needed by the responder π«Ά.
- (Optional) The Return Information MAY be carried if needed. It lets the responder send the response back to the Querier π. This isn't needed if the response is requested in band and the MPLS construct being measured is a point-to-point LSP, but otherwise it MUST be carried. The Return Address TLV is defined in [RFC6374], and the optional UDP Return Object is defined in [RFC7876] π.
Where a measurement other than an MPLS Direct Loss Measurement is to be made, the appropriate measurement message is used (for example, one of the new types defined in this document). This gets indicated to the receiver by the use of the corresponding ACH type π₯.
Okay bestie, let's get into the juicy part of this RFC π β¨
9. Carrying Packets over an LSP Using an SFL π
9.1. Extending RFC 6374 with SFL TLV π¦
okay so the [RFC6374] SFL TLV is shown in Figure 6 below π it carries the SFL that rode along in the label stack, the FEC that was used to allocate that SFL, and the index (into the batch of SFLs that were allocated for the FEC) that matches this particular SFL. it's giving organized π§
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |MBZ| SFL Batch | SFL Index |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SFL | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| FEC |
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6: SFL TLVhere's the breakdown, no cap π
Type π Set to Synonymous Flow Label (SFL-TLV).
Length π The length of the TLV is as specified in [RFC6374].
MBZ π MUST be sent as zero and ignored on receive.
SFL Batch π An identifier for a collection of SFLs grouped together for management and control purposes.
SFL Index πΈ The index of this SFL within the list of SFLs that were assigned for the FEC.
ngl this one's a bit extra but I love it π multiple SFLs can be assigned to a FEC, each with different actions. this index is an optional convenience for mapping between the TLV and the associated data structures in the LSRs. the two parties agree on using it during configuration. it is not required, but it's a convenience for the receiver if both parties support the facility. π«Ά
SFL π¦ The SFL used to deliver this packet. this is an MPLS label that is a component of a label stack entry as defined in Section 2.1 of [RFC3032].
Reserved π MUST be sent as zero and ignored on receive.
FEC π The Forwarding Equivalence Class that was used to request this SFL. it's encoded as per Section 3.4.1 of [RFC5036].
why does any of this matter? because some hardware throws away the MPLS label stack before handing the rest to the OAM handler π so by including both the SFL and the FEC plus index into the array of allocated SFLs, a bunch of different implementation types are supported. periodt π
10. Combined Loss/Delay Measurement Using SFL πΈ
this mode of operation is not currently supported by this specification. not yet, bestie π₯Ί
11. Privacy Considerations π
okay this one's serious π including originating and/or flow information in a packet gives more identity info, so it can potentially hurt privacy. the extra granularity does give better insight into flow characteristics, but it doesn't specifically identify which node originated the packet. the only ways to find that out are inspecting the network at the point of ingress or inspecting the control protocol packets. this privacy threat may be mitigated by encrypting the control protocol packets, regularly changing the synonymous labels, and by concurrently using a number of such labels. π§π
12. Security Considerations π
the security considerations in [RFC6374] and [RFC8372] (which in turn calls up [RFC5920] and [RFC7258]) apply to this protocol π‘οΈ
the issue noted in Section 11 is a security consideration. there are no other new security issues associated with the MPLS data plane. any control protocol used to request SFLs will need to ensure the legitimacy of the request. π¨
β οΈ bestie, listen up: an attacker that manages to corrupt the [RFC6374] SFL TLV in Section 9.1 could disrupt the measurements in a way that the [RFC6374] responder is unable to detect. the network operator is likely to notice the anomalous network performance measurements, and in any case, normal MPLS network security procedures make this type of attack extremely unlikely. π±
13. IANA Considerations π
13.1. Allocation of MPLS Generalized Associated Channel (G-ACh) Types π
as per the IANA considerations in [RFC5586] updated by [RFC7026] and [RFC7214], IANA has allocated the following values in the "MPLS Generalized Associated Channel (G-ACh) Types" registry, in the "Generic Associated Channel (G-ACh) Parameters" registry group:
+========+================================+===========+
| Value | Description | Reference |
+========+================================+===========+
| 0x0010 | Time Bucket Jitter Measurement | RFC 9571 |
+--------+--------------------------------+-----------+
| 0x0011 | Multi-packet Delay Measurement | RFC 9571 |
+--------+--------------------------------+-----------+
| 0x0012 | Average Delay Measurement | RFC 9571 |
+--------+--------------------------------+-----------+
Table 113.2. Allocation of MPLS Loss/Delay TLV Object π¦
IANA has allocated the following TLV from the 0-127 range of the "MPLS Loss/Delay Measurement TLV Object" registry in the "Generic Associated Channel (G-ACh) Parameters" registry group:
+======+=======================+===========+
| Type | Description | Reference |
+======+=======================+===========+
| 4 | Synonymous Flow Label | RFC 9571 |
+------+-----------------------+-----------+
Table 214. References π
14.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, <https://www.rfc-editor.org/info/rfc2119>.
[RFC3032] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y., Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack Encoding", RFC 3032, DOI 10.17487/RFC3032, January 2001, <https://www.rfc-editor.org/info/rfc3032>.
[RFC5036] Andersson, L., Ed., Minei, I., Ed., and B. Thomas, Ed., "LDP Specification", RFC 5036, DOI 10.17487/RFC5036, October 2007, <https://www.rfc-editor.org/info/rfc5036>.
[RFC5586] Bocci, M., Ed., Vigoureux, M., Ed., and S. Bryant, Ed., "MPLS Generic Associated Channel", RFC 5586, DOI 10.17487/RFC5586, June 2009, <https://www.rfc-editor.org/info/rfc5586>.
[RFC6374] Frost, D. and S. Bryant, "Packet Loss and Delay Measurement for MPLS Networks", RFC 6374, DOI 10.17487/RFC6374, September 2011, <https://www.rfc-editor.org/info/rfc6374>.
[RFC7026] Farrel, A. and S. Bryant, "Retiring TLVs from the Associated Channel Header of the MPLS Generic Associated Channel", RFC 7026, DOI 10.17487/RFC7026, September 2013, <https://www.rfc-editor.org/info/rfc7026>.
[RFC7214] Andersson, L. and C. Pignataro, "Moving Generic Associated Channel (G-ACh) IANA Registries to a New Registry", RFC 7214, DOI 10.17487/RFC7214, May 2014, <https://www.rfc-editor.org/info/rfc7214>.
[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, <https://www.rfc-editor.org/info/rfc7876>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8957] Bryant, S., Chen, M., Swallow, G., Sivabalan, S., and G. Mirsky, "Synonymous Flow Label Framework", RFC 8957, DOI 10.17487/RFC8957, January 2021, <https://www.rfc-editor.org/info/rfc8957>.
14.2. Informative References π§
[RFC3270] Le Faucheur, F., Ed., 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, <https://www.rfc-editor.org/info/rfc3270>.
[RFC5920] Fang, L., Ed., "Security Framework for MPLS and GMPLS Networks", RFC 5920, DOI 10.17487/RFC5920, July 2010, <https://www.rfc-editor.org/info/rfc5920>.
[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, <https://www.rfc-editor.org/info/rfc5921>.
[RFC7190] Villamizar, C., "Use of Multipath with MPLS and MPLS Transport Profile (MPLS-TP)", RFC 7190, DOI 10.17487/RFC7190, March 2014, <https://www.rfc-editor.org/info/rfc7190>.
[RFC7258] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an Attack", BCP 188, RFC 7258, DOI 10.17487/RFC7258, May 2014, <https://www.rfc-editor.org/info/rfc7258>.
[RFC8372] Bryant, S., Pignataro, C., Chen, M., Li, Z., and G. Mirsky, "MPLS Flow Identification Considerations", RFC 8372, DOI 10.17487/RFC8372, May 2018, <https://www.rfc-editor.org/info/rfc8372>.
[RFC9341] Fioccola, G., Ed., Cociglio, M., Mirsky, G., Mizrahi, T., and T. Zhou, "Alternate-Marking Method", RFC 9341, DOI 10.17487/RFC9341, December 2022, <https://www.rfc-editor.org/info/rfc9341>.
Acknowledgments π«Ά
the authors thank Benjamin Kaduk and Elwyn Davies for their thorough and thoughtful review of this document. they really did the most π
Contributors πΈ
Zhenbin Li Huawei Email: lizhenbin@huawei.com
Siva Sivabalan Ciena Corporation Email: ssivabal@ciena.com
Authors' Addresses π
Stewart Bryant (editor) University of Surrey Email: sb@stewartbryant.com
George Swallow Independent Email: swallow.ietf@gmail.com
Mach(Guoyi) Chen Huawei Email: mach.chen@huawei.com
Giuseppe Fioccola Huawei Technologies Email: giuseppe.fioccola@huawei.com
Gregory Mirsky ZTE Corp. Email: gregimirsky@gmail.com
π¦ where this page comes from
- ietf: rfc9571 2024-05
- π girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms