RFC 6777

Label Switched Path (LSP) Data Path Delay Metrics in Generalized MPLS and MPLS Traffic Engineering (MPLS-TE) Networks

📅 published November 2012, from ietf

RFC 6777: Label Switched Path (LSP) Data Path Delay Metrics in Generalized MPLS and MPLS Traffic Engineering (MPLS-TE) Networks 🎀

okay bestie, the big-picture facts first ✨

This one was published by the IETF in November 2012 as a Standards Track document (ISSN 2070-1721). It's a consensus product of the IETF community, so it got public review and was approved by the IESG. The header lists no Obsoletes or Updates entries.

The authors are:

W. Sun, Ed. (SJTU) 🌸
G. Zhang, Ed. (CATR) 🦋
J. Gao (Huawei) 💜
G. Xie (UC Riverside) 🧚
R. Papneja (Huawei) ⭐

Abstract ✨

When you set up a Label Switched Path (LSP) in Generalized MPLS (GMPLS) and MPLS Traffic Engineering (MPLS-TE) networks, finishing the signaling process does not automatically mean the cross-connection along the LSP got programmed properly and on time 😬. Meanwhile, LSP users or applications that control their use may treat finished signaling as proof that the data path is usable. If that mismatch between signaling and cross-connection programming isn't handled properly, and the programming can fail, you get data loss or even application failure 💀. Characterizing this performance helps designers improve how LSPs get used and makes the apps and tools that depend on LSPs way more robust 💅. This document defines a series of performance metrics to evaluate the connectivity of the data path in the signaling process 🔥.

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. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.

Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6777.

Copyright Notice ©️

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 described in the Simplified BSD License.

Table of Contents 🗺️

   1. Introduction ....................................................4
   2. Conventions Used in This Document ...............................5
   3. Overview of Performance Metrics .................................5
   4. Terms Used in This Document .....................................6
   5. A Singleton Definition for RRFD .................................7
      5.1. Motivation .................................................7
      5.2. Metric Name ................................................7
      5.3. Metric Parameters ..........................................7
      5.4. Metric Units ...............................................7
      5.5. Definition .................................................8
      5.6. Discussion .................................................8
      5.7. Methodologies ..............................................9
   6. A Singleton Definition for RSRD ................................10
      6.1. Motivation ................................................10
      6.2. Metric Name ...............................................10
      6.3. Metric Parameters .........................................10
      6.4. Metric Units ..............................................11
      6.5. Definition ................................................11
      6.6. Discussion ................................................11
      6.7. Methodologies .............................................12
   7. A Singleton Definition for PRFD ................................13
      7.1. Motivation ................................................13
      7.2. Metric Name ...............................................13
      7.3. Metric Parameters .........................................13
      7.4. Metric Units ..............................................13
      7.5. Definition ................................................14
      7.6. Discussion ................................................14
      7.7. Methodologies .............................................15

   8. A Singleton Definition for PSFD ................................16
      8.1. Motivation ................................................16
      8.2. Metric Name ...............................................16
      8.3. Metric Parameters .........................................16
      8.4. Metric Units ..............................................16
      8.5. Definition ................................................17
      8.6. Discussion ................................................17
      8.7. Methodologies .............................................18
   9. A Singleton Definition for PSRD ................................19
      9.1. Motivation ................................................19
      9.2. Metric Name ...............................................19
      9.3. Metric Parameters .........................................19
      9.4. Metric Units ..............................................19
      9.5. Definition ................................................20
      9.6. Discussion ................................................20
      9.7. Methodologies .............................................21
   10. A Definition for Samples of Data Path Delay ...................22
      10.1. Metric Name ..............................................22
      10.2. Metric Parameters ........................................22
      10.3. Metric Units .............................................22
      10.4. Definition ...............................................22
      10.5. Discussion ...............................................23
      10.6. Methodologies ............................................23
      10.7. Typical Testing Cases ....................................23
           10.7.1. With No LSP in the Network ........................23
           10.7.2. With a Number of LSPs in the Network ..............24
   11. Some Statistics Definitions for Metrics to Report .............24
      11.1. The Minimum of the Metric ................................24
      11.2. The Median of the Metric .................................24
      11.3. The Percentile of the Metric .............................24
      11.4. Failure Probability ......................................25
           11.4.1. Failure Count .....................................25
           11.4.2. Failure Ratio .....................................25
   12. Security Considerations .......................................25
   13. References ....................................................26
      13.1. Normative References .....................................26
      13.2. Informative References ...................................26
   Appendix A. Acknowledgements ......................................27
   Appendix B. Contributors ..........................................28

1. Introduction 🦋

Label Switched Paths (LSPs) get established, controlled, and allocated for use either by management tools or directly by the components that use them. In this doc, we call those management tools and the components that use LSPs "applications" 💅. These applications can be Network Management Systems (NMSs); hardware or software components that forward data onto virtual links; programs or tools that use dedicated links; or literally any other user of an LSP 🫶.

