RFC 8625

Ethernet Traffic Parameters with Availability Information

📅 published August 2019, from ietf

RFC 8625: Ethernet Traffic Parameters with Availability Information 💖

Okay bestie, let's talk about RFC 8625 🦋 It's an IETF doc from August 2019, published on the Standards Track (so it's an official Internet standard, no cap 👑). The authors are H. Long, M. Ye (editor), G. Mirsky (editor), A. D'Alessandro, and H. Shah. Long and Ye are from Huawei Technologies Co., Ltd., Mirsky is from ZTE, D'Alessandro is from Telecom Italia S.p.A, and Shah is from Ciena. It's numbered in the ISSN series as 2070-1721 ✨ The header doesn't list anything it obsoletes or updates, so there's no older RFC to track here 🙈

Abstract 💖

Okay so, a packet-switching network can have links whose bandwidth changes, like copper or radio links 📡 That bandwidth is sensitive to the environment, so weather and climate can totally affect it ☔ When people plan networks, they usually describe these links using availability ✨ This document adds an optional Bandwidth Availability TLV to RSVP-TE signaling. It's used together with the Ethernet SENDER_TSPEC object to set up a GMPLS Label Switched Path (LSP) 🎀

Status of This Memo 📝

This is an Internet Standards Track document ✨

It's a product of the Internet Engineering Task Force (IETF), so it represents the consensus of the IETF community 🫶 It got public review and was approved for publication by the Internet Engineering Steering Group (IESG). If you want more on Internet Standards, check out Section 2 of RFC 7841 💅

For info on the current status, any errata, and how to give feedback, go to https://www.rfc-editor.org/info/rfc8625.

Copyright (c) 2019 IETF Trust and the persons identified as the document authors. All rights reserved ✨

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) as they stand on the publication date. Please read these carefully, because they spell out your rights and restrictions for this document 📜 Any Code Components pulled out of this document must include Simplified BSD License text, as described in Section 4.e of the Trust Legal Provisions, and they come without warranty, as the Simplified BSD License describes 🔥

Table of Contents 🧚

1. Introduction ....................................................3
   1.1. Conventions Used in This Document ..........................4
2. Overview ........................................................4
3. Extension to RSVP-TE Signaling ..................................5
   3.1. Bandwidth Availability TLV .................................5
   3.2. Signaling Process ..........................................6
4. Security Considerations .........................................7
5. IANA Considerations .............................................8
6. References ......................................................8
   6.1. Normative References .......................................8
   6.2. Informative References .....................................9
Appendix A.  Bandwidth Availability Example .......................11
Acknowledgments ...................................................13
Authors' Addresses ................................................13

1. Introduction 🦋

The RSVP-TE specification [RFC3209] and the GMPLS extensions [RFC3473] define the signaling messages, including the bandwidth request for setting up an LSP in a packet-switching network 💌

Some data communication technologies can smoothly change their maximum physical bandwidth across a set of known discrete values 🌸 The parameter availability [G.827] [F.1703] [P.530] is often used to describe the link capacity during network planning. Availability is based on a time scale, and it's the proportion of operating time during which the requested bandwidth is guaranteed ⏰ Appendix A has a more detailed example of bandwidth availability. Assigning different bandwidth availability classes to different types of services over links with variable discrete bandwidth makes link capacity planning way more efficient 📈 To set up an LSP across these links, the nodes need bandwidth availability information to check bandwidth satisfaction and make a bandwidth reservation ✨ That availability information should be inherited from the bandwidth availability requirements of the services expected to ride on the LSP. For example, voice service usually needs 99.999% bandwidth availability 📞 Non-real-time services may be fine with 99.99% or 99.9% 🙈 Since different service types can need different availability guarantees, you may need multiple <availability, bandwidth> pairs when signaling 💅

If the bandwidth availability requirement isn't in the signaling message, the bandwidth will likely be reserved at the highest bandwidth availability 😭 Say a link's bandwidth at 99.999% availability is 100 Mbps, and its bandwidth at 99.99% availability is 200 Mbps. If a video application asks for 120 Mbps without an availability requirement, the system treats the request as 120 Mbps at 99.999% availability. But the available bandwidth at 99.999% is only 100 Mbps, so the LSP path can't be set up ❌ The video app doesn't actually need 99.999%, though, because 99.99% is enough 🎬 In that case, the LSP could be set up if the bandwidth availability is also specified in the signaling message 💖

