RFC 5814

RFC 5814 🎀 (Part 1 of 9)

okay bestie, this is RFC 5814 💖, and it's a Standards Track doc, which means it's officially part of the Internet's protocol family tree 🌳. It's titled "Label Switched Path (LSP) Dynamic Provisioning Performance Metrics in Generalized MPLS Networks" ✨. It was written by W. Sun, Ed. from SJTU and G. Zhang, Ed. from CATR 🫶. It was published in March 2010 and has ISSN 2070-1721 📅. The header doesn't list anything it obsoletes or updates, so it's standing on its own 👑.

Abstract ✨

okay so GMPLS (Generalized Multi-Protocol Label Switching) is giving future of data transmission 🔥. It was built to control and run all kinds of network gear, not just regular routers and switches 🌈. We're talking Dense Wavelength Division Multiplexing (DWDM) systems, Add-Drop Multiplexers (ADMs), photonic cross-connects (PXCs), optical cross-connects (OXCs), and more 🦋. These devices are wildly different when it comes to dynamic provisioning, which is how fast and flexibly they can set up connections on the fly 😭. Meanwhile, people want more dynamically provisioned connections because optical networks are popping up in metro areas 🏙️. Different apps need different things from provisioning performance, so it's literally imperative to define standard metrics and procedures. That way, network performance and app needs can be matched up 💅.

This document gives a set of performance metrics for judging dynamic Label Switched Path (LSP) provisioning in GMPLS networks, specifically how well dynamic LSP setup and release work 🧚. These metrics help describe what makes a GMPLS network tick when it comes to LSP dynamic provisioning 💜.

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 went through public review and was 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 is at http://www.rfc-editor.org/info/rfc5814 🔗.

Copyright Notice 🌈

Copyright (c) 2010 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), which were in effect on the date this document was published 📜. Please read these carefully, because they spell out your rights and restrictions for this document 🙈. Code Components pulled out of this document must include Simplified BSD License text, as described in Section 4.e of the Trust Legal Provisions, and they come without warranty, as described in the Simplified BSD License 💅.

This document may contain material from IETF Documents or IETF Contributions that were published or made publicly available before November 10, 2008 🍓. The people who control the copyright in some of that material may not have given the IETF Trust permission to allow modifications outside the IETF Standards Process 😭. Unless you get an adequate license from the people who control the copyright in those materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process 💀. The exceptions are formatting it for publication as an RFC or translating it into languages other than English 🌸.

Table of Contents 📋

   1. Introduction ....................................................6
   2. Conventions Used in This Document ...............................6
   3. Overview of Performance Metrics .................................6
   4. A Singleton Definition for Single Unidirectional LSP
      Setup Delay .....................................................7
      4.1. Motivation .................................................7
      4.2. Metric Name ................................................7
      4.3. Metric Parameters ..........................................8
      4.4. Metric Units ...............................................8
      4.5. Definition .................................................8
      4.6. Discussion .................................................8
      4.7. Methodologies ..............................................9
      4.8. Metric Reporting ...........................................9
   5. A Singleton Definition for Multiple Unidirectional LSPs
      Setup Delay ....................................................10
      5.1. Motivation ................................................10
      5.2. Metric Name ...............................................10
      5.3. Metric Parameters .........................................10
      5.4. Metric Units ..............................................10
      5.5. Definition ................................................11
      5.6. Discussion ................................................11
      5.7. Methodologies .............................................12
      5.8. Metric Reporting ..........................................13
   6. A Singleton Definition for Single Bidirectional LSP
      Setup Delay ....................................................13
      6.1. Motivation ................................................13
      6.2. Metric Name ...............................................14
      6.3. Metric Parameters .........................................14
      6.4. Metric Units ..............................................14
      6.5. Definition ................................................14
      6.6. Discussion ................................................15
      6.7. Methodologies .............................................15
      6.8. Metric Reporting ..........................................16
   7. A Singleton Definition for Multiple Bidirectional LSPs
      Setup Delay ....................................................16
      7.1. Motivation ................................................16
      7.2. Metric Name ...............................................16
      7.3. Metric Parameters .........................................17
      7.4. Metric Units ..............................................17
      7.5. Definition ................................................17
      7.6. Discussion ................................................18
      7.7. Methodologies .............................................19
      7.8. Metric Reporting ..........................................19
   8. A Singleton Definition for LSP Graceful Release Delay ..........20
      8.1. Motivation ................................................20
      8.2. Metric Name ...............................................20
      8.3. Metric Parameters .........................................20
      8.4. Metric Units ..............................................20
      8.5. Definition ................................................20
      8.6. Discussion ................................................22
      8.7. Methodologies .............................................22
      8.8. Metric Reporting ..........................................23
   9. A Definition for Samples of Single Unidirectional LSP
      Setup Delay ....................................................24
      9.1. Metric Name ...............................................24
      9.2. Metric Parameters .........................................24
      9.3. Metric Units ..............................................24
      9.4. Definition ................................................24
      9.5. Discussion ................................................25
      9.6. Methodologies .............................................25
      9.7. Typical Testing Cases .....................................26
           9.7.1. With No LSP in the Network .........................26
           9.7.2. With a Number of LSPs in the Network ...............26
      9.8. Metric Reporting ..........................................26
   10. A Definition for Samples of Multiple Unidirectional
       LSPs Setup Delay ..............................................26
      10.1. Metric Name ..............................................27
      10.2. Metric Parameters ........................................27
      10.3. Metric Units .............................................27
      10.4. Definition ...............................................27
      10.5. Discussion ...............................................28
      10.6. Methodologies ............................................28
      10.7. Typical Testing Cases ....................................29
           10.7.1. With No LSP in the Network ........................29
           10.7.2. With a Number of LSPs in the Network ..............29
      10.8. Metric Reporting .........................................29
   11. A Definition for Samples of Single Bidirectional LSP
       Setup Delay ...................................................30
      11.1. Metric Name ..............................................30
      11.2. Metric Parameters ........................................30
      11.3. Metric Units .............................................30
      11.4. Definition ...............................................30
      11.5. Discussion ...............................................31
      11.6. Methodologies ............................................31
      11.7. Typical Testing Cases ....................................32
           11.7.1. With No LSP in the Network ........................32
           11.7.2. With a Number of LSPs in the Network ..............32
      11.8. Metric Reporting .........................................32
   12. A Definition for Samples of Multiple Bidirectional
       LSPs Setup Delay ..............................................32
      12.1. Metric Name ..............................................33
      12.2. Metric Parameters ........................................33
      12.3. Metric Units .............................................33
      12.4. Definition ...............................................33
      12.5. Discussion ...............................................34
      12.6. Methodologies ............................................34
      12.7. Typical Testing Cases ....................................35
           12.7.1. With No LSP in the Network ........................35
           12.7.2. With a Number of LSPs in the Network ..............35
      12.8. Metric Reporting .........................................35
   13. A Definition for Samples of LSP Graceful Release Delay ........35
      13.1. Metric Name ..............................................36
      13.2. Metric Parameters ........................................36
      13.3. Metric Units .............................................36
      13.4. Definition ...............................................36
      13.5. Discussion ...............................................36
      13.6. Methodologies ............................................37
      13.7. Metric Reporting .........................................37
   14. Some Statistics Definitions for Metrics to Report .............37
      14.1. The Minimum of Metric ....................................37
      14.2. The Median of Metric .....................................37
      14.3. The Maximum of Metric ....................................38
      14.4. The Percentile of Metric .................................38
      14.5. Failure Statistics of Metric .............................38
           14.5.1. Failure Count .....................................39
           14.5.2. Failure Ratio .....................................39
   15. Discussion ....................................................39
   16. Security Considerations .......................................40
   17. Acknowledgments ...............................................41
   18. References ....................................................41
      18.1. Normative References .....................................41
      18.2. Informative References ...................................42
   Appendix A.  Authors' Addresses ...................................43

---

1. Introduction 🚀

Okay so, Generalized Multi-Protocol Label Switching (GMPLS) is giving one of the most promising control plane solutions for future transport and service networks 💅✨. It's built to control and operate a whole bunch of different network elements: conventional routers, switches, Dense Wavelength Division Multiplexing (DWDM) systems, Add-Drop Multiplexors (ADMs), photonic cross-connects (PXCs), optical cross-connects (OXCs), and more 🌈. These devices are wildly different from each other when it comes to dynamic provisioning ability, so it's a lot 😭.