Ideally, finishing the signaling process means the signaled LSP is ready to carry traffic. But in real implementations, vendors may choose to program the cross-connection in a pipelined manner so the overall LSP provisioning delay gets smaller ⚡. When they do that, the data path might not be ready for use instantly after signaling finishes. Implementation deficiencies can also cause a mismatch between signaling and data path provisioning. For example, if the data plane fails to program the cross-connection but doesn't manage to report that to the control plane, signaling can finish successfully while the data path never becomes functional at all 💀.

On the other hand, finishing signaling is often used in many cases as an indication of data path connectivity 🧚. For example, when invoking through the User-Network Interface (UNI) [RFC4208], a client device or an application may use the reception of the correct Resv message as an indication that the data path is fully functional and start transmitting traffic. Which, bestie, is how you get data loss or even application failure 😭.

Although RSVP(-TE) specifications have suggested that the cross-connections are programmed before signaling messages are propagated upstream, it is still worthwhile to verify the conformance of an implementation and measure the delay, when necessary 🔍.

This document defines a series of performance metrics to evaluate the connectivity of the data path during the signaling process 🌈. The metrics defined here complement the control plane metrics defined in [RFC5814]. These metrics can be used to verify the conformance of implementations against related specifications, as elaborated in [RFC6383]. They also can be used to build more robust applications 💖.

2. Conventions Used in This Document 📖

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 [RFC2119].

Part 1 of 5 done, bestie 🎀 Part 2 is coming up next, so stay tuned 💜✨

3. Overview of Performance Metrics ✨

okay bestie, so this memo defines five performance metrics for measuring how fast a data path gets provisioned with GMPLS/MPLS-TE signaling 🦋. these metrics are a glow-up of the ones in [RFC5814] 💅. the thing is, finishing the signaling for an LSP and actually getting the cross-connections programmed along it are not always in sync, and that's the whole tea ☕. [RFC5814] measures provisioning from the pure signaling side, but this doc also checks whether the data path is actually valid 🫶.

here are the five metrics 💖:

Resv Received, Forward Data (RRFD) - the delay between when the Resv message hits the ingress node and when the forward data path is ready to use 🎀.
Resv Sent, Reverse Data (RSRD) - the delay between when the egress node sends the Resv message and when the reverse data path is ready to use 🌸.
PATH Received, Forward Data (PRFD) - the delay between when the egress node receives the PATH message and when the forward data path is ready to use 🧚.
PATH Sent, Forward Data (PSFD) - the delay between when the ingress node sends the PATH message and when the forward data path is ready to use 🍓.
PATH Sent, Reverse Data (PSRD) - the delay between when the ingress node sends the PATH message and when the reverse data path is ready to use 🌈.

same energy as [RFC5814], we keep using the structures and notions from the IP Performance Metrics (IPPM) Framework documents [RFC2330] [RFC2679] [RFC2681] 📚. you're expected to already know those, plus the definitions in [RFC5814], iykyk 🙈.

4. Terms Used in This Document ✨

Forward data path - the data path from the ingress node to the egress node 💜. examples include the data path of a unidirectional LSP, and the data path from ingress to egress in a bidirectional LSP 🦋.
Reverse data path - the data path from the egress node to the ingress node in a bidirectional LSP 🌸.
Data path delay - the time needed to finish configuring the data path, measured relative to the signaling process 🎀. this doc defines five types: RRFD, RSRD, PRFD, PSFD, and PSRD 💅. data path delay in this doc MUST be told apart from transmission delay along the data path (the time it takes traffic to get from one side of the data path to the other) 🙈.
Error-free signal - a data-plane-specific sign that the data path is connected 🔥. for example, on interfaces that can do packet switching, the first error-free packet arriving from one side of the LSP to the other can serve as the error-free signal 📦. for SDH/SONET cross-connects, the disappearance of an alarm can be the error-free signal 🚨. we just call it "error-free signal" as a general umbrella term 👑. an implementation MUST choose a proper data path signal that's specific to the data path technology being tested ✨.
Ingress/egress node - in this memo, this means a measurement endpoint with both control plane and data plane features 🫶. usually the control plane part talks to the control plane of the network under test 💬. the data plane part generates data path signals and sends them into the data plane of the network under test, or receives data path signals coming back from it 🌈.

5. A Singleton Definition for RRFD ✨

this part defines a metric for forward data path delay when an LSP gets set up 🦋.

as [RFC6383] explains, finishing the RSVP-TE signaling process does NOT automatically mean the cross-connections along the LSP are in place and ready to carry traffic 💀. this metric measures the time gap between the ingress node receiving a Resv message and the cross-connection programming along the forward data path being finished 💖.

5.1. Motivation

RRFD is useful for these reasons 🧚:

as [RFC6383] describes, the data path might not be ready right after RSVP-TE signaling finishes 🙈. that delay is part of the implementation performance 🔥.
application designers might treat the end of signaling as a sign that the data path is connected 👑. this delay, plus the chance that cross-connection programming fails, will cause data loss or application failure if it isn't handled properly 😭. knowing the typical value of this delay helps designers improve the application model 💅.

5.2. Metric Name

RRFD = Resv Received, Forward Data path

5.3. Metric Parameters