To make LSP setup work through signaling in these scenarios, this document specifies a Bandwidth Availability TLV 🎀 It can apply to any kind of physical link with variable discrete bandwidth, like microwave or DSL 📡 Multiple Bandwidth Availability TLVs, together with multiple Ethernet Bandwidth Profile TLVs, can be carried by the Ethernet SENDER_TSPEC object [RFC6003]. The Ethernet FLOWSPEC object has the same format as the Ethernet SENDER_TSPEC object [RFC6003], so the Bandwidth Availability TLV can also be carried by the Ethernet FLOWSPEC object 🧚

1.1. Conventions Used in This Document 📖

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here 🫶

These acronyms show up in this document:

RSVP-TE  Resource Reservation Protocol - Traffic Engineering

LSP      Label Switched Path

SNR      Signal-to-Noise Ratio

TLV      Type-Length-Value

LSA      Link State Advertisement

QAM      Quadrature Amplitude Modulation

QPSK     Quadrature Phase Shift Keying

2. Overview 🌟

A tunnel in a packet-switching network may span one or more links in a network 🕸️ To set up an LSP, a node may collect link information advertised in a routing message (for example, an OSPF TE LSA message) from network nodes, so it can get the network topology 🗺️ Then it can calculate an LSP route based on that topology. The calculated LSP route is signaled using a PATH/RESV message to set up the LSP 💫

If a network has one or more links with variable discrete bandwidths, a <bandwidth, availability> requirement list should be specified for an LSP at setup 💜 Each <bandwidth, availability> pair in the list means that the listed bandwidth at the specified availability is required. The list can come from the results of service planning for the LSP 📋

A node with link(s) that have variable discrete bandwidth attached should include a <bandwidth, availability> information list in its OSPF TE LSA messages 🌈 The list maps each link's nominal bandwidth to its availability level. Nodes can then use this info for path calculation 🧮 The routing extension for availability is in [RFC8330].

When a node starts PATH/RESV signaling to set up an LSP, the PATH message should carry the <bandwidth, availability> requirement list as a bandwidth request 🚀 Intermediate nodes will allocate bandwidth resources for each availability requirement from the remaining bandwidth at the matching availability. If any <bandwidth, availability> request can't be satisfied, an error message may be returned 🚨

3. Extension to RSVP-TE Signaling 🎀

3.1. Bandwidth Availability TLV 💎

In this document, a Bandwidth Availability TLV is defined as a TLV of the Ethernet SENDER_TSPEC object [RFC6003]. The Ethernet SENDER_TSPEC object MAY include more than one Bandwidth Availability TLV 🙌 The Bandwidth Availability TLV has the following format:

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |               Type            |              Length           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    Index      |                 Reserved                      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                         Availability                          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                Figure 1: Bandwidth Availability TLV

Now let's go field by field, because each one matters 🔍

Type (2 octets): 4

Length (2 octets): 0x0C. This is the length in bytes of the whole TLV, including the Type and Length fields. Here, the length is 12 bytes 📏

Index (1 octet): When a Bandwidth Availability TLV is included, the Ethernet Bandwidth Profile TLV MUST also be included 🫵 If there are multiple bandwidth requirements (in multiple Ethernet Bandwidth Profile TLVs) and they have different availability requirements, multiple Bandwidth Availability TLVs MUST be carried 🌷 In that case, each Bandwidth Availability TLV has a one-to-one match with its Ethernet Bandwidth Profile TLV, since they share the same value in the Index field 💕 If all the bandwidth requirements in the Ethernet Bandwidth Profile TLV have the same availability requirement, one Bandwidth Availability TLV SHOULD be carried. In this case, the Index field is set to 0 🍓

Reserved (3 octets): These bits SHOULD be set to zero when sent and MUST be ignored when received 🙈

Availability (4 octets): This is a 32-bit floating-point number in binary interchange format [IEEE754], and it describes the decimal value of the availability requirement for this bandwidth request 🔢 The value MUST be less than 1 and is usually one of these: 0.99, 0.999, 0.9999, or 0.99999. The IEEE floating-point number is used here to line up with [RFC8330] 🤝 Once you go above 0.999999, the floating-point number starts introducing errors into the intended precision 😬 But in reality, 0.99999 is normally treated as the highest availability value in a telecom network, which works out to 5 minutes of outage in a year ⏳ So, using a floating-point number for availability is acceptable 💅

More of the RFC is coming in the next part, so stay tuned! 🦋✨

3.2. Signaling Process ✨

Okay so the source node kicks things off by sending a PATH message 💌. This one can carry a bunch of bandwidth requests, including one or more Ethernet Bandwidth Profile TLVs and one or more Bandwidth Availability TLVs. Each Ethernet Bandwidth Profile TLV lines up with an availability parameter in its matching Bandwidth Availability TLV 🎀.