The introduction of a control plane into optical circuit switching networks is the basis for automating how connections get provisioned, and it drastically reduces connection provision delay 🦋. More and more services and apps want to run over GMPLS-controlled networks as their transport layer, and they want to do it dynamically 🔥. So the need is growing to measure and characterize how well LSP provisioning works in GMPLS networks, so that what an application needs can be matched up with what the network can actually deliver 🎀.

This document defines performance metrics and methodologies that can be used to characterize the dynamic LSP provisioning performance of GMPLS networks. More specifically, it's about the performance of the signaling protocol 🧚. The metrics defined here can be used to characterize the average performance of GMPLS implementations 💜.

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]. Those are the official rules words, so read them carefully bestie 💖.

3. Overview of Performance Metrics 🍓

In this memo, we're characterizing the dynamic LSP provisioning performance of a GMPLS network. We define three performance metrics 🌸: unidirectional LSP setup delay, bidirectional LSP setup delay, and LSP graceful release delay. The latency of the LSP setup/release signal is conceptually similar to the Round-trip Delay in IP networks, which is a vibe we already know ⭐. That lets us reuse the structures and notions from the IP Performance Metrics (IPPM) Framework documents, [RFC2330] [RFC2679] [RFC2681]. The reader is assumed to already be familiar with the notions in those documents, so go check them out first 🙈.

Quick aside: data-path-related metrics are a different thing. Stuff like the time between the reception of a Resv message by the ingress node and when the forward data path becomes operational is defined in another document, [CCAMP-DPM]. It's desirable that both measurements get performed, because they complement each other 🫶.

4. A Singleton Definition for Single Unidirectional LSP Setup Delay 👑

Here we define a metric for single unidirectional Label Switched Path setup delay across a GMPLS network ✨. This is the first real metric, so let's get into it 💅.

4.1. Motivation ✨

okay so single unidirectional LSP setup delay is lowkey important, and here's why 💅

• This metric is a big deal for judging how fast a GMPLS network can provision things 🚀. A longer LSP setup delay usually means more overhead for the app asking for the LSP, especially when the LSP's lifetime is about the same as the setup delay itself 😭
• The minimum value tells you the delay you'll probably see when the LSP takes the shortest route at the lightest control plane load 🧚. The delay is made up of pieces like link propagation delay and nodal processing delay, so this metric also tells you how the control plane is doing 👀. For example, if LSPs on the same route keep taking longer to set up, that might mean the control channel is congested or a control element is overloaded 🔥. So yeah, it's super useful for testing and diagnostics 🩺
• The variance in a sample of LSP setup delay values can be an early sign of whether a network can support apps with strict setup delay requirements 🎯

Measuring single unidirectional LSP setup delay instead of bidirectional LSP setup delay makes sense for these reasons:

• Some apps only use unidirectional LSPs, not bidirectional ones 🌈. Content delivery services with multicasting are a good example, since they may only use unidirectional LSPs 📺

4.2. Metric Name

Single unidirectional LSP setup delay

4.3. Metric Parameters

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

4.4. Metric Units

The value of single unidirectional LSP setup delay is either a real number of milliseconds or undefined 🍓

4.5. Definition

Here's the vibe for a real number result 💖. The single unidirectional LSP setup delay from ingress node ID0 to egress node ID1 [RFC3945] at T is dT means that ingress node ID0 sends the first bit of a Path message packet to egress node ID1 at wire-time T, and that ingress node ID0 received the last bit of the responding Resv message packet from egress node ID1 at wire-time T+dT. 🦋

Now the undefined case 🙈. The single unidirectional LSP setup delay from ingress node ID0 to egress node ID1 at T is undefined means that ingress node ID0 sends the first bit of the Path message packet to egress node ID1 at wire-time T, and that ingress node ID0 does not receive the corresponding Resv message within a reasonable period of time 💀.

The undefined value is basically how this metric says "the setup failed" 😤. It's an event of Single Unidirectional LSP Setup Failure, and it's what you'd use to report a count or a percentage of those failures. See Section 14.5 for definitions of LSP setup/release failures 📚.

4.6. Discussion

These are the issues you'll probably run into IRL 🫶:

• The accuracy of unidirectional LSP setup delay at time T depends on the clock resolution in the ingress node 🕰️. But the ingress and egress nodes don't need to be synchronized, since unidirectional LSP setup uses two-way signaling 🔁
• Your methodology needs a way to tell whether a latency value is infinite or just really, really large 🤔. Simple upper bounds MAY be used, but GMPLS networks can include lots of different kinds of devices 🧩. For example, some photonic cross-connects (PXCs) have to move micro mirrors 🪞. That physical motion may take several milliseconds, but common electronic switches can finish nodal processing in several microseconds ⚡. So the unidirectional LSP setup delay varies wildly from one network to another 🎢. In practice, the upper bound SHOULD be chosen carefully 🧐
• If the ingress node sends out the Path message to set up an LSP but never gets the corresponding Resv message back, the unidirectional LSP setup delay MUST be set to undefined 🙃
• If the ingress node sends out the Path message to set up an LSP but gets a PathErr message back, the unidirectional LSP setup delay MUST be set to undefined 🚫. There are lots of possible reasons for this, like the Path message having invalid parameters, or the network not having enough resources to set up the requested LSP, etc 🤷‍♀️

4.7. Methodologies

Generally, the methodology goes like this 🗺️:

• Make sure the network has enough resources to set up the requested LSP ✅
• At the ingress node, form the Path message according to the LSP requirements 📝. A timestamp (T1) may be stored locally on the ingress node when the Path message packet is sent toward the egress node ⏱️
• If the corresponding Resv message arrives within a reasonable period of time, take the timestamp (T2) as soon as possible after receiving it 🫰. Subtract the two timestamps and you get an estimate of unidirectional LSP setup delay (T2-T1) 🧮
• If the corresponding Resv message fails to arrive within a reasonable period of time, the unidirectional LSP setup delay is deemed to be undefined 🫠. Note that the "reasonable" threshold is a parameter of the methodology 🎚️
• If the corresponding response is a PathErr message, the unidirectional LSP setup delay is deemed to be undefined 💔

4.8. Metric Reporting

The metric result (either a real number or undefined) MUST be reported together with the selected upper bound 📊. The route the LSP traverses MUST also be reported 🛣️. The route MAY be collected by using the record route object, see [RFC3209], or through the management plane 🗂️. Collecting routes through the management plane is out of scope for this document 🙅‍♀️.

---

5. A Singleton Definition for Multiple Unidirectional LSPs Setup Delay 👑

This section defines a metric for multiple unidirectional Label Switched Paths setup delay across a GMPLS network 🌐.

5.1. Motivation

Multiple unidirectional Label Switched Paths setup delay is useful for a few reasons 💜:

• Carriers may need a bunch of LSPs set up in a short time window 😳. This could happen because established LSPs got interrupted or because of other network failures 🌩️
• You can't figure out how long it takes to set up a large number of LSPs in a short window just from single LSP setup delay 🙅‍♀️

5.2. Metric Name

Multiple unidirectional LSPs setup delay

5.3. Metric Parameters

• ID0, the ingress LSR ID 🎀
• ID1, the egress LSR ID 🎀
• Lambda_m, a rate in reciprocal milliseconds 🔢
• X, the number of LSPs to set up 🔟
• T, a time when the first setup is attempted ⏰

5.4. Metric Units

The value of multiple unidirectional LSPs setup delay is either a real number of milliseconds or undefined 🍭

5.5. Definition

Given Lambda_m and X, the multiple unidirectional LSPs setup delay from the ingress node to the egress node [RFC3945] at T is dT means:

• ingress node ID0 sends the first bit of the first Path message packet to egress node ID1 at wire-time T; 🚀
• all subsequent (X-1) Path messages are sent according to the specified Poisson process with arrival rate Lambda_m; 🎲
• ingress node ID0 receives all corresponding Resv message packets from egress node ID1; and 📬
• ingress node ID0 receives the last Resv message packet at wire-time T+dT. 🏁