ID0, the ingress Label Switching Router (LSR) ID 🎀
ID1, the egress LSR ID 🌸
T, a time when the setup is attempted 🍓

5.4. Metric Units

the value of RRFD is either a real number of milliseconds or undefined 🌈.

5.5. Definition

for a real number dT, the following:

RRFD from ingress node ID0 to egress node ID1 at T is dT

means that:

ingress node ID0 sends a PATH message to egress node ID1 💌,
the last bit of the corresponding Resv message is received by ingress node ID0 at T ✨, and
an error-free signal is received by egress node ID1 using a data-plane-specific test pattern at T+dT 🦋.

5.6. Discussion

these issues are likely to pop up in practice 👀:

the accuracy of RRFD depends on the clock resolution of both the ingress node and the egress node ⏰. clock synchronization between the ingress and egress nodes is REQUIRED 🫶.
the accuracy of RRFD also depends on how the error-free signal gets received, and it can differ a LOT depending on the data plane technology 💅. for example, for an LSP between a pair of Ethernet interfaces, the ingress node might use a rate-based method to check data path connectivity and use the first error-free frame as the signal 📦. in that case, the gap between two successive frames really matters for accuracy 🙈. it is RECOMMENDED that the ingress node use small intervals, as long as the injected traffic doesn't exceed the capacity of the forward data path 🌸. the value of those intervals MUST be reported 📝.
the accuracy of RRFD also depends on how long it takes to propagate the error-free signal from the ingress node to the egress node 🚀. a typical value for that propagation under the same measurement setup MAY be reported 🎀. the methodology for getting those values is outside the scope of this document 🙅.
the accuracy here also depends on physical-layer serialization/deserialization of the test signal for certain data path technologies 🧠. for example, for an LSP between a pair of low-speed Ethernet interfaces, serializing/deserializing a large frame might not be negligible 🐢. in that case, it is RECOMMENDED that the ingress node use small frames 💖. the average frame length MAY be reported 📏.
some implementations might program the cross-connection before sending a PATH message further downstream, so the data path could be ready before the Resv message even reaches the ingress node 🏃. in those cases RRFD can be a NEGATIVE value 🌀. it is RECOMMENDED that a PRFD measurement be carried out to further characterize forward data path delay whenever a negative RRFD value shows up 🔍.
if an error-free signal is received by the egress node BEFORE a PATH message is sent on the ingress node, an error MUST be reported and the measurement SHOULD terminate 🚨.
if the corresponding Resv message is received but no error-free signal reaches the egress node within a reasonable period of time (a threshold), RRFD MUST be treated as undefined ⌛. the threshold value MUST be reported 📝.
if the LSP setup fails, this metric value MUST NOT be counted ❌.

5.7. Methodologies

generally, the methodology goes like this 🗺️:

make sure the network has enough resources to set up the requested LSP 💪.
start the data path measurement and/or monitoring procedures on the ingress and egress nodes 🎬. if an error-free signal is received by the egress node before a PATH message is sent, report an error and terminate the measurement 🛑.
at the ingress node, form the PATH message according to the LSP requirements and send it toward the egress node 📨.
once the last bit of the corresponding Resv message arrives, take the timestamp (T1) on the ingress node as soon as possible ⏱️.
when an error-free signal is observed on the egress node, take the timestamp (T2) as soon as possible 🎯. an estimate of RRFD (T2 - T1) can be computed 🧮.
if the corresponding Resv message arrives but no error-free signal is received within a reasonable period of time by the ingress node, RRFD is deemed undefined 🤷‍♀️.
if the LSP setup fails, RRFD is not counted 🙅‍♀️.

6. A Singleton Definition for RSRD ✨

this part defines a metric for reverse data path delay when an LSP gets set up 🦋.

as [RFC6383] explains, finishing the RSVP-TE signaling process does NOT automatically mean the cross-connections along the LSP are in place and ready to carry traffic 💀. this metric measures the time gap between finishing the signaling process and finishing the cross-connection programming along the reverse data path 💖. this metric MAY be used together with RRFD to characterize the data path delay of a bidirectional LSP 🫶.

6.1. Motivation

RSRD is useful for these reasons 🧚:

as [RFC6383] describes, the data path might not be ready right after RSVP-TE signaling finishes 🙈. that delay is part of the implementation performance 🔥.
application designers might treat the end of signaling as a sign that the data path is connected 👑. this delay, plus the possible failure of cross-connection programming, will cause data loss or application failure if it isn't handled properly 😭. knowing the typical value of this delay helps designers improve the application model 💅.

6.2. Metric Name

RSRD = Resv Sent, Reverse Data path

6.3. Metric Parameters

ID0, the ingress LSR ID 🎀
ID1, the egress LSR ID 🌸
T, a time when the setup is attempted 🍓

6.4. Metric Units

the value of RSRD is either a real number of milliseconds or undefined 🌈.

6.5. Definition

for a real number dT, the following:

RSRD from ingress node ID0 to egress node ID1 at T is dT

means that:

ingress node ID0 sends a PATH message to egress node ID1 💌,
the last bit of the corresponding Resv message is sent by egress node ID1 at T ✨, and
an error-free signal is received by ingress node ID0 using a data-plane-specific test pattern at T+dT 🦋.

6.6. Discussion 🎀

okay bestie, these are the issues that are likely to pop up in real life, so pay attention 👀

The accuracy of RSRD depends on the clock resolution of both the ingress node and egress node. Clock synchronization between the ingress node and egress node is required. ⏰✨
The accuracy of RSRD also depends on how the error-free signal gets received, and it may differ significantly when the underlying data plane technology is different. For example, on an LSP between a pair of Ethernet interfaces, the egress node (sometimes the tester) might use a rate-based method to check that the data path is connected, and treat the arrival of the first error-free frame as the error-free signal. In that case, the gap between two successive frames seriously affects accuracy 😭. It is RECOMMENDED in this case that the egress node use small intervals, as long as the injected traffic does not go over the capacity of the reverse data path. The value of the interval MUST be reported. 📏
The accuracy of RSRD also depends on how long it takes to propagate the error-free signal from the egress node to the ingress node. A typical value for propagating the error-free signal from the egress node to the ingress node under the same measurement setup MAY be reported. How to get those values is outside the scope of this document, so that's a different adventure 🗺️
The accuracy of this metric also depends on the physical-layer serialization/deserialization of the test signal for certain data path technologies. For example, on an LSP between a pair of low-speed Ethernet interfaces, the time needed to serialize/deserialize a large frame may not be negligible 🐢. In this case, it is RECOMMENDED that the egress node use small frames. The average length of the frame MAY be reported. 🍓
If the corresponding Resv message is sent but no error-free signal is received by the ingress node within a reasonable period of time (in other words, a threshold), RSRD MUST be treated as undefined. The value of the threshold MUST be reported. ⏳💀
If an error-free signal is received before a PATH message is sent on the ingress node, an error MUST be reported and the measurement SHOULD terminate. 🚨
If the LSP setup fails, this metric value MUST NOT be counted. 🙅‍♀️

6.7. Methodologies 🧠

okay so generally, the methodology goes like this:

Make sure that the network has enough resources to set up the requested LSP. 🛠️
Start the data path measurement and/or monitoring procedures on the ingress node and egress node. If an error-free signal is received by the ingress node before a PATH message is sent, report an error and terminate the measurement. 🛑
At the ingress node, form the PATH message according to the LSP requirements and send the message towards the egress node. 📨
Upon sending the last bit of the corresponding Resv message, take the timestamp (T1) on the egress node as soon as possible. ⏱️
When an error-free signal is observed on the ingress node, take the timestamp (T2) as soon as possible. An estimate of RSRD (T2 - T1) can be computed. 🧮✨
If the LSP setup fails, RSRD is not counted. 🥀
If no error-free signal is received within a reasonable period of time by the ingress node, RSRD is deemed to be undefined. 🫥

7. A Singleton Definition for PRFD 🦋

this part defines a metric for forward data path delay when an LSP is set up. 🌸

in an RSVP-TE implementation, when setting up an LSP, each node may choose to program the cross-connection before it sends a PATH message further downstream. so the forward data path might be ready to use before the signaling process finishes, which means before the Resv message reaches the ingress node. this metric can be used to spot that implementation practice and give useful info to application designers 💅🧚

7.1. Motivation 💜

PRFD is useful for the following reasons:

PRFD can be used to identify an RSVP-TE implementation practice in which cross-connections are programmed before a PATH message is sent downstream. 🔍
The value of PRFD may also help application designers fine-tune their application model. 🎀

7.2. Metric Name 🏷️

PRFD = PATH Received, Forward Data path

7.3. Metric Parameters 🧩

ID0, the ingress LSR ID
ID1, the egress LSR ID
T, a time when the setup is attempted

7.4. Metric Units 📐

The value of PRFD is either a real number of milliseconds or undefined.

7.5. Definition 📖

For a real number dT,

      PRFD from ingress node ID0 to egress node ID1 at T is dT

means that

ingress node ID0 sends a PATH message to egress node ID1,
the last bit of the PATH message is received by egress node ID1 at T, and
an error-free signal is received by the egress node ID1 using a data-plane-specific test pattern at T+dT.

7.6. Discussion 💬

okay the issues likely to come up in practice are:

The accuracy of PRFD depends on the clock resolution of the egress node. Clock synchronization between the ingress node and egress node is not required. ⏰🫶
The accuracy of PRFD also depends on how the error-free signal gets received, and it may differ significantly when the underlying data plane technology is different. For example, on an LSP between a pair of Ethernet interfaces, the egress node (sometimes the tester) might use a rate-based method to check that the data path is connected, and treat the arrival of the first error-free frame as the error-free signal. In that case, the gap between two successive frames seriously affects accuracy 😭. It is RECOMMENDED in this case that the ingress node use small intervals, as long as the injected traffic does not go over the capacity of the forward data path. The value of the interval MUST be reported. 📏
The accuracy of PRFD also depends on how long it takes to propagate the error-free signal from the ingress node to the egress node. A typical value for propagating the error-free signal from the ingress node to the egress node under the same measurement setup MAY be reported. How to get those values is outside the scope of this document 🗺️
The accuracy of this metric also depends on the physical-layer serialization/deserialization of the test signal for certain data path technologies. For example, on an LSP between a pair of low-speed Ethernet interfaces, the time needed to serialize/deserialize a large frame may not be negligible 🐢. In this case, it is RECOMMENDED that the ingress node use small frames. The average length of the frame MAY be reported. 🍓
If an error-free signal is received before a PATH message is sent, an error MUST be reported and the measurement SHOULD terminate. 🚨
If the LSP setup fails, this metric value MUST NOT be counted. 🙅‍♀️
This metric SHOULD be used together with RRFD. It is RECOMMENDED that a PRFD measurement be carried out after a negative RRFD value has already been observed. 👑✨

7.7. Methodologies 🧠

okay so generally, the methodology goes like this:

Make sure that the network has enough resources to set up the requested LSP. 🛠️
Start the data path measurement and/or monitoring procedures on the ingress node and egress node. If an error-free signal is received by the egress node before a PATH message is sent, report an error and terminate the measurement. 🛑
At the ingress node, form the PATH message according to the LSP requirements and send the message towards the egress node. 📨
Upon receiving the last bit of the PATH message, take the timestamp (T1) on the egress node as soon as possible. ⏱️
When an error-free signal is observed on the egress node, take the timestamp (T2) as soon as possible. An estimate of PRFD (T2 - T1) can be computed. 🧮✨
If the LSP setup fails, PRFD is not counted. 🥀
If no error-free signal is received within a reasonable period of time by the egress node, PRFD is deemed to be undefined. 🫥

8. A Singleton Definition for PSFD 🌈

this part defines a metric for forward data path delay when an LSP is set up. 💖

as described in [RFC6383], finishing the RSVP-TE signaling process does not necessarily mean that the cross-connections along the LSP being set up are in place and ready to carry traffic. this metric defines the time difference between the point when the PATH message is sent by the ingress node and the completion of the cross-connection programming along the LSP forward data path. ⚡

8.1. Motivation 🎯

PSFD is useful for the following reasons:

For the reasons described in [RFC6383], the data path setup delay may not be consistent with the control plane LSP setup delay. The data path setup delay metric is more precise for LSP setup performance measurement. 📊
Application designers may use the completion of the signaling process as an indication of data path connectivity. The difference between the control plane setup delay and data path delay, and the potential failure of cross-connection programming, if not properly treated, will result in data loss or application failure 😱. This metric can thus help designers improve the application model. 🛡️

8.2. Metric Name 🏷️

PSFD = PATH Sent, Forward Data path

8.3. Metric Parameters 🧩

ID0, the ingress LSR ID
ID1, the egress LSR ID
T, a time when the setup is attempted

8.4. Metric Units 📐

The value of PSFD is either a real number of milliseconds or undefined.

8.5. Definition 📖

For a real number dT,

      PSFD from ingress node ID0 to egress node ID1 at T is dT

means that

ingress node ID0 sends the first bit of a PATH message to egress node ID1 at T, and
an error-free signal is received by the egress node ID1 using a data-plane-specific test pattern at T+dT.

8.6. Discussion ✨

okay so bestie, this is the part where the spec lists the stuff people are most likely to run into in real life 💅 and honestly it's a lot of "it depends" energy, so let's go 🫶

o The accuracy of PSFD depends on the clock resolution of both the ingress node and egress node. Clock synchronization between the ingress node and egress node is required. 🕰️

o The accuracy of PSFD is also dependent on how the error-free signal is received, and it can look totally different depending on the data plane tech 🎀. Like, for an LSP between a pair of Ethernet interfaces, the ingress node might use a rate-based method to check that the data path is connected and then treat the first error-free frame it gets as the error-free signal 🦋. Here the gap between two frames is a huge deal for accuracy, so it is RECOMMENDED that the ingress node use small intervals 🌸, as long as the injected traffic does not go over the capacity of the forward data path. The value of the interval MUST be reported 📝.

o The accuracy of PSFD also depends on how long it takes to propagate the error-free signal from the ingress node to the egress node 🧚. A typical value for that under the same measurement setup MAY be reported 💜. How you get those values is outside the scope of this document, so that's a whole other story 🙈.

o The accuracy of this metric also depends on the physical-layer serialization/deserialization of the test signal for certain data path technologies 💖. For example, for an LSP between a pair of low-speed Ethernet interfaces, the time to serialize/deserialize a large frame may not be negligible 🍓. So in that case it is RECOMMENDED that the ingress node use small frames 💅. The average length of the frame MAY be reported ✨.

o If an error-free signal is received before a PATH message is sent, an error MUST be reported and the measurement SHOULD terminate 🚨.

o If the LSP setup fails, this metric value MUST NOT be counted 🙅‍♀️.

o If the PATH message is sent by the ingress node but no error-free signal is received by the egress node within a reasonable period of time, i.e., a threshold, PSFD MUST be treated as undefined 💀. The value of the threshold MUST be reported 📝.

8.7. Methodologies ✨

Generally, the methodology would proceed as follows 🦋:

o Make sure that the network has enough resources to set up the requested LSP 👑.

o Start the data path measurement and/or monitoring procedures on the ingress node and egress node 🌈. If an error-free signal is received by the egress node before a PATH message is sent, report an error and terminate the measurement 🚨.

o At the ingress node, form the PATH message according to the LSP requirements and send the message towards the egress node 💌. A timestamp (T1) may be stored locally in the ingress node when the PATH message packet is sent towards the egress node ⏱️.

o When an error-free signal is observed on the egress node, take the timestamp (T2) as soon as possible 🏃‍♀️. An estimate of PSFD (T2 - T1) can be computed 🧮.

o If the LSP setup fails, PSFD is not counted 🙅‍♀️.

o If no error-free signal is received within a reasonable period of time by the egress node, PSFD is deemed to be undefined 💔.

A Singleton Definition for PSRD 🦋

This part defines a metric for reverse data path delay when an LSP is set up 🎀.

This metric defines the time difference between the point when the ingress node sends the PATH message and the completion of the cross-connection programming along the LSP reverse data path 💫. This metric MAY be used together with PSFD to characterize the data path delay of a bidirectional LSP 🫶.

9.1. Motivation ✨

PSRD is useful for the following reasons 🌸:

o For the reasons described in [RFC6383], the data path setup delay may not be consistent with the control plane LSP setup delay 😭. The data path setup delay metric is more precise for LSP setup performance measurement 🎯.

o The completion of the signaling process may be used by application designers as an indication of data path connectivity 🧚. The difference between the control plane setup delay and data path delay, and the potential failure of cross-connection programming, if not properly treated, will result in data loss or application failure 😱. This metric can thus help designers to improve the application model 💖.

9.2. Metric Name ✨

PSRD = PATH Sent, Reverse Data path

9.3. Metric Parameters ✨

o ID0, the ingress LSR ID 🪪

o ID1, the egress LSR ID 🪪

o T, a time when the setup is attempted ⏰

9.4. Metric Units ✨

The value of PSRD is either a real number of milliseconds or undefined 🍭.

9.5. Definition ✨

For a real number dT,

PSRD from ingress node ID0 to egress node ID1 at T is dT

means that 🫧

o ingress node ID0 sends the first bit of a PATH message to egress node ID1 at T, and 📨

o an error-free signal is received through the reverse data path by the ingress node ID0 using a data-plane-specific test pattern at T+dT 🎯.

9.6. Discussion ✨

The following issues are likely to come up in practice 💅:

o The accuracy of PSRD depends on the clock resolution of the ingress node. Clock synchronization between the ingress node and egress node is not required 🕰️.

o The accuracy of PSRD is also dependent on how the error-free signal is received, and it can look totally different depending on the data plane tech 🎀. Like, for an LSP between a pair of Ethernet interfaces, the egress node might use a rate-based method to check that the data path is connected and then treat the first error-free frame it gets as the error-free signal 🦋. Here the gap between two frames is a huge deal for accuracy, so it is RECOMMENDED that the egress node use small intervals 🌸, as long as the injected traffic does not go over the capacity of the forward data path. The value of the interval MUST be reported 📝.

o The accuracy of PSRD also depends on how long it takes to propagate the error-free signal from the egress node to the ingress node 🧚. A typical value for that under the same measurement setup MAY be reported 💜. How you get those values is outside the scope of this document 🙈.

o The accuracy of this metric also depends on the physical-layer serialization/deserialization of the test signal for certain data path technologies 💖. For example, for an LSP between a pair of low-speed Ethernet interfaces, the time to serialize/deserialize a large frame may not be negligible 🍓. So in that case it is RECOMMENDED that the egress node use small frames 💅. The average length of the frame MAY be reported ✨.

o If an error-free signal is received before a PATH message is sent, an error MUST be reported and the measurement SHOULD terminate 🚨.

o If the LSP setup fails, this metric value MUST NOT be counted 🙅‍♀️.

o If the PATH message is sent by the ingress node but no error-free signal is received by the ingress node within a reasonable period of time, i.e., a threshold, PSRD MUST be treated as undefined 💀. The value of the threshold MUST be reported 📝.

9.7. Methodologies ✨

Generally, the methodology would proceed as follows 🦋:

o Make sure that the network has enough resources to set up the requested LSP 👑.

o When an error-free signal is observed on the ingress node, take the timestamp (T2) as soon as possible 🏃‍♀️. An estimate of PSRD (T2 - T1) can be computed 🧮.

o If the LSP setup fails, PSRD is not counted 🙅‍♀️.

o If no error-free signal is received within a reasonable period of time by the ingress node, PSRD is deemed to be undefined 💔.

A Definition for Samples of Data Path Delay ✨

In Sections 5, 6, 7, 8, and 9, we defined the singleton metrics of data path delay 🧠. Now we define how to get one particular sample of such a delay 🎯. Sampling is done to select a particular portion of singleton values of the given parameters 🍰. As in [RFC2330], we use Poisson sampling as an example 🦋.

10.1. Metric Name ✨

Type <X> data path delay sample, where X is either RRFD, RSRD, PRFD, PSFD, or PSRD.

10.2. Metric Parameters ✨

o ID0, the ingress LSR ID 🪪

o ID1, the egress LSR ID 🪪

o T0, a time ⏰

o Tf, a time ⏰

o Lambda, a rate in reciprocal milliseconds 📈

o Th, the LSP holding time ⏳

o Td, the maximum waiting time for successful LSP setup ⌛

o Ts, the maximum waiting time for an error-free signal ⏳

10.3. Metric Units ✨

A sequence of pairs; the elements of each pair are 🧁:

o T, a time when setup is attempted ⏰

o dT, either a real number of milliseconds or undefined 🍭

10.4. Definition ✨

Given T0, Tf, and Lambda, compute a pseudo-random Poisson process beginning at or before T0, with average arrival rate Lambda, and ending at or after Tf 🎲. Those time values greater than or equal to T0 and less than or equal to Tf are then selected ✅. At each of the times in this process, we obtain the value of a data path delay sample of type <X> at this time 🫧. The value of the sample is the sequence made up of the resulting <time, type <X> data path delay> pairs 🧾. If there are no such pairs, the sequence is of length zero and the sample is said to be empty 🫥.

10.5. Discussion ✨

The following issues are likely to come up in practice 💅:

o The parameters Lambda, Th, and Td should be carefully chosen, as explained in the discussions for LSP setup delay (see [RFC5814]) 📚.

o The parameter Ts should be carefully chosen and MUST be reported along with the LSP forward/reverse data path delay sample 📝.

10.6. Methodologies ✨

Generally, the methodology would proceed as follows 🦋:

o Select specific times, using the specified Poisson arrival process 🎲.

o Set up the LSP and obtain the value of type <X> data path delay 🔧.

o Release the LSP after Th, and wait for the next Poisson arrival process 🕊️.

10.7. Typical Testing Cases ✨

10.7.1. With No LSP in the Network ✨

10.7.1.1. Motivation ✨

Data path delay with no LSP in the network is important because this reflects the inherent delay of a device implementation 🧸. The minimum value provides an indication of the delay that will likely be experienced when an LSP data path is configured under light traffic load 🌤️.

10.7.1.2. Methodologies ✨

Make sure that there is no LSP in the network, and proceed with the methodologies described in Section 10.6 🫶.

10.7.2. With a Number of LSPs in the Network ✨

10.7.2.1. Motivation ✨

Data path delay with a number of LSPs in the network is important because it reflects the performance of an operational network with considerable load 🏙️. This delay may vary significantly as the number of existing LSPs varies 📊. It can be used as a scalability metric of a device implementation 🚀.

10.7.2.2. Methodologies 🧚

Okay bestie, this part is literally a three-step recipe 💅

Set up the required number of LSPs.
Wait until the network reaches a stable state.
Then proceed with the methodologies described in Section 10.6.

11. Some Statistics Definitions for Metrics to Report 📊

Now that we have all these samples, we get to do the fun part: summarising them into stats that actually tell us something about a GMPLS network 🦋 Quick heads up, each metric value is either a real number of milliseconds or undefined, and in the discussion below we only look at the finite values ✨

11.1. The Minimum of the Metric 💖

The minimum is just the smallest dT value in the sample. When we compute it, undefined values SHOULD be treated as infinitely large. That means the minimum could itself be undefined if all the dT values are undefined. The metric minimum SHOULD be set to undefined if the sample is empty 🙈

11.2. The Median of the Metric 🍓

The median is the median of the dT values in the given sample, and when we compute it, undefined values MUST NOT be included. The median SHOULD be set to undefined if all the dT values are undefined, or if the sample is empty.

When there are only a few defined values in the sample, the metric median may not be typical, so it SHOULD be used carefully ⚠️

11.3. The Percentile of the Metric 💜

The "empirical distribution function" (EDF) of a set of scalar measurements is a function F(x). For any x, it gives the fractional proportion of the total measurements that were <= x.

Given a percentage X, the Xth percentile of the metric means the smallest value of x for which F(x) >= X. When computing the percentile, undefined values MUST NOT be included.

See [RFC2330] for further details 🔍

11.4. Failure Probability 🔥

Given the samples of the performance metric, we get to report two stats about failure events: Failure Count and Failure Ratio. Both can be applied to the forward data path and the reverse data path. For example, once you've got a sample of RRFD, you can get the forward data path failure stats. A sample of RSRD can be used to calculate the reverse data path failure stats instead. Detailed definitions of both are below 👑

11.4.1. Failure Count 🧮

Failure Count is the number of undefined values of the corresponding performance metric in a sample. It's always an integer.

11.4.2. Failure Ratio 💅

Failure Ratio is the percentage of failure events compared to the total number of requests in a sample. Here, a failure event means that the signaling completes with no error, while no error-free signal is observed. The formula goes like this:

Failure Ratio = Number of undefined value/(Number of valid metric
values + Number of undefined value) * 100%.

12. Security Considerations 🔐

Okay, this section is serious, so I'm going to be serious too 😭