When the intermediate and destination nodes receive the PATH message, they compare the requested bandwidth under each availability level in the SENDER_TSPEC objects with the leftover link bandwidth under the matching availability level on a local link. They're basically checking whether they can meet the bandwidth requirements 🔍.

  • When all <bandwidth, availability> requirement requests can be satisfied (that is, the requested bandwidth under each availability parameter is smaller than or equal to the remaining bandwidth under the corresponding availability parameter on its local link), the node SHOULD reserve the bandwidth resources from each remaining sub-bandwidth portion on its local link to set up this LSP. Optionally, a higher availability bandwidth can be allocated to a lower availability request when the lower availability bandwidth cannot satisfy the request. ✨
  • When at least one <bandwidth, availability> requirement request cannot be satisfied, the node SHOULD generate a PathErr message with the error code "Admission Control Error" and the error value "Requested Bandwidth Unavailable" (see [RFC2205]). 💀

When two LSPs request bandwidth with the same availability requirement, the contention MUST be resolved by comparing the node IDs, where the LSP with the higher node ID is assigned the reservation. This is consistent with the general contention resolution mechanism provided in Section 4.2 of [RFC3471]. Higher node ID wins, no drama 👑.

When a node does not support the Bandwidth Availability TLV, the node should send a PathErr message with error code "Unknown Attributes TLV", as specified in [RFC5420]. An LSP could also be set up in this case if there's enough bandwidth (note that the availability level of the reserved bandwidth is unknown). 🙈

When a node receives Bandwidth Availability TLVs with a mix of zero and non-zero indexes, the message MUST be ignored and MUST NOT be propagated. When a node receives Bandwidth Availability TLVs (non-zero index) with no matching index value among the Ethernet Bandwidth Profile TLVs, the message MUST be ignored and MUST NOT be propagated. When a node receives several <bandwidth, availability> pairs, but there are extra Ethernet Bandwidth Profile TLVs that do not match the index of any Bandwidth Availability TLV, the extra Ethernet Bandwidth Profile TLVs MUST be ignored and MUST NOT be propagated. Not propagating the mismatched stuff is non-negotiable, bestie 😭

4. Security Considerations 🔒

Okay, security time, and I'm being so serious about it. This document defines a Bandwidth Availability TLV in RSVP-TE signaling used in GMPLS networks. [RFC3945] notes that authentication in GMPLS systems may use the authentication mechanisms of the component protocols. [RFC5920] gives an overview of security vulnerabilities and protection mechanisms for the GMPLS control plane. In particular, Section 7.1.2 of [RFC5920] discusses control-plane protection with RSVP-TE by using general RSVP security tools, limiting the impact of an attack on control-plane resources, and using authentication for RSVP messages. Moreover, the GMPLS network is often considered to be a closed network, so insertion, modification, or inspection of packets by an outside party is not possible. 🕵️‍♀️ Still, read Section 7.1.2 of [RFC5920] like it's your job.

5. IANA Considerations 🎀

IANA maintains a registry of GMPLS parameters called the "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Parameters" registry. This registry includes the "Ethernet Sender TSpec TLVs/ Ethernet Flowspec TLVs" subregistry, which holds the TLV type values for TLVs carried in the Ethernet SENDER_TSPEC object. This subregistry has been updated to include the Bandwidth Availability TLV:

      Type             Description                 Reference
      ----             ----------------------      ---------
       4               Bandwidth Availability      RFC 8625

6. References 📚

6.1. Normative References

6.2. Informative References

  • [EN-302-217] ETSI, "Fixed Radio Systems; Characteristics and requirements for point-to-point equipment and antennas; Part 1: Overview and system-independent common characteristics", ETSI EN 302 217-1, Version 3.1.1, May 2017.
  • [F.1703] ITU-R, "Availability objectives for real digital fixed wireless links used in 27 500 km hypothetical reference paths and connections", ITU-R Recommendation F.1703-0, January 2005, <https://www.itu.int/rec/R-REC-F.1703/en>.
  • [G.827] ITU-T, "Availability performance parameters and objectives for end-to-end international constant bit-rate digital paths", ITU-T Recommendation G.827, September 2003, <https://www.itu.int/rec/T-REC-G.827/en>.
  • [P.530] ITU-R, "Propagation data and prediction methods required for the design of terrestrial line-of-sight systems", ITU-R Recommendation P.530-17, December 2017, <https://www.itu.int/rec/R-REC-P.530/en>.
  • [RFC3945] Mannie, E., Ed., "Generalized Multi-Protocol Label Switching (GMPLS) Architecture", RFC 3945, DOI 10.17487/RFC3945, October 2004, <https://www.rfc-editor.org/info/rfc3945>.
  • [RFC5920] Fang, L., Ed., "Security Framework for MPLS and GMPLS Networks", RFC 5920, DOI 10.17487/RFC5920, July 2010, <https://www.rfc-editor.org/info/rfc5920>.
  • [RFC8330] Long, H., Ye, M., Mirsky, G., D'Alessandro, A., and H. Shah, "OSPF Traffic Engineering (OSPF-TE) Link Availability Extension for Links with Variable Discrete Bandwidth", RFC 8330, DOI 10.17487/RFC8330, February 2018, <https://www.rfc-editor.org/info/rfc8330>.