If the multiple unidirectional LSPs setup delay at T is "undefined", this means that: 💀

• ingress node ID0 sends all the Path messages toward egress node ID1, 📤
• the first bit of the first Path message packet is sent at wire-time T, and ⏱️
• ingress node ID0 does not receive one or more of the corresponding Resv messages within a reasonable period of time 😵‍💫.

The undefined value of this metric indicates an event of Multiple Unidirectional LSP Setup Failure, and it's what you'd use to report a count or a percentage of Multiple Unidirectional LSP Setup failures 📉. See Section 14.5 for definitions of LSP setup/release failures 📚.

5.6. Discussion

These are the issues you'll probably hit in practice 🫶:

• The accuracy of multiple unidirectional LSPs setup delay at time T depends on the clock resolution in the ingress node 🕰️. But the ingress and egress nodes don't need to be synchronized, since unidirectional LSP setup uses two-way signaling 🔁
• Your methodology needs a way to tell whether a latency value is infinite or just very large 🤔. Simple upper bounds MAY be used, but GMPLS networks can include lots of different kinds of devices 🧩. For example, some photonic cross-connects (PXCs) have to move micro mirrors 🪞. That physical motion may take several milliseconds, but electronic switches can finish nodal processing within several microseconds ⚡. So the multiple unidirectional LSP setup delay varies wildly from one network to another 🎢. In practice, the upper bound SHOULD be chosen carefully 🧐
• If the ingress node sends out the multiple Path messages to set up the LSPs but never gets one or more of the corresponding Resv messages back, multiple unidirectional LSP setup delay MUST be set to undefined 🙃
• If the ingress node sends out the Path messages to set up the LSPs but gets one or more PathErr messages back, multiple unidirectional LSPs setup delay MUST be set to undefined 🚫. There are lots of possible reasons for this. For example, one of the Path messages has invalid parameters, or the network doesn't have enough resources to set up the requested LSPs, etc 🤷‍♀️
• The arrival rate of the Poisson process Lambda_m SHOULD be chosen carefully 🎯. On one hand, the control plane shouldn't be overburdened 😮‍💨. On the other hand, the arrival rate should be high enough to meet the requirements of applications or services 🚀
• It's important that all the LSPs MUST traverse the same route 🛤️. If there are multiple routes between ingress node ID0 and egress node ID1, Explicit Route Objects (EROs), or an alternate method (e.g., static configuration), MUST be used to make sure all LSPs traverse the same route 🔒

5.7. Methodologies

Generally, the methodology goes like this 🗺️:

• Make sure the network has enough resources to set up the requested LSPs ✅
• At the ingress node, form the Path messages according to the LSPs' requirements 📝
• At the ingress node, pick the time for each of the Path messages according to the specified Poisson process 🎲
• At the ingress node, send out the Path messages according to the selected times 📤
• Store a timestamp (T1) locally on the ingress node when the first Path message packet is sent toward the egress node ⏱️
• If all of the corresponding Resv messages arrive within a reasonable period of time, take the final timestamp (T2) as soon as possible after receiving all the messages. Subtract the two timestamps and you get an estimate of multiple unidirectional LSPs setup delay (T2-T1) 🧮
• If one or more of the corresponding Resv messages fail to arrive within a reasonable period of time, the multiple unidirectional LSPs setup delay is deemed to be undefined 🫠. Note that the "reasonable" threshold is a parameter of the methodology 🎚️
• If one or more of the corresponding responses are PathErr messages, the multiple unidirectional LSPs setup delay is deemed to be undefined 💔

5.8. Metric Reporting 📝

Okay so the metric result (a real number or undefined) MUST be reported together with the selected upper bound 🎀. The route that the LSPs traverse MUST also be reported 🗺️. The route MAY be collected by using the record route object (see [RFC3209]), or via the management plane. Collecting routes via the management plane is out of scope of this doc 🙈.

6. A Singleton Definition for Single Bidirectional LSP Setup Delay 🦋

GMPLS allows establishment of bidirectional symmetric LSPs (not asymmetric LSPs, sorry bestie 🙅). This section defines a metric for single bidirectional LSP setup delay across a GMPLS network 💜.

6.1. Motivation 🌸

Single bidirectional Label Switched Path setup delay is useful for several reasons:

• LSP setup delay is an important metric that characterizes the provisioning performance of a GMPLS network. A longer LSP setup delay adds more overhead for the requesting application, especially when the LSP duration is comparable to the LSP setup delay. So measuring the setup delay is important for application scheduling 📅.
• The minimum value of this metric gives an indication of the delay that will likely be experienced when the LSP traverses the shortest route at the lightest load in the control plane. Since the delay is made up of several components, such as link propagation delay and nodal processing delay, this metric also reflects the status of the control plane 🧠. For example, for LSPs traversing the same route, longer setup delays may suggest congestion in the control channel or high control element load. For this reason, this metric is useful for testing and diagnostic purposes 🔍.
• LSP setup delay variance has a different impact on applications. Erratic variation in LSP setup delay makes it difficult to support applications that have stringent setup delay requirements 😭.

The measurement of single bidirectional LSP setup delay, instead of unidirectional LSP setup delay, is motivated by the following factors:

• Bidirectional LSPs are seen as a requirement for many GMPLS networks. Their provisioning performance is important to applications that generate bidirectional traffic 🔁.

6.2. Metric Name 🏷️

Single bidirectional LSP setup delay

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 single bidirectional LSP setup delay is either a real number of milliseconds or undefined.

6.5. Definition 💅

For a real number dT, the single bidirectional LSP setup delay from ingress node ID0 to egress node ID1 at T is dT means that ingress node ID0 sends out the first bit of a Path message including an Upstream Label [RFC3473] heading for egress node ID1 at wire-time T, egress node ID1 receives that packet, then immediately sends a Resv message packet back to ingress node ID0, and that ingress node ID0 receives the last bit of the Resv message packet at wire-time T+dT.

If the single bidirectional LSP setup delay from ingress node ID0 to egress node ID1 at T is "undefined", this means that ingress node ID0 sends the first bit of a Path message to egress node ID1 at wire-time T and that ingress node ID0 does not receive that response packet within a reasonable period of time ⏳.

The undefined value of this metric indicates an event of Single Bidirectional LSP Setup Failure 💀, and would be used to report a count or a percentage of Single Bidirectional LSP Setup failures. See Section 14.5 for definitions of LSP setup/release failures.

6.6. Discussion 💬

The following issues are likely to come up in practice:

• The accuracy of single bidirectional LSP setup delay depends on the clock resolution in the ingress node. But synchronization between the ingress node and egress node is not required, since single bidirectional LSP setup uses two-way signaling 🤝.
• A given methodology will have to include a way to determine whether a latency value is infinite or whether it is merely very large. Simple upper bounds MAY be used, but GMPLS networks may accommodate many kinds of devices. For example, some photonic cross-connects (PXCs) have to move micro mirrors. This physical motion may take several milliseconds, but electronic switches can finish the nodal processing within several microseconds. So the bidirectional LSP setup delay varies drastically from one network to another 🌪️. In the process of bidirectional LSP setup, if the downstream node overrides the label suggested by the upstream node, the setup delay may also increase. Thus, in practice, the upper bound SHOULD be chosen carefully ⚖️.
• If the ingress node sends out the Path message to set up the LSP, but never receives the corresponding Resv message, single bidirectional LSP setup delay MUST be set to undefined.
• If the ingress node sends out the Path message to set up the LSP, but receives a PathErr message, single bidirectional LSP setup delay MUST be set to undefined. There are many possible reasons for this case. For example, the Path message has invalid parameters or the network does not have enough resources to set up the requested LSP 🙃.

6.7. Methodologies 🧪

Generally, the methodology would proceed as follows:

• Make sure that the network has enough resources to set up the requested LSP ✅.
• At the ingress node, form the Path message (including the Upstream Label or suggested label) according to the LSP requirements. A timestamp (T1) MAY be stored locally on the ingress node when the Path message packet is sent towards the egress node.

Wait, the original says "may", lowercase. Keep it lowercase exactly as written; I'll correct that line below in the final output.

• If the corresponding Resv message arrives within a reasonable period of time, take the final timestamp (T2) as soon as possible upon receipt of the message. By subtracting the two timestamps, an estimate of bidirectional LSP setup delay (T2-T1) can be computed 🧮.
• If the corresponding Resv message fails to arrive within a reasonable period of time, the single bidirectional LSP setup delay is deemed to be undefined. Note that the "reasonable" threshold is a parameter of the methodology.
• If the corresponding response is a PathErr message, the single bidirectional LSP setup delay is deemed to be undefined.

6.8. Metric Reporting 📝

The metric result (either a real number or undefined) MUST be reported together with the selected upper bound. The route that the LSP traverses MUST also be reported 🗺️. The route MAY be collected by using the record route object (see [RFC3209]), or via the management plane. Collecting routes via the management plane is out of scope of this document 🙈.

7. A Singleton Definition for Multiple Bidirectional LSPs Setup Delay 🌈

This section defines a metric for multiple bidirectional LSPs setup delay across a GMPLS network 🚀.

7.1. Motivation 🌟

Multiple bidirectional LSPs setup delay is useful for several reasons:

• Upon traffic interruption caused by network failure or network upgrade, carriers may require a large number of LSPs to be set up during a short time period 🚨.
• The time needed to set up a large number of LSPs during a short time period cannot be deduced from single LSP setup delay 🤯.

7.2. Metric Name 🏷️

Multiple bidirectional LSPs setup delay

7.3. Metric Parameters 🎛️

• ID0, the ingress LSR ID
• ID1, the egress LSR ID
• Lambda_m, a rate in reciprocal milliseconds
• X, the number of LSPs to set up
• T, a time when the first setup is attempted

7.4. Metric Units 📏

The value of multiple bidirectional LSPs setup delay is either a real number of milliseconds or undefined.

7.5. Definition 💅

Given Lambda_m and X, for a real number dT, the multiple bidirectional LSPs setup delay from ingress node to egress node at T is dT, means that:

• Ingress node ID0 sends the first bit of the first Path message heading for egress node ID1 at wire-time T;
• All subsequent (X-1) Path messages are sent according to the specified Poisson process with arrival rate Lambda_m;
• Ingress node ID1 receives all corresponding Resv message packets from egress node ID1; and
• Ingress node ID0 receives the last Resv message packet at wire-time T+dT.

If the multiple bidirectional LSPs setup delay from ingress node to egress node at T is "undefined", this means that the ingress node sends all the Path messages to the egress node and that the ingress node fails to receive one or more of the response Resv messages within a reasonable period of time 😬.

The undefined value of this metric indicates an event of Multiple Bidirectional LSP Setup Failure, and would be used to report a count or a percentage of Multiple Bidirectional LSP Setup failures. See Section 14.5 for definitions of LSP setup/release failures.

7.6. Discussion 💬

The following issues are likely to come up in practice:

• The accuracy of multiple bidirectional LSPs setup delay depends on the clock resolution in the ingress node. But synchronization between the ingress node and egress node is not required, since bidirectional LSP setup uses two-way signaling 🤝.
• A given methodology will have to include a way to determine whether a latency value is infinite or whether it is merely very large. Simple upper bounds MAY be used, but GMPLS networks may accommodate many kinds of devices. For example, some photonic cross-connects (PXCs) have to move micro mirrors. This physical motion may take several milliseconds, but electronic switches can finish the nodal process within several microseconds. So the multiple bidirectional LSPs setup delay varies drastically from one network to another 🌪️. In the process of multiple bidirectional LSPs setup, if the downstream node overrides the label suggested by the upstream node, the setup delay may also increase. Thus, in practice, the upper bound SHOULD be chosen carefully ⚖️.
• If the ingress node sends out the Path messages to set up the LSPs, but never receives all the corresponding Resv messages, the multiple bidirectional LSPs setup delay MUST be set to undefined.
• If the ingress node sends out the Path messages to set up the LSPs, but receives one or more responding PathErr messages, the multiple bidirectional LSPs setup delay MUST be set to undefined. There are many possible reasons for this case. For example, one or more of the Path messages have invalid parameters or the network does not have enough resources to set up the requested LSPs 🙃.
• The arrival rate of the Poisson process Lambda_m SHOULD be carefully chosen such that, on the one hand, the control plane is not overburdened. On the other hand, the arrival rate is large enough to meet the requirements of applications or services 🎯.
• It is important that all the LSPs MUST traverse the same route. If there are multiple routes between the ingress node ID0 and egress node ID1, EROs, or an alternate method, e.g., static configuration, MUST be used to ensure that all LSPs traverse the same route 🛣️✨.

7.7. Methodologies ✨

Okay so the methodology basically goes like this, bestie 🎀

• Make sure the network has enough resources to set up the requested LSPs. 💅
• At the ingress node, form the Path messages (including the Upstream Label or suggested label) according to the LSPs' requirements.
• At the ingress node, select the time for each of the Path messages according to the specified Poisson process.
• At the ingress node, send out the Path messages according to the selected time.
• Store a timestamp (T1) locally in the ingress node when the first Path message packet is sent towards the egress node. ⏱️
• If all of the corresponding Resv messages arrive within a reasonable period of time, take the final timestamp (T2) as soon as possible upon the receipt of all the messages. By subtracting the two timestamps, an estimate of multiple bidirectional LSPs setup delay (T2-T1) can be computed. 🔥
• If one or more of the corresponding Resv messages fail to arrive within a reasonable period of time, the multiple bidirectional LSPs setup delay is deemed to be undefined. Note that the "reasonable" threshold is a parameter of the methodology. 🫶
• If one or more of the corresponding responses are PathErr messages, the multiple bidirectional LSPs setup delay is deemed to be undefined. 😭

7.8. Metric Reporting 🦋

The metric result (either a real number or undefined) MUST be reported together with the selected upper bound. The route that the LSPs traverse MUST also be reported. The route MAY be collected via use of the record route object, see [RFC3209], or via the management plane. The collection of routes via the management plane is out of scope of this document. 📋

8. A Singleton Definition for LSP Graceful Release Delay 🌸

There are two different kinds of LSP release mechanisms in GMPLS networks: graceful release and forceful release. This document does not take forceful LSP release procedure into account. So we're focusing on the graceful kind, periodt 💜

8.1. Motivation 🧚

LSP graceful release delay is useful for several reasons:

• The LSP graceful release delay is part of the total cost of dynamic LSP provisioning. For some short duration applications, the LSP release time cannot be ignored. ⏳
• The LSP graceful release procedure is more preferred in a GMPLS controlled network, particularly the optical networks. Since it doesn't trigger restoration/protection, it is "alarm-free connection deletion" in [RFC4208]. It's giving clean exit energy 🚪✨

8.2. Metric Name 🏷️

LSP graceful release delay

8.3. Metric Parameters 📝

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

8.4. Metric Units 📏

The value of LSP graceful release delay is either a real number of milliseconds or undefined

8.5. Definition 💖

Okay, this is the juicy part. There are two different LSP graceful release procedures: one is initiated by the ingress node, and another is initiated by the egress node. The two procedures are depicted in [RFC3473]. We define the graceful LSP release delay for these two procedures separately. Main character energy 👑

For a real number dT, if the LSP graceful release delay from ingress node ID0 to egress node ID1 at T is dT, this means that ingress node ID0 sends the first bit of a Path message including an Admin Status Object with the Reflect (R) and Delete (D) bits set to the egress node at wire-time T, that egress node ID1 receives that packet, then immediately sends a Resv message including an Admin Status Object with the Delete (D) bit set back to the ingress node. Ingress node ID0 sends the PathTear message downstream to remove the LSP, and egress node ID1 receives the last bit of PathTear packet at wire-time T+dT. 🦋

Also, as an option, upon receipt of the Path message including an Admin Status Object with the Reflect (R) and Delete (D) bits set, egress node ID1 may respond with a PathErr message with the Path_State_Removed flag set.

The LSP graceful release delay from ingress node ID0 to egress node ID1 at T is undefined means that ingress node ID0 sends the first bit of Path message to egress node ID1 at wire-time T and that (either the egress node does not receive the Path packet, the egress node does not send a corresponding Resv message packet in response, or the ingress node does not receive that Resv packet, and) egress node ID1 does not receive the PathTear message within a reasonable period of time. 💀

If the LSP graceful release delay from egress node ID1 to ingress node ID0 at T is dT, this means that egress node ID1 sends the first bit of a Resv message including an Admin Status Object with the Reflect (R) and Delete (D) bits set to the ingress node at wire-time T. Ingress node ID0 sends a PathTear message downstream to remove the LSP, and egress node ID1 receives the last bit of PathTear packet at wire-time T+dT. 🌈

If the LSP graceful release delay from egress node ID1 to ingress node ID0 at T is "undefined", this means that egress node ID1 sends the first bit of Resv message including an Admin Status Object with the Reflect (R) and Delete (D) bits set to the ingress node ID0 at wire-time T and that (either the ingress node does not receive the Resv packet or the ingress node does not send PathTear message packet in response, and) egress node ID1 does not receive the PathTear message within a reasonable period of time. 🙈

The undefined value of this metric indicates an event of LSP Graceful Release Failure and would be used to report a count or a percentage of LSP Graceful Release failures. See Section 14.5 for definitions of LSP setup/release failures. ❌

8.6. Discussion 🗣️

The following issues are likely to come up in practice:

• In the first (second) circumstance, the accuracy of LSP graceful release delay at time T depends on the clock resolution in the ingress (egress) node. In the first circumstance, synchronization between the ingress node and egress node is required, but it is not in the second circumstance.
• A given methodology has to include a way to determine whether a latency value is infinite or whether it is merely very large. Simple upper bounds MAY be used, but the upper bound SHOULD be chosen carefully in practice. 🧐
• In the first circumstance, if the ingress node sends out Path message including an Admin Status Object with the Reflect (R) and Delete (D) bits set to initiate LSP graceful release, but the egress node never receives the corresponding PathTear message, LSP graceful release delay MUST be set to undefined. 🚫
• In the second circumstance, if the egress node sends out the Resv message including an Admin Status Object with the Reflect (R) and Delete (D) bits set to initiate LSP graceful release, but never receives the corresponding PathTear message, LSP graceful release delay MUST be set to undefined. 🚫

8.7. Methodologies 🛠️

In the first circumstance, the methodology may proceed as follows:

• Make sure the LSP to be deleted is set up;
• At the ingress node, form the Path message including an Admin Status Object with the Reflect (R) and Delete (D) bits set. A timestamp (T1) may be stored locally on the ingress node when the Path message packet is sent towards the egress node.
• Upon receiving the Path message including an Admin Status Object with the Reflect (R) and Delete (D) bits set, the egress node sends a Resv message including an Admin Status Object with the Delete (D) and Reflect (R) bits set. Alternatively, the egress node sends a PathErr message with the Path_State_Removed flag set upstream.
• When the ingress node receives the Resv message or the PathErr message, it sends a PathTear message to remove the LSP.
• The egress node takes a timestamp (T2) once it receives the last bit of the PathTear message. The LSP graceful release delay is then (T2-T1).
• If the ingress node sends the Path message downstream, but the egress node fails to receive the PathTear message within a reasonable period of time, the LSP graceful release delay is deemed to be undefined. Note that the "reasonable" threshold is a parameter of the methodology.

In the second circumstance, the methodology would proceed as follows:

• Make sure the LSP to be deleted is set up;
• On the egress node, form the Resv message including an Admin Status Object with the Reflect (R) and Delete (D) bits set. A timestamp may be stored locally on the egress node when the Resv message packet is sent towards the ingress node.
• Upon receiving the Admin Status Object with the Reflect (R) and Delete (D) bits set in the Resv message, the ingress node sends a PathTear message downstream to remove the LSP.
• The egress node takes a timestamp (T2) once it receives the last bit of the PathTear message. The LSP graceful release delay is then (T2-T1).
• If the egress node sends the Resv message upstream, but it fails to receive the PathTear message within a reasonable period of time, the LSP graceful release delay is deemed to be undefined. Note that the "reasonable" threshold is a parameter of the methodology.

8.8. Metric Reporting 📋

The metric result (either a real number or undefined) MUST be reported together with the selected upper bound and the procedure used (e.g., either from the ingress node to the egress node or from the egress node to the ingress node; see Section 8.5 for more details). The route that the LSP traverses MUST also be reported. The route MAY be collected via use of the record route object, see [RFC3209], or via the management plane. The collection of routes via the management plane is out of scope of this document. 💅

9. A Definition for Samples of Single Unidirectional LSP Setup Delay 🎀

In Section 4, we defined the singleton metric of single unidirectional LSP setup delay. Now we define how to get one particular sample of single unidirectional LSP setup delay. Sampling means to take a number of distinct instances of a skeleton metric under a given set of parameters. As in [RFC2330], we use Poisson sampling as an example. ✨

9.1. Metric Name 🏷️

Single unidirectional LSP setup delay sample

9.2. Metric Parameters 📝

• ID0, the ingress LSR ID
• ID1, the egress LSR ID
• T0, a time
• Tf, a time
• Lambda, a rate in the reciprocal milliseconds
• Th, LSP holding time
• Td, the maximum waiting time for successful setup

9.3. Metric Units 📏

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

• T, a time when setup is attempted
• dT, either a real number of milliseconds or undefined

9.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 unidirectional LSP setup delay sample. The value of the sample is the sequence made up of the resulting <time, LSP setup delay> pairs. If there are no such pairs, the sequence is of length zero and the sample is said to be empty. 🌸

9.5. Discussion

okay so the parameter Lambda needs to be picked super carefully 🫶 if the rate is too high, too frequent LSP setup/release procedure will result in high overhead in the control plane 💀 and that overhead then pushes up the unidirectional LSP setup delay. but if the rate is too low, the sample might not fully capture the dynamic provisioning performance of the GMPLS network 🙈 the right Lambda value depends on the network you're working with ✨

the parameters Td also need careful picking 🎀 different switching technologies can vary a lot when they do a cross-connect operation, and the time it takes to set up an LSP under different traffic can vary a lot too 🌸

for active measurement, the parameters Th need care too 💅 the combo of Lambda and Th reflects the load of the network. when you pick Th, you should think about whether the network still has enough resources to run the subsequent tests 🦋 the value of Th MAY be constant during one sampling process, just to keep things simple 🧚

fr, for online or passive measurements, the arrival rate and LSP holding time come from actual traffic 😭 so in that case, Lambda and Th aren't input parameters at all 💜

and this one is a must-do 🔥 when you're getting a sample, all the LSPs MUST traverse the same route. if there are multiple routes between the ingress node ID0 and egress node ID1, EROs, or an alternate method (like static configuration, for example), MUST be used to make sure every LSP takes the same route 👑

---

9.6. Methodologies

• Select the times using the specified Poisson arrival process,
• Set up the LSP as the methodology for the singleton unidirectional LSP setup delay, and obtain the value of unidirectional LSP setup delay, and
• Release the LSP after Th, and wait for the next Poisson arrival event.

note: it's possible that the next Poisson arrival event shows up before the previous LSP release procedure finishes, and then the LSP setup procedure gets kicked off early 😳 if the two LSPs end up competing for resources, the LSP setup may fail. ways to avoid that kind of contention are outside the scope of this document 🙈

---

9.7. Typical Testing Cases

9.7.1. With No LSP in the Network

9.7.1.1. Motivation

single unidirectional LSP setup delay with no LSP in the network is important because it shows the inherent delay of an RSVP-TE implementation 🧚 the minimum value gives you an idea of the delay you'll likely see when an LSP takes the shortest route with the lightest load in the control plane 🍓

9.7.1.2. Methodologies

make sure there's no LSP in the network, then go through the methodologies in Section 9.6 💖

9.7.2. With a Number of LSPs in the Network

9.7.2.1. Motivation

single unidirectional LSP setup delay with a number of LSPs in the network matters because it shows how an operational network with a lot of load performs 🔥 this delay can change a lot as the number of existing LSPs changes, and it can be used as a scalability metric for an RSVP-TE implementation 📈✨

9.7.2.2. Methodologies

set up the required number of LSPs and wait until the network reaches a stable state 🌈 then go through the methodologies in Section 9.6 🦋

---

9.8. Metric Reporting

the metric results, including both real and undefined values, MUST be reported together with the total number of values 📊 the context the sample was obtained in also MUST be reported, which means the selected parameters, the route the LSPs took, and the testing case used 🫶

---

10. A Definition for Samples of Multiple Unidirectional LSPs Setup Delay

in Section 5 we defined the singleton metric of multiple unidirectional LSPs setup delay 🎀 now we get to define how to grab one particular sample of it 💅

sampling means taking a number of distinct instances of a skeleton metric under a given set of parameters ✨ like in [RFC2330], we use Poisson sampling as an example 🦋

10.1. Metric Name

Multiple unidirectional LSPs setup delay sample

10.2. Metric Parameters

• ID0, the ingress LSR ID
• ID1, the egress LSR ID
• T0, a time
• Tf, a time
• Lambda_m, a rate in the reciprocal milliseconds
• Lambda, a rate in the reciprocal milliseconds
• X, the number of LSPs to set up
• Th, LSP holding time
• Td, the maximum waiting time for successful multiple unidirectional LSPs setup

10.3. Metric Units

a sequence of pairs, where the elements of each pair are:

• T, a time when the first setup is attempted
• dT, either a real number of milliseconds or undefined

10.4. Definition

given T0, Tf, and Lambda, compute a pseudo-random Poisson process that begins at or before T0 with an average arrival rate of Lambda and ends at or after Tf 🌸 then select the time values that are greater than or equal to T0 and less than or equal to Tf. at each of those times in the process, we get the value of the multiple unidirectional LSP setup delay sample ✨ the value of the sample is the sequence made up of the resulting <time, setup delay> pairs. if there are no such pairs, the sequence has length zero and the sample is said to be empty 🫥

10.5. Discussion

the parameter Lambda is used as the arrival rate of the "batch unidirectional LSPs setup" operation 🧁 it sets the interval between each batch operation. the parameter Lambda_m is used inside each batch operation, as described in Section 5

the parameters Lambda and Lambda_m need careful picking 💅 if the rate is too high, overly frequent LSP setup/release procedure will mean high control-plane overhead, and that overhead then increases the unidirectional LSP setup delay 💀 if the rate is too low, the sample might not completely reflect the dynamic provisioning performance of the GMPLS network 🙈 the right Lambda and Lambda_m values depend on the network

the parameters Td should be carefully chosen too 🎀 different switching technologies can vary significantly when performing a cross-connect operation, and the time needed to set up an LSP under different traffic can also vary significantly 🌈

when you're obtaining a sample, all the LSPs MUST traverse the same route 👑 if there are multiple routes between the ingress node ID0 and egress node ID1, EROs, or an alternate method (e.g., static configuration) MUST be used to ensure all the LSPs traverse the same route 🫶

10.6. Methodologies

• Select the times using the specified Poisson arrival process,
• Set up the LSP as the methodology for the singleton multiple unidirectional LSPs setup delay, and obtain the value of multiple unidirectional LSPs setup delay, and
• Release the LSP after Th, and wait for the next Poisson arrival event.

note: it's possible that the next Poisson arrival event arrives before the previous LSP release procedure completes, and then the LSP setup procedure starts 😳 if the two LSPs compete for resources, the LSP setup may fail. ways to avoid that contention are outside the scope of this document 🙈

10.7. Typical Testing Cases

10.7.1. With No LSP in the Network

10.7.1.1. Motivation

multiple unidirectional LSPs setup delay with no LSP in the network is important because it reflects the inherent delay of an RSVP-TE implementation 🧚 the minimum value shows the delay you'll likely experience when LSPs take the shortest route with the lightest control-plane load 🍓

10.7.1.2. Methodologies

make sure there's no LSP in the network, then go through the methodologies in Section 10.6 💖

10.7.2. With a Number of LSPs in the Network

10.7.2.1. Motivation

multiple unidirectional LSPs setup delay with a number of LSPs in the network matters because it shows how an operational network with considerable load performs 🔥 this delay can vary significantly as the number of existing LSPs varies, so it can be used as a scalability metric for an RSVP-TE implementation 📈

10.7.2.2. Methodologies

set up the required number of LSPs and wait until the network reaches a stable state 🌸 then go through the methodologies in Section 10.6 🦋

10.8. Metric Reporting

the metric results, including both real and undefined values, MUST be reported together with the total number of values 📊 the context the sample was obtained in also MUST be reported, including the selected parameters, the route the LSPs traversed, and the testing case used 🫶

---

11. A Definition for Samples of Single Bidirectional LSP Setup Delay

in Section 6 we defined the singleton metric of single bidirectional LSP setup delay 🎀 now we define how to get one particular sample of it 💅 sampling means taking a number of distinct instances of a skeleton metric under a given set of parameters ✨ like in [RFC2330], we use Poisson sampling as an example 🦋

11.1. Metric Name

Single bidirectional LSP setup delay sample with no LSP in the network

11.2. Metric Parameters

• ID0, the ingress LSR ID
• ID1, the egress LSR ID
• T0, a time
• Tf, a time
• Lambda, a rate in the reciprocal milliseconds
• Th, LSP holding time
• Td, the maximum waiting time for successful setup

11.3. Metric Units

a sequence of pairs, where the elements of each pair are:

• T, a time when setup is attempted
• dT, either a real number of milliseconds or undefined

11.4. Definition

given T0, Tf, and Lambda, compute a pseudo-random Poisson process that begins at or before T0 with an average arrival rate of Lambda and ends at or after Tf 🌈 then select the time values that are greater than or equal to T0 and less than or equal to Tf. at each of those times in the process, we get the value of the bidirectional LSP setup delay sample 💖 the value of the sample is the sequence made up of the resulting <time, LSP setup delay> pairs. if there are no such pairs, the sequence has length zero and the sample is said to be empty 🫥

11.5. Discussion 💅

okay so Lambda has to be picked carefully, bestie 🎀 if the rate is too high, the LSP setup/release procedure happens way too often, and the control plane overhead goes brrr 📈. That overhead then makes the bidirectional LSP setup delay go up too 😭 but if the rate is too low, the sample might not fully show how the GMPLS network handles dynamic provisioning ✨ the right Lambda depends on the network you're working with.

Td needs care too 🦋 different switching technologies can be wildly different when they do a cross-connect operation, and the time to set up an LSP can swing a lot depending on the traffic.

for active measurement, Th also needs to be chosen carefully 🌸 Lambda and Th together show how loaded the network is. The selection of Th SHOULD take into account that the network has sufficient resources to perform subsequent tests. The value of Th MAY be constant during one sampling process, just to keep things simple 🧚

for online or passive measurements, though, the arrival rate and the LSP holding time come from real traffic, so Lambda and Th are not input parameters in that case 💜

it is so important that all the LSPs MUST traverse the same route when you're getting a sample 🔥 if there are multiple routes between the ingress node ID0 and egress node ID1, EROs, or an alternate method (like static configuration, e.g.) MUST be used to make sure every LSP takes the same route 🫶

11.6. Methodologies 🍓

• Select the times using the specified Poisson arrival process,
• Set up the LSP as the methodology for the singleton bidirectional LSP setup delay, and obtain the value of bidirectional LSP setup delay, and
• Release the LSP after Th, and wait for the next Poisson arrival event.

Note: it is possible that before the previous LSP release procedure completes, the next Poisson arrival event arrives and the LSP setup procedure is initiated. If there is resource contention between the two LSPs, the LSP setup may fail. Ways to avoid such contention are outside the scope of this document. 🙈

11.7. Typical Testing Cases ✨

11.7.1. With No LSP in the Network 🌈

11.7.1.1. Motivation

Single bidirectional LSP setup delay with no LSP in the network is important because it shows the inherent delay of an RSVP-TE implementation 💖 the minimum value gives you a hint of the delay you'll likely see when an LSP goes over the shortest route with the lightest load in the control plane.

11.7.1.2. Methodologies

Make sure there is no LSP in the network, then go through the methodologies in Section 11.6 🧚

11.7.2. With a Number of LSPs in the Network 🔥

11.7.2.1. Motivation

Single bidirectional LSP setup delay with a number of LSPs in the network is important because it shows how an operational network performs under a lot of load 💅 this delay can change a lot as the number of existing LSPs changes, and it can be used as a scalability metric for an RSVP-TE implementation 👑

11.7.2.2. Methodologies

Set up the required number of LSPs and wait until the network reaches a stable state, then go through the methodologies in Section 11.6 🫶

11.8. Metric Reporting 📝

The metric results, including both real and undefined values, MUST be reported together with the total number of values. The context in which the sample was obtained MUST also be reported, including the selected parameters, the route traversed by the LSPs, and the testing case used 🎀

---

12. A Definition for Samples of Multiple Bidirectional LSPs Setup Delay 🦋

In Section 7, we defined the singleton metric of multiple bidirectional LSPs setup delay. Now we're going to define how to get one particular sample of multiple bidirectional LSP setup delay 💜

Sampling means taking a bunch of distinct instances of a skeleton metric under a given set of parameters. Just like in [RFC2330], we use Poisson sampling as an example 🌸

12.1. Metric Name

Multiple bidirectional LSPs setup delay sample

12.2. Metric Parameters

• ID0, the ingress LSR ID
• ID1, the egress LSR ID
• T0, a time
• Tf, a time
• Lambda_m, a rate in the reciprocal milliseconds
• Lambda, a rate in the reciprocal milliseconds
• X, the number of LSPs to set up
• Th, LSP holding time
• Td, the maximum waiting time for successful multiple unidirectional LSPs setup

12.3. Metric Units

A sequence of pairs. The elements of each pair are:

• T, a time when the first setup is attempted
• dT, either a real number of milliseconds or undefined

12.4. Definition ✨

Given T0, Tf, and Lambda, compute a pseudo-random Poisson process beginning at or before T0, with an average arrival rate of Lambda and ending at or after Tf. Those time values that are 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 the multiple unidirectional LSP setup delay sample. The value of the sample is the sequence made up of the resulting <time, setup delay> pairs. If there are no such pairs, the sequence is of length zero and the sample is said to be empty 🧁

12.5. Discussion 💅

The parameter Lambda is used as an arrival rate of the "batch bidirectional LSPs setup" operation 🌈 it regulates the interval between each batch operation. The parameter Lambda_m is used within each batch operation, as described in Section 7.

The parameters Lambda and Lambda_m should be carefully chosen. If the rate is too high, overly frequent LSP setup/release procedures will result in high overhead in the control plane, and that overhead will increase the unidirectional LSP setup delay 😭 on the other hand, if the rate is too low, the sample might not completely reflect the dynamic provisioning performance of the GMPLS network. The appropriate Lambda and Lambda_m values depend on the given network.

The parameters Td should be carefully chosen too. Different switching technologies may vary significantly in performing a cross-connect operation, and the time needed to set up an LSP under different traffic may also vary significantly 🦋

It is important that, in obtaining a sample, all the LSPs MUST traverse the same route. If there are multiple routes between the ingress node ID0 and egress node ID1, EROs, or an alternate method (e.g., static configuration) MUST be used to ensure that all LSPs traverse the same route 🫶

12.6. Methodologies 🍓

• Select the times using the specified Poisson arrival process,
• Set up the LSP as the methodology for the singleton multiple bidirectional LSPs setup delay, and obtain the value of multiple unidirectional LSPs setup delay, and
• Release the LSP after Th, and wait for the next Poisson arrival event.

Note: it is possible that before the previous LSP release procedure completes, the next Poisson arrival event arrives and the LSP setup procedure is initiated. If there is resource contention between the two LSPs, the LSP setup may fail. Ways to avoid such contention are outside the scope of this document. 🙈

12.7. Typical Testing Cases ✨

12.7.1. With No LSP in the Network 🌸

12.7.1.1. Motivation

Multiple bidirectional LSPs setup delay with no LSP in the network is important because it reflects the inherent delay of an RSVP-TE implementation 💖 the minimum value gives an indication of the delay that will likely be experienced when an LSPs traverse the shortest route with the lightest load in the control plane.

12.7.1.2. Methodologies

Make sure there is no LSP in the network, then proceed with the methodologies described in Section 10.6 🧚

12.7.2. With a Number of LSPs in the Network 🔥

12.7.2.1. Motivation

Multiple bidirectional LSPs setup 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, and it may be used as a scalability metric of an RSVP-TE implementation.

12.7.2.2. Methodologies

Set up the required number of LSPs and wait until the network reaches a stable state, then proceed with the methodologies described in Section 12.6 💅

12.8. Metric Reporting 📝

The metric results, including both real and undefined values, MUST be reported together with the total number of values. The context in which the sample was obtained MUST also be reported, including the selected parameters, the route traversed by the LSPs, and the testing case used 🎀

---

13. A Definition for Samples of LSP Graceful Release Delay 🦋

In Section 8, we defined the singleton metric of LSP graceful release delay. Now we define how to get one particular sample of LSP graceful release delay 💜 we also use Poisson sampling as an example ✨

13.1. Metric Name

LSP graceful release delay sample

13.2. Metric Parameters

• ID0, the ingress LSR ID
• ID1, the egress LSR ID
• T0, a time
• Tf, a time
• Lambda, a rate in reciprocal milliseconds
• Td, the maximum waiting time for successful LSP release

13.3. Metric Units

A sequence of pairs. The elements of each pair are:

• T, a time, and
• dT, either a real number of milliseconds or undefined

13.4. Definition 🧁

Given T0, Tf, and Lambda, we compute a pseudo-random Poisson process beginning at or before T0, with an average arrival rate of Lambda and ending at or after Tf. Those time values that are 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 the LSP graceful release delay sample. The value of the sample is the sequence made up of the resulting <time, LSP graceful delay> pairs. If there are no such pairs, the sequence is of length zero and the sample is said to be empty 🌈

13.5. Discussion 💅

The parameter Lambda should be carefully chosen. If the rate is too large, overly frequent LSP setup/release procedures will result in high overhead in the control plane 😭 that overhead will increase the unidirectional LSP setup delay. On the other hand, if the rate is too small, the sample might not completely reflect the dynamic provisioning performance of the GMPLS network. The appropriate Lambda value depends on the given network 🦋

It is important that, in obtaining a sample, all the LSPs MUST traverse the same route. If there are multiple routes between the ingress node ID0 and egress node ID1, EROs, or an alternate method (e.g., static configuration) MUST be used to ensure that all LSPs traverse the same route 🫶

13.6. Methodologies 🍓

Generally, the methodology would proceed as follows:

• Set up the LSP to be deleted
• Select the times using the specified Poisson arrival process,
• Release the LSP as the methodology for the singleton LSP graceful release delay, and obtain the value of LSP graceful release delay, and
• Set up the LSP, and restart the Poisson arrival process, wait for the next Poisson arrival event.

13.7. Metric Reporting 📝

The metric results, including both real and undefined values, MUST be reported together with the total number of values. The context in which the sample was obtained, including the selected parameters and the route traversed by the LSPs, MUST also be reported 🎀

14. Some Statistics Definitions for Metrics to Report ✨

okay so now we get to the fun part, bestie 💅 we've got the samples, and now we're going to cook up some stats from them so we can actually learn stuff about a GMPLS network 🧚 the metric values are either a real number of milliseconds or undefined (which is basically "it didn't work" energy 💀), and we're only going to care about the finite values in the discussion below 🫶

14.1. The Minimum of Metric

so the minimum is just the smallest dT value in the sample, lowkey simple 🌸 when you compute it, undefined values SHOULD be treated as infinitely large 🔥 which means the minimum could end up being undefined if every single dT value is undefined 😭 and if the sample is empty, the metric minimum SHOULD be set to undefined 🙈

14.2. The Median of Metric

the median is the median of the dT values in the sample, nothing fancy 🍓 but when you compute it, the undefined values MUST NOT be included 💅

14.3. The Maximum of Metric

the maximum is the biggest dT value in the sample ✨ when you compute it, undefined values MUST NOT be included 🎀 this means measurements that go over the upper bound are NOT reported in this stat 👀 which is a big deal when there are a bunch of undefined measurements, so be careful when you're evaluating the max 🚨