In the control plane, the measurement endpoints must be conformant to signaling specifications and behave as normal signaling endpoints. So it will not incur security issues other than normal LSP provisioning. However, the measurement parameters must be carefully selected so that the measurements inject trivial amounts of additional traffic into the networks they measure. If they inject "too much" traffic, they can skew the results of the measurement and, in extreme cases, cause congestion and denial of service.

In the data plane, the measurement endpoint MUST use a signal that is consistent with what is specified in the control plane. For example, in a packet switched case, the traffic injected into the data plane MUST NOT exceed the specified rate in the corresponding LSP setup request. In a wavelength switched case, the measurement endpoint MUST use the specified or negotiated lambda with appropriate power.

The security considerations pertaining to the original RSVP protocol [RFC2205] and its TE extensions [RFC3209] also remain relevant 🚨

13. References 📚

13.1. Normative References 💖

[RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
           Requirement Levels", BCP 14, RFC 2119, March 1997.

[RFC2205]  Braden, B., Zhang, L., Berson, S., Herzog, S., and S.
           Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1
           Functional Specification", RFC 2205, September 1997.

[RFC2679]  Almes, G., Kalidindi, S., and M. Zekauskas, "A One-way
           Delay Metric for IPPM", RFC 2679, September 1999.

[RFC2681]  Almes, G., Kalidindi, S., and M. Zekauskas, "A Round-trip
           Delay Metric for IPPM", RFC 2681, September 1999.

[RFC3209]  Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V.,
           and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP
           Tunnels", RFC 3209, December 2001.

13.2. Informative References 🧠

[RFC2330]  Paxson, V., Almes, G., Mahdavi, J., and M. Mathis,
           "Framework for IP Performance Metrics", RFC 2330,
           May 1998.

[RFC4208]  Swallow, G., Drake, J., Ishimatsu, H., and Y. Rekhter,
           "Generalized Multiprotocol Label Switching (GMPLS) User-
           Network Interface (UNI): Resource ReserVation Protocol-
           Traffic Engineering (RSVP-TE) Support for the Overlay
           Model", RFC 4208, October 2005.

[RFC5814]  Sun, W. and G. Zhang, "Label Switched Path (LSP) Dynamic
           Provisioning Performance Metrics in Generalized MPLS
           Networks", RFC 5814, March 2010.

[RFC6383]  Shiomoto, K. and A. Farrel, "Advice on When It Is Safe to
           Start Sending Data on Label Switched Paths Established
           Using RSVP-TE", RFC 6383, September 2011.

Appendix A. Acknowledgements 🫶

We wish to thank Adrian Farrel, Lou Berger, and Al Morton for their comments and help, and we also wish to thank Klaas Wierenga and Alexey Melnikov for their reviews 💕

This document has ideas as well as text that already appeared in existing IETF documents. The authors wish to thank G. Almes, S. Kalidindi, and M. Zekauskas for that 🌸

We also wish to thank Weisheng Hu, Yaohui Jin, and Wei Guo in the state key laboratory of advanced optical communication systems and networks for their valuable comments. We also wish to thank the National Natural Science Foundation of China (NSFC) and the 863 program of China for their support 🇨🇳✨

Appendix B. Contributors 🎀

Bin Gu
IXIA
Oriental Kenzo Plaza 8M, 48 Dongzhimen Wai Street
Dongcheng District
Beijing  200240
China

Phone: +86 13611590766
EMail: BGu@ixiacom.com


Xueqin Wei
Fiberhome Telecommunication Technology Co., Ltd.
Wuhan
China

Phone: +86 13871127882
EMail: xqwei@fiberhome.com.cn


Tomohiro Otani
KDDI R&D Laboratories, Inc.
2-1-15 Ohara Kamifukuoka Saitama
356-8502
Japan

Phone: +81-49-278-7357
EMail: tm-otani@kddi.com


Ruiquan Jing
China Telecom Beijing Research Institute
118 Xizhimenwai Avenue
Beijing  100035
China

Phone: +86-10-58552000
EMail: jingrq@ctbri.com.cn

Authors' Addresses 🦋

Weiqiang Sun (editor)
Shanghai Jiao Tong University
800 Dongchuan Road
Shanghai  200240
China

Phone: +86 21 3420 5359
EMail: sun.weiqiang@gmail.com


Guoying Zhang (editor)
China Academy of Telecommunication Research, MIIT, China
No. 52 Hua Yuan Bei Lu, Haidian District
Beijing  100191
China

Phone: +86 1062300103
EMail: zhangguoying@catr.cn


Jianhua Gao
Huawei Technologies Co., Ltd.
China

Phone: +86 755 28973237
EMail: gjhhit@huawei.com


Guowu Xie
University of California, Riverside
900 University Ave.
Riverside, CA  92521
USA

Phone: +1 951 237 8825
EMail: xieg@cs.ucr.edu


Rajiv Papneja
Huawei Technologies
Santa Clara, CA  95050
Reston, VA  20190
USA

EMail: rajiv.papneja@huawei.com

📦 where this page comes from

ietf: rfc6777 2012-11
💖 girlified by claude-haiku-5-5 on 2026-10-17: a language model's rewrite of the original, under its terms