Appendix A. Bandwidth Availability Example 🦋

Okay, this appendix is my favourite, because it's basically a microwave-link weather story 🌧️. In mobile backhaul networks, microwave links are super popular for providing connections on the last hops. To keep the link connected in heavy rain, the microwave link may lower the modulation level, since moving to a lower modulation level gives a lower SNR requirement. This is called "adaptive modulation" technology [EN-302-217]. The catch is that a lower modulation level also means a lower link bandwidth. When a link bandwidth drops because of modulation downshifting, high-priority traffic can be maintained while lower-priority traffic gets dropped. Similarly, copper links may change their link bandwidth due to external interference. ⚡

Let's presume that a link has three discrete bandwidth levels:

  • The link bandwidth under modulation level 1 (e.g., QPSK) is 100 Mbps.
  • The link bandwidth under modulation level 2 (e.g., 16QAM) is 200 Mbps.
  • The link bandwidth under modulation level 3 (e.g., 256QAM) is 400 Mbps.

On a sunny day, modulation level 3 can be used to achieve a 400 Mbps link bandwidth. ☀️

Light rain with an X mm/h rate triggers the system to change the modulation level from level 3 to level 2, with the bandwidth changing from 400 Mbps to 200 Mbps. The probability of X mm/h rain in the local area is 52 minutes in a year. Then the dropped 200 Mbps bandwidth has 99.99% availability. 🌦️

Heavy rain with a Y(Y>X) mm/h rate triggers the system to change the modulation level from level 2 to level 1, with the bandwidth changing from 200 Mbps to 100 Mbps. The probability of Y mm/h rain in the local area is 26 minutes in a year. Then the dropped 100 Mbps bandwidth has 99.995% availability. ⛈️

For the 100 Mbps bandwidth of modulation level 1, only extreme weather conditions can cause the whole system to be unavailable, which only happens for 5 minutes in a year. So the 100 Mbps bandwidth of the modulation level 1 owns the availability of 99.999%. 👑

There are discrete buckets per availability level. Under the worst weather conditions, there's only 100 Mbps capacity, which is 99.999% available. It's treated effectively as "always available" since better availability is not possible. If the weather is bad but not the worst possible conditions, modulation level 2 can be used, which gets an additional 100 Mbps bandwidth (i.e., 200 Mbps total). Therefore, 100 Mbps is in the 99.999% bucket, and 100 Mbps is in the 99.995% bucket. In clear weather, modulation level 3 can be used to get 400 Mbps total, but that's only 200 Mbps more than at modulation level 2, so the 99.99% bucket has that "extra" 200 Mbps, and the other two buckets still have 100 Mbps each. 🪣

Therefore, the maximum bandwidth is 400 Mbps. The sub-bandwidth and its availability according to the weather conditions are shown as follows:

      Sub-bandwidth (Mbps)   Availability
      ------------------     ------------

      200                    99.99%

      100                    99.995%

      100                    99.999%

Acknowledgments 🫶

The authors would like to thank Deborah Brungard, Khuzema Pithewan, Lou Berger, Yuji Tochio, Dieter Beller, and Autumn Liu for their comments on and contributions to the document. Y'all are absolutely iconic 💖

Authors' Addresses 💖

Okay bestie, these are the humans who wrote this spec, and you can literally reach out to them 🫶 Each block below is their contact info, copied exactly as it appears in the RFC.

Hao Long
Huawei Technologies Co., Ltd.
No.1899, Xiyuan Avenue, Hi-tech Western District
Chengdu 611731
China

Phone: +86-18615778750
Email: longhao@huawei.com


Min Ye (editor)
Huawei Technologies Co., Ltd.
No.1899, Xiyuan Avenue, Hi-tech Western District
Chengdu 611731
China

Email: amy.yemin@huawei.com


Greg Mirsky (editor)
ZTE

Email: gregimirsky@gmail.com


Alessandro D'Alessandro
Telecom Italia S.p.A

Email: alessandro.dalessandro@telecomitalia.it


Himanshu Shah
Ciena Corp.
3939 North First Street
San Jose, CA 95134
United States of America

Email: hshah@ciena.com

Five authors, three companies, and two editors who kept this whole thing together 👑 ✨

📦 where this page comes from