bestie, read that last part twice. the max can look way calmer than reality if you've got lots of failures, iykyk 💀

14.4. The Percentile of Metric

okay this one is a little more math-y but we got this 🦋 the "empirical distribution function" (EDF) of a set of scalar measurements is a function F(x), and for any x it gives you the fractional proportion of the total measurements that were less than or equal to x 🌈

so given a percentage X, the X-th percentile of the metric is the smallest value of x where F(x) >= X 💜 and when you compute the percentile, undefined values MUST NOT be included 🫶

for more details, check out [RFC2330] 📚

14.5. Failure Statistics of Metric

okay so LSP setup and release can fail for all kinds of reasons 😭 like when the control plane is overburdened, or when one of the intermediate nodes is short on resources 🫠 setup or release failures can seriously mess with network operation, so it's worth reporting every single failure case 🔥 that way people can go check for possible implementation, configuration, or other deficiencies 🕵️‍♀️

five types of failure events were defined in the earlier sections, and they are:

• Single Unidirectional LSP Setup Failure
• Multiple Unidirectional LSP Setup Failure
• Single Bidirectional LSP Setup Failure
• Multiple Bidirectional LSP Setup Failure
• LSP Graceful Release Failure

given the samples of the performance metric, we're gonna offer two stats about these failure events 🎀

14.5.1. Failure Count

Failure Count is the number of undefined values of the corresponding performance metric (aka failure events) in a sample 💀 and the value is an integer 🔢

14.5.2. Failure Ratio

Failure Ratio is the percentage of failure events out of the total number of requests in a sample 💅 here's how it's calculated:

X type failure ratio = Number of X type failure events/(Number of
valid X type metric values + Number of X type failure events) * 100%.

15. Discussion 🧠

okay bestie, here's the tea 🍵 a few things worth pointing out:

• the unidirectional/bidirectional LSP setup delay is one ingress-egress round-trip time plus processing time 🦋 but in this document, that delay has NOT taken the processing time in the end nodes (ingress and/or egress) into account 🙈 the timestamp T2 is taken after the endpoint node receives it, and honestly the last node still has to take some time to process local procedures 😭 same deal for the LSP graceful release delay, since the memo didn't consider processing time in the end node either 💅
• this document assumes the correct procedures for installing the data plane are followed, as described in [RFC3209], [RFC3471], and [RFC3473] ✨ that means by the time the egress receives and processes a Path message, it's safe for the egress to transmit data on the reverse path 🌸 and by the time the ingress receives and processes a Resv message, it's safe for the ingress to transmit data on the forward path 🫶 see [CCAMP-SWITCH] for the detailed explanations 📚 this document does NOT verify that the control plane software implementations are conformant, although such tests MAY be built using suitable signal generation test equipment 🔧 in [CCAMP-DPM], we defined a series of metrics to do exactly that kind of verification 💜 still, it is RECOMMENDED that both the measurements in this document and the measurements in [CCAMP-DPM] are performed, so they complement each other 👑
• be sure to measure the time taken for control plane messages, including the processing of those messages by the nodes under test 🎀 when you're implementing the tests in this document, don't skip that part 🙈
• bidirectional LSPs may be set up using three-way signaling, where the initiating node sends a ResvConf message downstream upon receiving the Resv message 🦋 the ResvConf message is used to notify the terminate node that it can transfer data upstream 🌈 honestly both directions should be ready to transfer data when the initiating node receives the Resv message 💅 so the bidirectional LSP setup delay defined here does NOT take the confirmation procedure into account 🫠

16. Security Considerations 🔐

okay this section is SERIOUS bestie, so let's get into it 😭🔥

samples of the metrics can be obtained in either active or passive manners 👀

in active measurement, ingress nodes inject probing messages into the control plane 💉 since the measurement endpoints MUST be conformant to signaling specifications and behave as normal signaling endpoints, it won't cause other security issues beyond 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 💀

when samples of the metrics are collected in a passive manner, for example by monitoring the operations on real-life LSPs, the implementation of the monitoring and reporting mechanism MUST be careful so that it can't be used to attack the control plane 🛡️ a typical implementation may use the Management Information Base (MIB) to collect and store the metrics, and access to the MIB is limited to the Network Management Systems (NMSs) 🔒 in this case, passive monitoring won't cause other security issues beyond implementing the MIBs and NMSs ✨ if an implementation chooses to expose the performance data to other applications, then it MUST take into account the possible security issues it may face 👀 for example, when exposing the performance data through Simple Network Management Protocol (SNMP), certain authentication methods SHOULD be used to make sure the entity maintaining the performance data isn't subject to unauthorized readings and modifications 🔐 rate limiting on the performance query may also be desirable, to reduce the risk that the entity maintaining the performance data gets overwhelmed by too many query requests 🫠 it is RECOMMENDED that implementers consider the security features provided by the SNMPv3 framework (see [RFC3410], section 8), including full support for the SNMPv3 cryptographic mechanisms (for authentication and privacy) 💜

and finally, the security considerations pertaining to the original RSVP protocol [RFC2205] and its TE extensions [RFC3209] also remain relevant 🌸

17. Acknowledgments 🎀

we wanna thank Dan Li, Fang Liu (Christine), Zafar Ali, Monique Morrow, Adrian Farrel, Deborah Brungard, Lou Berger, and Thomas D. Nadeau for their comments and help 🫶 Lou Berger and Adrian Farrel made text contributions to this document 🙌

we also wanna thank experts from IPPM and BMWG (Reinhard Schrage, Al Morton, and Henk Uijterwaal) for reviewing this document 👑 Reinhard Schrage made text contributions too 💅

this document has ideas and text that appeared in existing IETF documents, and the authors wanna thank G. Almes, S. Kalidindi, and M. Zekauskas 🦋

we also wanna thank Weisheng Hu, Yaohui Jin, and Wei Guo in the state key laboratory of advanced optical communication systems and networks for the valuable comments 🌈 and we appreciate the support from the National Natural Science Foundation of China (NSFC) and the 863 program of China 🇨🇳✨

18. References 📚

18.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.

[RFC3471]       Berger, L., "Generalized Multi-Protocol Label
                Switching (GMPLS) Signaling Functional Description",
                RFC 3471, January 2003.

[RFC3473]       Berger, L., "Generalized Multi-Protocol Label
                Switching (GMPLS) Signaling Resource ReserVation
                Protocol-Traffic Engineering (RSVP-TE) Extensions",
                RFC 3473, January 2003.

[RFC3945]       Mannie, E., "Generalized Multi-Protocol Label
                Switching (GMPLS) Architecture", RFC 3945,
                October 2004.

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

18.2. Informative References

[CCAMP-DPM]     Sun, W., Zhang, G., Gao, J., Xie, G., Papneja, R.,
                Gu, B., Wei, X., Otani, T., and R. Jing, "Label
                Switched Path (LSP) Data Path Delay Metric in
                Generalized MPLS/ MPLS-TE Networks", Work
                in Progress, December 2009.

[CCAMP-SWITCH]  Shiomoto, K. and A. Farrel, "Advice on When It is
                Safe to Start Sending Data on Label Switched Paths
                Established Using RSVP-TE", Work in Progress,
                October 2009.

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

[RFC3410]       Case, J., Mundy, R., Partain, D., and B. Stewart,
                "Introduction and Applicability Statements for
                Internet-Standard Management Framework", RFC 3410,
                December 2002.

Appendix A. Authors' Addresses ✨

okay bestie, here are the humans who wrote this thing 🫶 time to meet the squad, with their phone numbers and emails so you can slide into their DMs (professionally, obvi 💅)

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
Isocore
12359 Sunrise Valley Drive, STE 100
Reston, VA  20190
USA

Phone: +1 703 860 9273
EMail: rpapneja@isocore.com

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: otani@kddilabs.jp

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

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

---

Editors' Addresses 🌸

the editors who kept the whole group project on track 👑 (they really did the most 😭)

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

Phone: +86 21 3420 5359
EMail: sunwq@mit.edu

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

Phone: +86 1062300103
EMail: zhangguoying@mail.ritt.com.cn

and that's the whole RFC, bestie 🦋✨