RFC 7456
Loss and Delay Measurement in Transparent Interconnection of Lots of Links (TRILL)
RFC 7456: Loss and Delay Measurement in TRILL 🎀
okay bestie, this one is RFC 7456 and it's all about Loss and Delay Measurement in Transparent Interconnection of Lots of Links (TRILL) 🦋. It's a Standards Track doc from the IETF, dated March 2015, with ISSN 2070-1721. The authors are T. Mizrahi from Marvell, T. Senevirathne, S. Salam, and D. Kumar from Cisco, and D. Eastlake 3rd from Huawei 💅. It doesn't list anything it obsoletes or updates, so there's no drama there ✨.
Abstract 🌸
Performance Monitoring (PM) is a huge part of Operations, Administration, and Maintenance (OAM) 💖. Network operators use it to check that the Service Level Agreement (SLA) they promised customers is actually being met, and to catch weird network anomalies 👀. This document specifies the mechanisms for Loss Measurement and Delay Measurement in TRILL networks 🧚.
Status of This Memo 🌈
This is an Internet Standards Track document 🔥.
It's a product of the Internet Engineering Task Force (IETF), and it represents the consensus of the IETF community. It went through public review and got approved for publication by the Internet Engineering Steering Group (IESG) 🙌. For more on Internet Standards, check out Section 2 of RFC 5741.
Info about the current status of this document, any errata, and how to send feedback lives at http://www.rfc-editor.org/info/rfc7456 🍓.
Copyright Notice 💜
Copyright (c) 2015 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. Please read these carefully, because they spell out 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 they're provided without warranty as described in the Simplified BSD License 💅.
Table of Contents 🧭
1. Introduction ....................................................3
2. Conventions Used in this Document ...............................4
2.1. Key Words ..................................................4
2.2. Definitions ................................................4
2.3. Abbreviations ..............................................5
3. Loss and Delay Measurement in the TRILL Architecture ............6
3.1. Performance Monitoring Granularity .........................6
3.2. One-Way vs. Two-Way Performance Monitoring .................6
3.2.1. One-Way Performance Monitoring ......................7
3.2.2. Two-Way Performance Monitoring ......................7
3.3. Point-to-Point vs. Point-to-Multipoint PM ..................8
4. Loss Measurement ................................................8
4.1. One-Way Loss Measurement ...................................8
4.1.1. 1SL Message Transmission ............................9
4.1.2. 1SL Message Reception ..............................10
4.2. Two-Way Loss Measurement ..................................11
4.2.1. SLM Message Transmission ...........................12
4.2.2. SLM Message Reception ..............................12
4.2.3. SLR Message Reception ..............................13
5. Delay Measurement ..............................................14
5.1. One-Way Delay Measurement .................................14
5.1.1. 1DM Message Transmission ...........................15
5.1.2. 1DM Message Reception ..............................16
5.2. Two-Way Delay Measurement .................................16
5.2.1. DMM Message Transmission ...........................17
5.2.2. DMM Message Reception ..............................17
5.2.3. DMR Message Reception ..............................18
6. Packet Formats .................................................19
6.1. TRILL OAM Encapsulation ...................................19
6.2. Loss Measurement Packet Formats ...........................21
6.2.1. Counter Format .....................................21
6.2.2. 1SL Packet Format ..................................21
6.2.3. SLM Packet Format ..................................22
6.2.4. SLR Packet Format ..................................23
6.3. Delay Measurement Packet Formats ..........................24
6.3.1. Timestamp Format ...................................24
6.3.2. 1DM Packet Format ..................................24
6.3.3. DMM Packet Format ..................................25
6.3.4. DMR Packet Format ..................................26
6.4. OpCode Values .............................................27
7. Performance Monitoring Process .................................28
8. Security Considerations ........................................29
9. References .....................................................29
9.1. Normative References ......................................29
9.2. Informative References ....................................30
Acknowledgments ...................................................31
Authors' Addresses ................................................321. Introduction ✨
TRILL [TRILL] is a protocol for transparent least-cost routing 🚀. Routing Bridges (RBridges) send traffic to its destination based on least cost, and they do it using a TRILL encapsulation header with a hop count.
Operations, Administration, and Maintenance [OAM] is basically a toolbox for detecting, isolating, and reporting connection failures and performance degradation 🧰. Performance Monitoring (PM) is a key part of OAM. It helps network operators detect and debug network anomalies and incorrect behavior. PM has two main building blocks: Loss Measurement and Delay Measurement. PM may also include other derived metrics, like Packet Delivery Rate and Inter-Frame Delay Variation 📊.
The OAM requirements for TRILL networks are defined in [OAM-REQ], and the TRILL OAM framework is described in [OAM-FRAMEWK]. Both of those documents also highlight the main PM requirements 💅.
This document defines protocols for Loss Measurement and Delay Measurement in TRILL networks. These protocols are based on the PM functionality defined in ITU-T G.8013/Y.1731 [Y.1731-2013] 🎀.
- Loss Measurement 📉: the Loss Measurement protocol measures packet loss between two RBridges. It works by sending a set of synthetic packets and counting how many were transmitted and received during the test. The frame loss is calculated by comparing those two numbers. This gives a statistical estimate of the packet loss between the involved RBridges, and the margin of error can be controlled by varying how many synthetic packets get transmitted. This document does not define procedures for packet loss computation based on counting user data, for the reasons given in Section 5.1 of [OAM-FRAMEWK] 🙅.
- Delay Measurement ⏱️: the Delay Measurement protocol measures packet delay and packet delay variation between two RBridges. It's done using timestamped OAM messages 🧡.
2. Conventions Used in this Document 📚
2.1. Key Words
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [KEYWORDS] 🔑.
The requirement level of PM in [OAM-REQ] is 'SHOULD'. Nevertheless, this memo uses the entire range of requirement levels, including 'MUST'. So the requirements in this memo are to be read as 'A MEP (Maintenance End Point) that implements TRILL PM MUST/SHOULD/MAY/...' 💜.
2.2. Definitions
- One-way packet delay (based on [IPPM-1DM]) ⏳: the time elapsed from the start of transmission of the first bit of a packet by an RBridge until the reception of the last bit of the packet by the remote RBridge.
- Two-way packet delay (based on [IPPM-2DM]) 🔁: the time elapsed from the start of transmission of the first bit of a packet from the local RBridge, through the receipt of the packet at the remote RBridge, the transmission of a response packet from the remote RBridge back to the local RBridge, and the receipt of the last bit of that response packet by the local RBridge.
- Packet loss (based on [IPPM-Loss]) 🫥: the number of packets sent by a source RBridge and not received by the destination RBridge. In the context of this document, packet loss is measured at a specific probe instance and a specific observation period. As in [Y.1731-2013], this document distinguishes between near-end and far-end packet loss. Note that this semantic distinction specifies the direction of packet loss but does not affect the nature of the packet loss metric, which is defined in [IPPM-Loss] 🧐.
- Far-end packet loss ➡️: the number of packets lost on the path from the local RBridge to the remote RBridge in a specific probe instance and a specific observation period.
- Near-end packet loss ⬅️: the number of packets lost on the path from the remote RBridge to the local RBridge in a specific probe instance and a specific observation period.
2.3. Abbreviations
Here's the full abbreviation list, no skipping 📝:
1DM One-way Delay Measurement
1SL One-way Synthetic Loss Measurement
DMM Delay Measurement Message
DMR Delay Measurement Reply
DoS Denial of Service
FGL Fine-Grained Label [FGL]
MD Maintenance Domain
MD-L Maintenance Domain Level
MEP Maintenance End Point
MIP Maintenance Intermediate Point
MP Maintenance Point
OAM Operations, Administration, and Maintenance [OAM]
PM Performance Monitoring
SLM Synthetic Loss Measurement Message
SLR Synthetic Loss Measurement Reply
TLV Type-Length-Value
TRILL Transparent Interconnection of Lots of Links [TRILL]3. Loss and Delay Measurement in the TRILL Architecture 🦋
As described in [OAM-FRAMEWK], OAM protocols in a TRILL campus operate over two types of Maintenance Points (MPs): Maintenance End Points (MEPs) and Maintenance Intermediate Points (MIPs) 🗺️.
+-------+ +-------+ +-------+
| | | | | |
| RB1 |<===>| RB3 |<===>| RB2 |
| | | | | |
+-------+ +-------+ +-------+
MEP MIP MEP
Figure 1: Maintenance Points in a TRILL CampusPerformance Monitoring (PM) lets a MEP run Loss and Delay Measurements on any other MEP in the campus 🫶. PM is always performed in the context of a specific Maintenance Domain (MD).
The PM functionality defined in this document is not applicable to MIPs 🙅♀️.
3.1. Performance Monitoring Granularity 🔍
okay so, as [OAM-FRAMEWK] explains, PM can run at three levels of granularity: Network, Service, and Flow. Think of it like zooming in on a map 🗺️
- Network-level PM: the PM protocol runs over a dedicated test VLAN or FGL [FGL].
- Service-level PM: the PM protocol measures actual user VLANs or FGLs. 💅
- Flow-level PM: the PM protocol measures things on a per-flow basis. A flow, as defined in [OAM-REQ], is a set of packets that share the same path and per-hop behavior (such as priority). As defined in [OAM-FRAMEWK], flow-based monitoring uses a Flow Entropy field that sits at the beginning of the OAM packet header (see Section 6.1) and copies the forwarding behavior of the monitored flow. It's giving precision 🎯
3.2. One-Way vs. Two-Way Performance Monitoring 🦋
Okay this one is so real. Paths in a TRILL network are not necessarily symmetric. That means a packet sent from RB1 to RB2 doesn't have to go through the same RBridges or links as a packet sent from RB2 to RB1. Even inside a single flow, packets going RB1 to RB2 can take a different path than packets going RB2 to RB1. Not the same route both ways, bestie 🙈
3.2.1. One-Way Performance Monitoring
In one-way PM, RB1 sends PM messages to RB2, so RB2 can monitor the performance on the path from RB1 to RB2. ✨
A MEP that implements TRILL PM SHOULD support one-way Performance Monitoring. A MEP that implements TRILL PM SHOULD support both the PM functionality of the sender, RB1, and the PM functionality of the receiver, RB2. 🫶
One-way PM can be applied either proactively or on-demand. The more typical scenario is the proactive mode, where RB1 and RB2 periodically send PM messages to each other, so each of them can monitor the performance on the incoming path from the peer MEP. 🌸
3.2.2. Two-Way Performance Monitoring 🔁
In two-way PM, a sender, RB1, sends PM messages to a reflector, RB2, and RB2 responds to them. This lets RB1 monitor the performance of:
- The path from RB1 to RB2.
- The path from RB2 to RB1.
- The two-way path from RB1 to RB2, and back to RB1.
Sometimes it's interesting for RB1 to monitor only the path from RB1 to RB2. Two-way PM lets the sender, RB1, monitor the path from RB1 to RB2, whereas one-way PM (Section 3.2.1) lets the receiver, RB2, monitor this path. 👑
A MEP that implements TRILL PM MUST support two-way PM. A MEP that implements TRILL PM MUST support both the sender and the reflector PM functionality. 💜
As described in Section 3.1, flow-based PM uses the Flow Entropy field as one of the parameters that identify a flow. In two-way PM, the Flow Entropy of the path from RB1 to RB2 is typically different from the Flow Entropy of the path from RB2 to RB1. This document uses the Reflector Entropy TLV [TRILL-FM], which lets the sender specify the Flow Entropy value to be used in the response message. 🧚
Two-way PM can be applied either proactively or on-demand. ⭐
3.3. Point-to-Point vs. Point-to-Multipoint PM 📡
PM can be applied either as a point-to-point measurement protocol, or as a point-to-multipoint measurement protocol. Two shapes, same vibe ✨
The point-to-point approach measures the performance between two RBridges using unicast PM messages. 💖
In the point-to-multipoint approach, an RBridge RB1 sends PM messages to multiple RBridges using multicast messages. The reflectors (in two-way PM) respond to RB1 using unicast messages. To protect against reply storms, the reflectors MUST send the response messages after a random delay in the range of 0 to 2 seconds. This keeps the responses staggered in time, so the initiating RBridge doesn't get overwhelmed with replies. 😭 Moreover, an RBridge Scope TLV [TRILL-FM] can be used to limit the set of RBridges from which a response is expected, which cuts down the impact of potential response bursts. 🍓
4. Loss Measurement 🧮
The Loss Measurement protocol has two modes of operation: one-way Loss Measurement and two-way Loss Measurement. Two modes, one goal: find the lost packets 🕵️♀️
Note: The terms 'one-way' and 'two-way' Loss Measurement should not be confused with the terms 'single-ended' and 'dual-ended' Loss Measurement used in [Y.1731-2013]. As defined in Section 3.2, the terms 'one-way' and 'two-way' specify whether the protocol monitors performance on one direction or on both directions. The terms 'single-ended' and 'dual-ended', on the other hand, describe whether the protocol is asymmetric or symmetric, respectively. 🙃
4.1. One-Way Loss Measurement 🌊
One-way Loss Measurement measures the one-way packet loss from one MEP to another. The loss ratio is measured using a set of One-way Synthetic Loss Measurement (1SL) messages. The packet format of the 1SL message is specified in Section 6.2.2. Figure 2 shows a one-way Loss Measurement message exchange.
TXp TXc
Sender --------------------------------------
\ \
\ 1SL . . . \ 1SL
\ \
\/ \/
Receiver --------------------------------------
RXp RXc
Figure 2: One-Way Loss MeasurementThe one-way Loss Measurement procedure uses a set of 1SL messages to measure packet loss. The figure shows two non-consecutive messages from the set. 🎬
The sender keeps a counter of transmitted 1SL messages, and puts the value of this counter, TX, into each 1SL message it transmits. The receiver keeps a counter of received 1SL messages, RX, and can calculate the loss by comparing its counter values to the counter values received in the 1SL messages. 🧠
In Figure 2, the subscript 'c' is short for current, and 'p' is short for previous. 🍰
4.1.1. 1SL Message Transmission 🚀
One-way Loss Measurement can be applied either proactively or on-demand. As mentioned in Section 3.2.1, it's more likely to be applied proactively, though. 💫
The term 'on-demand' in the context of one-way Loss Measurement implies that the sender transmits a fixed set of 1SL messages, allowing the receiver to perform the measurement based on this set. 🎯
A MEP that supports one-way Loss Measurement MUST support unicast transmission of 1SL messages.
A MEP that supports one-way Loss Measurement MAY support multicast transmission of 1SL messages. 🌈
The sender MUST maintain a packet counter for each peer MEP and probe instance (test ID). Every time the sender transmits a 1SL packet, it increments the corresponding counter and then puts the value of the counter into the Counter TX field of the 1SL packet. 🔢
The 1SL message MAY be sent with a variable-size Data TLV, so Loss Measurement can work for various packet sizes. 🎀
4.1.2. 1SL Message Reception 📥
The receiver MUST maintain a reception counter for each peer MEP and probe instance (test ID). When a 1SL packet arrives, the receiver MUST verify that:
- The 1SL packet is destined to the current MEP.
- The packet's MD level matches the MEP's MD level.
If both conditions are satisfied, the receiver increments the corresponding reception counter and records the new value of the counter, RX1. 🙌
A MEP that supports one-way Loss Measurement MUST support reception of both unicast and multicast 1SL messages. 🫧
The receiver computes the one-way packet loss with respect to a probe instance measurement interval. A probe instance measurement interval includes a sequence of 1SL messages with the same test ID. The one-way packet loss is computed by comparing the counter values TXp and RXp at the beginning of the measurement interval with the counter values TXc and RXc at the end of the measurement interval (see Figure 2):
one-way packet loss = (TXc-TXp) - (RXc-RXp) (1)The calculation in Equation (1) is based on counter value differences. That means the sender's counter, TX, and the receiver's counter, RX, don't need to be synchronized to a common initial value. 🤝
Heads up, though: if the sender or receiver resets one of the counters, TX or RX, the calculation in Equation (1) produces a false measurement result. So the sender and receiver SHOULD NOT clear the TX and RX counters during a measurement interval. 🚫
When the receiver calculates the packet loss per Equation (1), it MUST perform a wraparound check. If the receiver detects that one of the counters has wrapped around, the receiver adjusts the result of Equation (1) accordingly. 🔄
A 1SL receiver MUST support reception of 1SL messages with a Data TLV. 📦
Since synthetic one-way Loss Measurement is performed using 1SL messages, some 1SL messages may obviously be dropped during a measurement interval. So when the receiver doesn't receive a 1SL, it can't perform the calculations in Equation (1) for that specific 1SL message. Lost is lost, periodt 😭
4.2. Two-Way Loss Measurement 🪞
Two-way Loss Measurement lets a MEP measure the packet loss on the paths to and from a peer MEP. It uses a set of Synthetic Loss Measurement Messages (SLMs) to compute the packet loss. Each SLM is answered with a Synthetic Loss Measurement Reply (SLR). The packet formats of the SLM and SLR packets are specified in Sections 6.2.3 and 6.2.4, respectively. Figure 3 shows a two-way Loss Measurement message exchange. 💌
TXp RXp TXc RXc
Sender -----------------------------------------------
\ /\ \ /\
\ / . . . \ /
SLM \ / SLR SLM \ / SLR
\/ / \/ /
Reflector -----------------------------------------------
TRXp TRXc
Figure 3: Two-Way Loss MeasurementThe two-way Loss Measurement procedure uses a set of SLM-SLR handshakes. The figure shows two non-consecutive handshakes from the set. 🤍
The sender keeps a counter of transmitted SLM messages and puts the value of this counter, TX, into each transmitted SLM message. The reflector keeps a counter of received SLM messages, TRX. The reflector generates an SLR and puts TRX into the SLR packet. The sender keeps a counter of received SLR messages, RX. When an SLR message arrives, the sender can calculate the loss by comparing its local counter values to the counter values received in the SLR messages. 🎉
The subscript 'c' is short for current, and 'p' is short for previous. ✌️
4.2.1. SLM Message Transmission 📤
Two-way Loss Measurement can be applied either proactively or on-demand. 🌟
A MEP that supports two-way Loss Measurement MUST support unicast transmission of SLM messages.
A MEP that supports two-way Loss Measurement MAY support multicast transmission of SLM messages. 🎈
The sender MUST maintain a counter of transmitted SLM packets for each peer MEP and probe instance (test ID). Every time the sender transmits an SLM packet, it increments the corresponding counter and then puts the value of the counter into the Counter TX field of the SLM packet. 💅
A sender MAY include a Reflector Entropy TLV in an SLM message. The Reflector Entropy TLV format is specified in [TRILL-FM]. 🧩
An SLM message MAY be sent with a Data TLV, so Loss Measurement can work for various packet sizes. 🦄
4.2.2. SLM Message Reception ✨
okay bestie, the reflector MUST keep a reception counter called TRX for every peer MEP and every probe instance (that's the test ID) 🎀
when an SLM packet shows up, the reflector MUST check that:
- The SLM packet is destined to the current MEP.
- The packet's MD level matches the MEP's MD level.
if both of those are true, the reflector bumps the matching packet counter and records the new TRX value 🦋 then it makes an SLR message that's basically a twin of the SLM, with these glow-ups:
- The reflector puts
TRXinto the Counter TRX field of the SLR. - The OpCode field in the OAM header gets set to the SLR OpCode.
- The reflector drops its MEP ID into the Reflector MEP ID field.
- If the received SLM has a Reflector Entropy TLV [TRILL-FM], the reflector copies the Flow Entropy value from that TLV into the Flow Entropy field of the SLR. the outgoing SLR does NOT carry a Reflector Entropy TLV 🙈
- The TRILL Header and transport header get updated so they match the source and destination of the SLR packet. the SLR is always a unicast message 💌
a MEP that supports two-way Loss Measurement MUST support receiving both unicast and multicast SLM messages 🌸
and a reflector MUST support receiving SLM packets that carry a Data TLV. when it gets one, the reflector includes the unmodified TLV in the SLR 💅
4.2.3. SLR Message Reception 💜
the sender MUST keep a reception counter, RX, for each peer MEP and probe instance (test ID) 🌈
when an SLR message arrives, the sender MUST check that:
- The SLR packet is destined to the current MEP.
- The Sender MEP ID field in the SLR packet matches the current MEP.
- The packet's MD level matches the MEP's MD level.
if the conditions above are met, the sender bumps the matching reception counter and records the new value, RX ✨
here's the fun part: the sender works out packet loss for a probe instance measurement interval. a probe instance measurement interval is a whole bunch of SLM messages plus their matching SLR messages, all with the same test ID 🧚 the loss is found by comparing the counters at the start of the interval (marked with a subscript 'p') against the counters at the end of the interval (marked with a subscript 'c'), as shown in Figure 3 😭
far-end packet loss = (TXc-TXp) - (TRXc-TRXp) (2)
near-end packet loss = (TRXc-TRXp) - (RXc-RXp) (3)Note: the total two-way packet loss is the sum of the far-end and near-end packet losses, that is, (TXc-TXp) - (RXc-RXp) 🍓
these two equations are all about counter differences, so the sender's counters (TX and RX) and the reflector's counter (TRX) do NOT have to be synced to a shared starting value. no drama 🫶
⚠️ bestie, listen up: if the sender or reflector resets any of the counters (TX,TRX, orRX), Equations (2) and (3) give a FALSE result. so the sender and reflector SHOULD NOT clear theTX,TRX, andRXcounters during a measurement interval 💀
when the sender calculates packet loss with Equations (2) and (3), it MUST do a wraparound check. if the reflector spots that one of the counters has wrapped around, the reflector adjusts the result of Equations (2) and (3) to match 🔥
since synthetic two-way Loss Measurement runs on SLM and SLR messages, some of them can get dropped during a measurement interval, obviously 🙃 when an SLM or an SLR gets dropped, the matching two-way handshake (Figure 3) doesn't finish, so the reflector skips the Equations (2) and (3) math for that exchange 🦋
a sender MAY choose to only monitor far-end packet loss, meaning it runs Equation (2) and ignores Equation (3). in that case, the sender can run flow-based PM of the path to the peer MEP without using the Reflector Entropy TLV 👑
5. Delay Measurement 🎀
the Delay Measurement protocol comes in two flavors: one-way Delay Measurement and two-way Delay Measurement 🌸
5.1. One-Way Delay Measurement 🦋
one-way Delay Measurement figures out the one-way packet delay going from one MEP to another. the packet format for one-way Delay Measurement is called 1DM and it's specified in Section 6.3.2. the one-way Delay Measurement message exchange is shown in Figure 4 ✨
T1
Sender ------------------- ----> time
\
\ 1DM
\
\/
Receiver -------------------
T2
Figure 4: One-Way Delay Measurementthe sender sends a 1DM message that carries its time of transmission, T1. the receiver gets the message at time T2 and works out the one-way delay like this:
one-way delay = T2-T1 (4)Equation (4) assumes that T2 and T1 are measured against a common reference time. so two MEPs running a one-way Delay Measurement protocol MUST be time-synchronized 🕰️ how they sync their clocks is outside the scope of this document, so that's not my problem here 🙈
5.1.1. 1DM Message Transmission 💌
1DM packets can go out proactively or on-demand. but as Section 3.2.1 mentioned, they're usually sent proactively 🌈
a MEP that supports one-way Delay Measurement MUST support unicast transmission of 1DM messages 💅
a MEP that supports one-way Delay Measurement MAY support multicast transmission of 1DM messages ✨
a 1DM message MAY be sent with a variable size Data TLV, so you can measure delay for different packet sizes 🧚
the sender puts the 1DM packet's time of transmission into the Timestamp T1 field 💖
5.1.2. 1DM Message Reception 🫶
when a 1DM packet arrives, the receiver records its time of reception, T2. the receiver MUST check two things:
- The 1DM packet is destined to the current MEP.
- The packet's MD level matches the MEP's MD level.
if both are true, the receiver terminates the packet and calculates the one-way delay as shown in Equation (4) 👑
a MEP that supports one-way Delay Measurement MUST support receiving both unicast and multicast 1DM messages 🌸
a 1DM receiver MUST support receiving 1DM messages that carry a Data TLV 🎀
when one-way Delay Measurement packets come in periodically, the receiver MAY compute the packet delay variation based on several measurements. and get this: packet delay variation can still be computed even when the two peer MEPs are NOT time-synchronized 🤯
5.2. Two-Way Delay Measurement 💜
two-way Delay Measurement uses a two-way handshake to work out the two-way packet delay between two MEPs. the handshake has two packets: a Delay Measurement Message (DMM) and a Delay Measurement Reply (DMR). the DMM and DMR packet formats are specified in Sections 6.3.3 and 6.3.4, respectively 🦋
the two-way Delay Measurement message exchange is shown in Figure 5 🔥
T1 T4
Sender ----------------------- ----> time
\ /\
\ /
DMM \ / DMR
\/ /
Reflector -----------------------
T2 T3
Figure 5: Two-Way Delay Measurementthe sender generates a DMM message that carries its time of transmission, T1. the reflector receives the DMM and records its time of reception, T2. then the reflector makes a DMR message that carries T1, T2, and the DMR's transmission time, T3. the sender receives the DMR at T4 and uses those four timestamps to calculate the two-way packet delay 🧚
5.2.1. DMM Message Transmission ✨
DMM packets can be sent periodically or on-demand 💅
a MEP that supports two-way Delay Measurement MUST support unicast transmission of DMM messages 🌈
a MEP that supports two-way Delay Measurement MAY support multicast transmission of DMM messages 🍓
a sender MAY include a Reflector Entropy TLV in a DMM message. the Reflector Entropy TLV format is specified in [TRILL-FM] 🫶
a DMM MAY be sent with a variable size Data TLV, so you can measure packet delay for various packet sizes 💖
the sender puts the DMM packet's time of transmission into the Timestamp T1 field 🎀
5.2.2. DMM Message Reception 👑
when a DMM packet arrives, the reflector records its time of reception, T2. the reflector MUST check two things:
- The DMM packet is destined to the current MEP.
- The packet's MD level matches the MEP's MD level.
if both are satisfied, the reflector terminates the packet and generates a DMR packet. the DMR is identical to the received DMM, except for these changes:
- The reflector puts T2 into the Timestamp T2 field of the DMR.
- The reflector puts the DMR's transmission time, T3, into the Timestamp T3 field of the DMR.
- The OpCode field in the OAM header is set to the DMR OpCode.
- If the received DMM includes a Reflector Entropy TLV [TRILL-FM], the reflector copies the Flow Entropy value from the TLV into the Flow Entropy field of the DMR message. the outgoing DMR message does NOT include a Reflector Entropy TLV.
- The TRILL Header and transport header get updated to match the source and destination of the DMR packet. the DMR is always a unicast message 💌
a MEP that supports two-way Delay Measurement MUST support receiving both unicast and multicast DMM messages 🌸
and a reflector MUST support receiving DMM packets that carry a Data TLV. when it gets one, the reflector includes the unmodified TLV in the DMR 💅🦋
5.2.3. DMR Message Reception ✨
Okay so, when the DMR lands, the sender stamps its arrival time as T4 💌. Before doing any math, though, the sender MUST verify:
- The DMR packet is destined to the current MEP. 🎯
- The packet's MD level matches the MEP's MD level. 📏
If both checks pass, the sender uses all four timestamps to work out the two-way delay 🧮✨:
two-way delay = (T4-T1) - (T3-T2) (5)Two-way delay can be computed even when the two peer MEPs are not time-synchronized 🙌. One-way Delay Measurement is the one that needs the two MEPs to be synced ⏰, so it's a whole different vibe.
Two MEPs running a two-way Delay Measurement protocol MAY be time-synchronized 🕰️. If they are, the sender MAY work out the one-way delays like this 💅:
one-way delay {sender->reflector} = T2 - T1 (6)
one-way delay {reflector->sender} = T4 - T3 (7)When two-way Delay Measurement runs periodically, the sender MAY also figure out the delay variation using multiple measurements 📈🦋.
A sender MAY choose to monitor only the sender->reflector delay 🎀. That means doing the Equation (6) math and skipping Equations (5) and (7). Bestie, here's the tea: in this case, the sender can run flow-based PM on the path to the peer MEP without needing the Reflector Entropy TLV 🫶.
6. Packet Formats 📦
6.1. TRILL OAM Encapsulation 🌸
The TRILL OAM packet format is generally discussed in [OAM-FRAMEWK] and specified in detail in [TRILL-FM]. It's quoted in this doc just for convenience 💖.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. Link Header . (variable)
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ TRILL Header + 6 or more bytes
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. Flow Entropy . 96 bytes
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OAM Ethertype |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. OAM Message Channel . Variable
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Link Trailer | Variable
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6: TRILL OAM EncapsulationThe OAM Message Channel used in this document is defined in [TRILL-FM] and 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|MD-L | Version | OpCode | Flags |FirstTLVOffset |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. OpCode-specific fields .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. TLVs .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 7: OAM Packet FormatThe first four octets of the OAM Message Channel are shared by all OpCodes 🫧, and everything after them is OpCode-specific. Here's the quick rundown of those first 4 octets 🍓:
- MD-L: Maintenance Domain Level.
- Version: indicates the version of this protocol. It's always zero in the context of this document.
- OpCode: Operation Code (8 bits). Specifies the operation the message performs. Specific packet formats are presented in Sections 6.2 and 6.3 of this document. A list of the PM message OpCodes is provided in Section 6.4.
- Flags: The definition of flags is OpCode-specific. The value of this field is zero unless otherwise stated.
- FirstTLVOffset: defines the location of the first TLV, in octets, starting from the end of the FirstTLVOffset field.
- TLVs: one or more TLV fields. The last TLV field is always an End TLV.
For more on the OAM packet format, including how TLVs are shaped, check [TRILL-FM] 🧚.
6.2. Loss Measurement Packet Formats 📉
6.2.1. Counter Format 🔢
Loss Measurement packets use a 32-bit packet counter field 💜. When a counter goes past its maximal value, 0xFFFFFFFF, it wraps around back to 0 🔄.
6.2.2. 1SL Packet Format 💫
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|MD-L | Ver (0) | OpCode | Flags (0) |FirstTLVOffset |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sender MEP ID | Reserved (0) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Test ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Counter TX |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved (0) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. TLVs .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 8: 1SL Packet FormatFor fields not listed below, see Section 6.1 🔍.
- OpCode: see Section 6.4.
- FirstTLVOffset: defines the location of the first TLV, in octets, starting from the end of the FirstTLVOffset field. The value of this field MUST be 16 in 1SL packets. 🚨
- Sender MEP ID: the MEP ID of the MEP that initiated the 1SL.
- Reserved (0): set to 0 by the sender and ignored by the receiver.
- Test ID: a 32-bit unique test identifier.
- Counter TX: the value of the sender's transmission counter, including this packet, at the time of transmission.
6.2.3. SLM Packet Format 🦋
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|MD-L | Ver (0) | OpCode | Flags (0) |FirstTLVOffset |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sender MEP ID | Reserved for Reflector MEP ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Test ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Counter TX |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved for SLR: Counter TRX (0) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. TLVs .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 9: SLM Packet FormatFor fields not listed below, see Section 6.1 🔍.
- OpCode: see Section 6.4.
- FirstTLVOffset: defines the location of the first TLV, in octets, starting from the end of the FirstTLVOffset field. The value of this field MUST be 16 in SLM packets. 🚨
- Sender MEP ID: the MEP ID of the MEP that initiated this packet.
- Reserved for Reflector MEP ID: this field is reserved for the reflector's MEP ID, to be added in the SLR.
- Test ID: a 32-bit unique test identifier.
- Counter TX: the value of the sender's transmission counter, including this packet, at the time of transmission.
- Reserved for SLR: this field is reserved for the SLR corresponding to this packet. The reflector uses this field in the SLR for carrying TRX, the value of its reception counter.
6.2.4. SLR Packet Format 🌈
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|MD-L | Ver (0) | OpCode | Flags (0) |FirstTLVOffset |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sender MEP ID | Reflector MEP ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Test ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Counter TX |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Counter TRX |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. TLVs .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 10: SLR Packet FormatFor fields not listed below, see Section 6.1 🔍.
- OpCode: see Section 6.4.
- FirstTLVOffset: defines the location of the first TLV, in octets, starting from the end of the FirstTLVOffset field. The value of this field MUST be 16 in SLR packets. 🚨
- Sender MEP ID: the MEP ID of the MEP that initiated the SLM that this SLR replies to.
- Reflector MEP ID: the MEP ID of the MEP that transmits this SLR message.
- Test ID: a 32-bit unique test identifier, copied from the corresponding SLM message.
- Counter TX: the value of the sender's transmission counter at the time of the SLM transmission.
- Counter TRX: the value of the reflector's reception counter, including this packet, at the time of reception of the corresponding SLM packet.
6.3. Delay Measurement Packet Formats ⏱️
6.3.1. Timestamp Format 🕐
The timestamps used in Delay Measurement packets are 64 bits long 💖. They use the 64 least significant bits of the IEEE 1588-2008 (1588v2) Precision Time Protocol timestamp format [IEEE1588v2].
This truncated format is a 32-bit seconds field followed by a 32-bit nanoseconds field ✨. It's also used in IEEE 1588v1 [IEEE1588v1], in [Y.1731-2013], and in [MPLS-LM-DM] 🫶.
6.3.2. 1DM Packet Format ✨
Okay bestie, the 1DM packet is giving clean, minimal energy 🦋
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|MD-L | Ver (1) | OpCode | Reserved (0)|T|FirstTLVOffset |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Timestamp T1 |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved for 1DM receiving equipment (0) |
| (for Timestamp T2) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. TLVs .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 11: 1DM Packet FormatFor the fields that aren't listed below, just peek at Section 6.1 🎀
- OpCode: see Section 6.4. 💅
- Reserved (0): this is the upper part of the Flags field. The sender sets it to 0 and the receiver just ignores it 🙈
- T: the Type flag. When it's set, that means proactive operation. When it's cleared, that means on-demand mode ✨
- FirstTLVOffset: tells you where the first TLV lives, measured in octets and counted from the end of the FirstTLVOffset field. This one MUST be 16 in 1DM packets, no exceptions 👑
- Timestamp T1: this is the time the packet got sent 🕰️
- Reserved for 1DM: this spot is for the 1DM receiver's own internal use. The receiver can stash T2 here, which is the time this packet was received 🧚
6.3.3. DMM Packet Format 🦋
The DMM packet is basically the 1DM's more dramatic cousin, with extra timestamp drama 💜
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|MD-L | Ver (1) | OpCode | Reserved (0)|T|FirstTLVOffset |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Timestamp T1 |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved for DMM receiving equipment (0) |
| (for Timestamp T2) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved for DMR (0) |
| (for Timestamp T3) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved for DMR receiving equipment |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. TLVs .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 12: DMM Packet FormatFor fields not listed below, see Section 6.1. You know the drill 💖
- OpCode: see Section 6.4. 🫶
- Reserved (0): the upper part of the Flags field. The sender sets it to 0 and the receiver ignores it 🌸
- T: the Type flag. Set means proactive operation, cleared means on-demand mode 🍓
- FirstTLVOffset: the location of the first TLV, in octets, counted from the end of the FirstTLVOffset field. This MUST be 32 in DMM packets 🔥
- Timestamp T1: the time this packet was transmitted ⭐
- Reserved for DMM: this is for the internal use of the MEP that receives the DMM, which is the reflector. The reflector can use this field to carry T2, the time this packet was received 🧚♀️
- Reserved for DMR: two timestamp fields are set aside for the DMR message. One is for T3, the DMR transmission time. The other is for the internal use of the MEP that receives the DMR 😭
6.3.4. DMR Packet Format 💅
The DMR is the reply, and honestly it's the one with the full timestamp glow-up 🌈
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|MD-L | Ver (1) | OpCode | Reserved (0)|T|FirstTLVOffset |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Timestamp T1 |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Timestamp T2 |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Timestamp T3 |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved for DMR receiving equipment |
| (for Timestamp T4) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. TLVs .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 13: DMR Packet FormatFor fields not listed below, see Section 6.1. Same energy as before 🎀
- OpCode: see Section 6.4. ✨
- Reserved (0): the upper part of the Flags field. Sender sets it to 0, receiver ignores it 🙈
- T: the Type flag. Set means proactive, cleared means on-demand 🦋
- FirstTLVOffset: the location of the first TLV, in octets, counted from the end of the FirstTLVOffset field. This MUST be 32 in DMR packets 👑
- Timestamp T1: the time the DMM packet this DMR replies to was transmitted 🕰️
- Timestamp T2: the time the DMM packet this DMR replies to was received 📥
- Timestamp T3: the time this DMR packet was transmitted 📤
- Reserved for DMR: this is for the internal use of the MEP that receives the DMR, which is the sender. The sender can use this field to carry T4, the time this packet was received 🧚
6.4. OpCode Values 🌸
Since the OAM packets in here follow [Y.1731-2013], they use the same OpCodes, and they're listed below 💜
OpCode OAM packet
value type
------ ----------
45 1DM
46 DMR
47 DMM
53 1SL
54 SLR
55 SLMThese OpCodes come from the range of values that IEEE 802.1 [802.1Q] has allocated for ITU-T to control 🫶
7. Performance Monitoring Process 📊
The Performance Monitoring process is made up of a bunch of Performance Monitoring instances, which are called PM Sessions. A PM session can be started between two MEPs on a specific flow, and it can be defined as either a Loss Measurement session or a Delay Measurement session 🔥
A Loss Measurement session can be used to figure out Frame Loss Ratio, availability, and resiliency. A Delay Measurement session can be used to figure out Frame Delay, Inter-Frame Delay Variation, Frame Delay Range, and Mean Frame Delay 💖
A PM session is defined by the specific PM function (the PM tool) being run, and also by the Start Time, Stop Time, Message Period, Measurement Interval, and Repetition Time. Here's what each of those means 👑
- Start Time: the time the PM session begins ⏰
- Stop Time: the time the measurement ends 🛑
- Message Period: how often messages get sent, meaning the time between message transmissions 📨
- Measurement Interval: the time period over which measurements are gathered and then summarized. The Measurement Interval can line up with the PM Session duration, but it doesn't need to. PM messages are only transmitted during a PM Session 🌈
- Repetition Time: the time between the start times of the Measurement Intervals 🔁
Measurement Interval Measurement Interval
(Completed, Historic) (In Process, Current)
| |
| |
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
^ ^ ^ ^
| | | |
Start Time Message Stop Time
(service enabled) Period (Service disabled)
Figure 14: Relationship between Different Timing Parameters8. Security Considerations 🔐
The security considerations of TRILL OAM are discussed in [OAM-REQ], [OAM-FRAMEWK], and [TRILL-FM]. General TRILL security considerations are covered in [TRILL] 🧚
Okay, this part is serious, so read it carefully 🙈
As discussed in [OAM-Over], an attack on a PM protocol can falsely show performance issues that don't exist, or it can stop real ones from getting detected. That can end up causing DoS (Denial of Service) 😭 Synthetic PM messages can also be used maliciously to launch DoS attacks on RBridges. And there's network reconnaissance too: if an attacker just passively eavesdrops on PM messages, they can collect information and use it to attack the network 💀
As in [TRILL-FM], TRILL PM OAM messages MAY include the OAM Authentication TLV. An Authentication TLV needs a cryptographic algorithm, and that can affect performance on the RBridges taking part in the protocol. So in some cases it could change the measurement results. Based on a system-specific threat assessment, the benefits of the security TLV must be weighed against the potential measurement inaccuracy it may cause. Operators should make a decision on whether or not to use authentication based on that trade-off. It should be noted that this is a big decision, so think it through 🫶💜
9. References 📚
9.1. Normative References ✨
okay bestie, these are the ones you have to read, no skipping 💅 Each one is a must-read for the spec to make sense.
[KEYWORDS]Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997,<http://www.rfc-editor.org/info/rfc2119>.[TRILL]Perlman, R., Eastlake 3rd, D., Dutt, D., Gai, S., and A. Ghanwani, "Routing Bridges (RBridges): Base Protocol Specification", RFC 6325, July 2011,<http://www.rfc-editor.org/info/rfc6325>.[FGL]Eastlake 3rd, D., Zhang, M., Agarwal, P., Perlman, R., and D. Dutt, "Transparent Interconnection of Lots of Links (TRILL): Fine-Grained Labeling", RFC 7172, May 2014,<http://www.rfc-editor.org/info/rfc7172>.[TRILL-FM]Senevirathne, T., Finn, N., Salam, S., Kumar, D., Eastlake 3rd, D., Aldrin, S., and Y. Li, "Transparent Interconnection of Lots of Links (TRILL): Fault Management", RFC 7455, March 2015,<http://www.rfc-editor.org/info/rfc7455>.
9.2. Informative References 🌸
these ones are the extra reading 📚 not required, but SO worth it if you want the full picture 🤓🫶
[OAM-REQ]Senevirathne, T., Bond, D., Aldrin, S., Li, Y., and R. Watve, "Requirements for Operations, Administration, and Maintenance (OAM) in Transparent Interconnection of Lots of Links (TRILL)", RFC 6905, March 2013,<http://www.rfc-editor.org/info/rfc6905>.[OAM-FRAMEWK]Salam, S., Senevirathne, T., Aldrin, S., and D. Eastlake 3rd, "Transparent Interconnection of Lots of Links (TRILL) Operations, Administration, and Maintenance (OAM) Framework", RFC 7174, May 2014,<http://www.rfc-editor.org/info/rfc7174>.[Y.1731-2013]ITU-T, "OAM functions and mechanisms for Ethernet based Networks", ITU-T Recommendation G.8013/Y.1731, November 2013.[802.1Q]IEEE, "IEEE Standard for Local and metropolitan area networks -- Bridges and Bridged Networks", IEEE Std 802.1Q, December 2014.[IEEE1588v1]IEEE, "IEEE Standard for a Precision Clock Synchronization Protocol for Networked Measurement and Control Systems Version 1", IEEE Standard 1588, 2002.[IEEE1588v2]IEEE, "IEEE Standard for a Precision Clock Synchronization Protocol for Networked Measurement and Control Systems Version 2", IEEE Standard 1588, 2008.[MPLS-LM-DM]Frost, D. and S. Bryant, "Packet Loss and Delay Measurement for MPLS Networks", RFC 6374, September 2011,<http://www.rfc-editor.org/info/rfc6374>.[OAM]Andersson, L., van Helvoort, H., Bonica, R., Romascanu, D., and S. Mansfield, "Guidelines for the Use of the "OAM" Acronym in the IETF", BCP 161, RFC 6291, June 2011,<http://www.rfc-editor.org/info/rfc6291>.[IPPM-1DM]Almes, G., Kalidindi, S., and M. Zekauskas, "A One-way Delay Metric for IPPM", RFC 2679, September 1999,<http://www.rfc-editor.org/info/rfc2679>.[IPPM-2DM]Almes, G., Kalidindi, S., and M. Zekauskas, "A Round-trip Delay Metric for IPPM", RFC 2681, September 1999,<http://www.rfc-editor.org/info/rfc2681>.[IPPM-Loss]Almes, G., Kalidindi, S., and M. Zekauskas, "A One-way Packet Loss Metric for IPPM", RFC 2680, September 1999,<http://www.rfc-editor.org/info/rfc2680>.[OAM-Over]Mizrahi, T., Sprecher, N., Bellagamba, E., and Y. Weingarten, "An Overview of Operations, Administration, and Maintenance (OAM) Tools", RFC 7276, June 2014,<http://www.rfc-editor.org/info/rfc7276>.
Acknowledgments 🫶
huge shoutout to the amazing people who helped make this happen 💖 The authors are so grateful to Adrian Farrel, Alexey Melnikov, Jan Novak, Carlos Pignataro, Gagan Mohan Goel, Pete Resnick, and Prabhu Raj for their super helpful comments 🙌✨
Authors' Addresses 💌
meet the team 🧚 here's how to reach each of the authors:
Tal Mizrahi
Marvell
6 Hamada St.
Yokneam, 20692
Israel
EMail: talmi@marvell.com
Tissa Senevirathne
Cisco
375 East Tasman Drive
San Jose, CA 95134
United States
EMail: tsenevir@cisco.com
Samer Salam
Cisco
595 Burrard Street, Suite 2123
Vancouver, BC V7X 1J1
Canada
EMail: ssalam@cisco.com
Deepak Kumar
Cisco
510 McCarthy Blvd,
Milpitas, CA 95035
United States
Phone : +1 408-853-9760
EMail: dekumar@cisco.com
Donald Eastlake 3rd
Huawei Technologies
155 Beaver Street
Milford, MA 01757
United States
Phone: +1-508-333-2270
EMail: d3e3e3@gmail.com📦 where this page comes from
- ietf: rfc7456 2015-03
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms