RFC 5976

Y.1541-QOSM: Model for Networks Using Y.1541 Quality-of-Service Classes

📅 published October 2010, from ietf

RFC 5976 🎀 Y.1541-QOSM: Model for Networks Using Y.1541 Quality-of-Service Classes

okay bestie, this one is from the IETF and it's Experimental (not a Standards Track spec 🧪). It came out in October 2010, and the ISSN is 2070-1721. The authors are G. Ash, A. Morton, M. Dolly, P. Tarapore, and C. Dvorak from AT&T Labs, plus Y. El Mghazli from Alcatel-Lucent 🌸. The header doesn't list anything it obsoletes or updates, so there's no lineage drama here ✨.

Abstract

okay so this doc describes a QoS-NSLP Quality-of-Service model (QOSM) that's built on the ITU-T Recommendation Y.1541 Network QoS Classes, plus some related signaling guidance 💅. Y.1541 specifies 8 classes of Network Performance objectives, and the Y.1541-QOSM extensions add extra QSPEC parameters and QOSM processing guidelines 🦋.

Status of This Memo

not gonna lie, this section is a lot, but the vibe is: this is not an Internet Standards Track spec. It's published so people can examine it, try out experimental implementations, and evaluate it 🧪.

It defines an Experimental Protocol for the Internet community. It's a product of the Internet Engineering Task Force (IETF) and represents the consensus of the IETF community 🫶. It got public review and was approved for publication by the Internet Engineering Steering Group (IESG). Not every IESG-approved doc is a candidate for any level of Internet Standard, so see Section 2 of RFC 5741 for the details 👑.

For the current status, any errata, and how to give feedback, check http://www.rfc-editor.org/info/rfc5976 💌.

the legal bit 🧾: Copyright (c) 2010 IETF Trust and the persons identified as the document authors, all rights reserved.

This doc is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents, which are at http://trustee.ietf.org/license-info and apply on the publication date. Read those carefully, because they spell out your rights and restrictions 📜. Code Components pulled out of this doc have to include the Simplified BSD License text described in Section 4.e of the Trust Legal Provisions, and they come with no warranty, as the Simplified BSD License says 🌈.

This doc may contain material from IETF Documents or IETF Contributions that were published or 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 a proper license from those copyright holders, this doc can't be modified outside the IETF Standards Process, and derivative works can't be made outside it either. The one exception is formatting it for publication as an RFC, or translating it into languages other than English 🌍.

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
     1.1.  Requirements Language  . . . . . . . . . . . . . . . . . .  3
   2.  Summary of ITU-T Recommendations Y.1541 and Signaling
       Requirements . . . . . . . . . . . . . . . . . . . . . . . . .  3
     2.1.  Description of Y.1541 Classes  . . . . . . . . . . . . . .  4
     2.2.  Y.1541-QOSM Processing Requirements  . . . . . . . . . . .  6
   3.  Additional QSPEC Parameters for Y.1541 QOSM  . . . . . . . . .  7
     3.1.  Traffic Model (TMOD) Extension Parameter . . . . . . . . .  7
     3.2.  Restoration Priority Parameter . . . . . . . . . . . . . .  8
   4.  Y.1541-QOSM Considerations and Processing Example  . . . . . . 10
     4.1.  Deployment Considerations  . . . . . . . . . . . . . . . . 10
     4.2.  Applicable QSPEC Procedures  . . . . . . . . . . . . . . . 10
     4.3.  QNE Processing Rules . . . . . . . . . . . . . . . . . . . 10
     4.4.  Processing Example . . . . . . . . . . . . . . . . . . . . 10
     4.5.  Bit-Level QSPEC Example  . . . . . . . . . . . . . . . . . 12
     4.6.  Preemption Behavior  . . . . . . . . . . . . . . . . . . . 14
   5.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 14
     5.1.  Assignment of QSPEC Parameter IDs  . . . . . . . . . . . . 14
     5.2.  Restoration Priority Parameter Registry  . . . . . . . . . 14
       5.2.1.  Restoration Priority Field . . . . . . . . . . . . . . 14
       5.2.2.  Time to Restore Field  . . . . . . . . . . . . . . . . 15
       5.2.3.  Extent of Restoration Field  . . . . . . . . . . . . . 15
   6.  Security Considerations  . . . . . . . . . . . . . . . . . . . 16
   7.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 16
   8.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 17
     8.1.  Normative References . . . . . . . . . . . . . . . . . . . 17
     8.2.  Informative References . . . . . . . . . . . . . . . . . . 17

1. Introduction ✨

okay so this doc describes a QoS model (QOSM) for the Next Steps in Signaling (NSIS) QoS signaling layer protocol (QoS-NSLP) application 🧚. It's based on ITU-T Recommendation Y.1541 Network QoS Classes and related signaling guidance. [Y.1541] currently specifies 8 classes of Network Performance objectives, and the Y.1541-QOSM extensions add more QSPEC [RFC5975] parameters and QOSM processing guidelines 💖. The extensions come from standardization work at the ITU-T on QoS signaling requirements, which is covered in [Y.1541] and [E.361], plus guidance from [TRQ-QoS-SIG] 🌸.

[RFC5974] defines the message types and control information for the QoS-NSLP that apply to every QOSM, and a QOSM is basically a defined mechanism for achieving QoS as a whole 🦋. A QOSM's spec covers its QSPEC parameter information and how that info should be treated or interpreted in the network. The QSPEC [RFC5975] holds a set of parameters and values that describe the requested resources 🎀. The QoS-NSLP doesn't look inside it (it's opaque), and it's kind of like the TSpec, RSpec, and AdSpec from [RFC2205] and [RFC2210] 🫶.

Each QoS NSIS Entity (QNE) interprets the QSPEC contents through the resource management function (RMF). That's how policy control and traffic control happen, including admission control and configuring the scheduler 🔥.

1.1. Requirements Language

the BCP 14 key words are the rules-of-the-road words in this doc, so here they are, verbatim 📌: 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 RFC 2119 [RFC2119] 💅.

2. Summary of ITU-T Recommendations Y.1541 and Signaling Requirements 👑

as we said up top, [Y.1541] defines standardized QoS classes for IP networks, and you'll get a quick summary of them below 💜. Section 7 of [TRQ-QoS-SIG] covers the signaling features you need for end-to-end QoS in IP networks, using the Y.1541 QoS classes as the foundation 🌈. [Y.1541] goes for a flexible split of the end-to-end performance objectives (like delay) across networks, rather than a fixed per-network allocation, which is very much a "it depends on the path" energy 🧚. The good news is that NSIS protocols already cover most of the requirements. This doc just adds the extra QSPEC parameters and processing requirements needed to support the Y.1541 QOSM 🦋✨.

more in part 2 bestie 🫶💖

2.1. Description of Y.1541 Classes ✨

okay so [Y.1541] groups services into QoS classes based on the performance objectives they need 💅 these classes cover a huge range of user apps. The classes group objectives for one-way IP packet delay, IP packet delay variation, IP packet loss ratio, and so on, and the actual parameters are defined in [Y.1540] 🦋

ngl the ITU-T keeps updating [Y.1541], so the stuff in this section is just here for info and to make the doc easier to read 🌸 if there's ever a mismatch, the normative definitions in [Y.1541] win, no debate 🫶

Classes 0 and 1 might be built with the Diffserv Expedited Forwarding (EF) Per-Hop Behavior (PHB), and they support interactive real-time apps [RFC3246] 🎀 Classes 2, 3, and 4 might use the Diffserv Assured Forwarding (AFxy) PHB Group, which supports data transfer apps with different levels of interactivity [RFC2597] 💜 Class 5 generally lines up with the Diffserv Default PHB, where all the QoS parameters are unspecified, which fits a best-effort service [RFC2474] 🌈 Classes 6 and 7 are for apps that are super sensitive to loss, like high-quality digital TV, Time Division Multiplexing (TDM) circuit emulation, and high-capacity file transfers using TCP 😭 All of these classes are meant to be a base for agreements between end-users and service providers, and between service providers too 👑 They cover loads of apps, including point-to-point telephony, data transfer, multimedia conferencing, and more ✨ The limited number of classes is what keeps implementation feasible, especially when you think about scale in global networks 🧚

The QoS classes apply to a packet flow. [Y.1541] defines a packet flow as the traffic tied to a given connection or connectionless stream that shares the same source host, destination host, class of service, and session identification 🦋 Here's the quick rundown of each Y.1541 QoS class:

Class 0: Real-time, highly interactive apps that are sensitive to jitter. Mean delay <= 100 ms, delay variation <= 50 ms, and loss ratio <= 10^-3. Example apps include VoIP and video teleconference 💖

Class 1: Real-time, interactive apps that are sensitive to jitter. Mean delay <= 400 ms, delay variation <= 50 ms, and loss ratio <= 10^-3. Example apps include VoIP and video teleconference 🎀

Class 2: Highly interactive transaction data. Mean delay <= 100 ms, delay variation is unspecified, and loss ratio <= 10^-3. Example apps include signaling 🌸

Class 3: Interactive transaction data. Mean delay <= 400 ms, delay variation is unspecified, and loss ratio <= 10^-3. Example apps include signaling 🍓

Class 4: Low Loss Only apps. Mean delay <= 1 s, delay variation is unspecified, and loss ratio <= 10^-3. Example apps include short transactions, bulk data, and video streaming 🌈

Class 5: Unspecified apps with unspecified mean delay, delay variation, and loss ratio. Example apps include traditional apps of default IP networks 💅

Class 6: Apps that are highly sensitive to loss. Mean delay <= 100 ms, delay variation <= 50 ms, and loss ratio <= 10^-5. Example apps include television transport, high-capacity TCP transfers, and Time-Division Multiplexing (TDM) circuit emulation 🔥

Class 7: Apps that are highly sensitive to loss. Mean delay <= 400 ms, delay variation <= 50 ms, and loss ratio <= 10^-5. Example apps include television transport, high-capacity TCP transfers, and TDM circuit emulation 👑

These classes let customers and network service providers define service level agreements (SLAs) around QoS requirements ✨ The service provider then needs to make sure those requirements are recognized and get appropriate treatment across network layers 💜

Work is in progress on methods for combining local values of performance metrics to estimate the performance of the complete path 👀 See Section 8 of [Y.1541], [RFC5835], and [COMPOSITION] 🫶

2.2. Y.1541-QOSM Processing Requirements 💖

[TRQ-QoS-SIG] guides the specification of signaling information for IP-based QoS at the interface between the user and the network (UNI) and across interfaces between different networks (NNI) 🦋 To hit the specific network performance requirements set for the Y.1541 QoS classes [Y.1541], a network needs to provide specific user-plane functionality at the UNI and NNI 🌸 Dynamic network provisioning at a UNI and/or NNI node lets a traffic contract for an IP flow be requested on the fly, from a specific source node to one or more destination nodes ✨ When that request comes in, the network checks whether resources are available to satisfy it and then provisions the network accordingly 🧚

For implementations to claim compliance with this memo, it MUST be possible to derive the following service-level parameters as part of the process of requesting service 🎀

  • a. Y.1541 QoS class, 32-bit integer, range: 0-7
  • b. rate (r), octets per second
  • c. peak rate (p), octets per second
  • d. bucket size (b), octets
  • e. maximum packet size (MPS), octets, IP header + IP payload
  • f. Diffserv PHB class [RFC2475]
  • g. admission priority, 32-bit integer, range: 0-2

Compliant implementations MAY derive the following service-level parameters as part of the service request process 🌈

  • h. peak bucket size (Bp), octets, 32-bit floating point number in single-precision IEEE floating point format [IEEE754]
  • i. restoration priority, multiple integer values defined in Section 3 below

All parameters except Bp and restoration priority have already been specified in [RFC5975] 💜 These additional parameters are defined as follows:

  • Bp, the size of the peak-rate bucket in a dual-token bucket arrangement, essentially setting the maximum length of bursts in the peak-rate stream. For example, see Annex B of [Y.1221]
  • restoration priority, as defined in Section 3 of this memo

Their QSPEC Parameter format is specified in Section 3 🍓

It MUST be possible to perform the following QoS-NSLP signaling functions to meet Y.1541-QOSM requirements 🔥

  • a. accumulate delay, delay variation, and loss ratio across the end-to-end connection, which may span multiple domains.
  • b. enable negotiation of Y.1541 QoS class across domains.
  • c. enable negotiation of delay, delay variation, and loss ratio across domains.

These signaling requirements are supported in [RFC5974], and the functions are illustrated in Section 4 of this memo 👑

3. Additional QSPEC Parameters for Y.1541 QOSM 🧚

The specifications in this section extend the QSPEC [RFC5975] 🦋

3.1. Traffic Model (TMOD) Extension Parameter 💅

The traffic model (TMOD) extension parameter is represented by one floating point number in single-precision IEEE floating point format and one 32-bit reserved field ✨ It looks like this:

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |M|E|N|r|           15          |r|r|r|r|          1            |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |  Peak Bucket Size [Bp] (32-bit IEEE floating point number)    |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                         Figure 1: TMOD Extension

The Peak Bucket Size term, Bp, is represented as an IEEE floating point value [IEEE754] in units of octets 🌸 The sign bit MUST be zero (all values MUST be non-negative) 🙈 Exponents less than 127 (i.e., 0) are prohibited 😭 Exponents greater than 162 (i.e., positive 35) are discouraged, except for specifying a peak rate of infinity 💀 Infinity is represented with an exponent of all ones (255), and a sign bit and mantissa of all zeros 💖

The QSPEC parameter behavior for the TMOD extended parameter follows what's defined in Section 3.3.1 of [RFC5975] 🎀 The new parameter (and all traffic-related parameters) are specified independently from the Y.1541 class parameter 🫶

3.2. Restoration Priority Parameter 🦋

okay so restoration priority is basically how urgently a service needs to bounce back after something breaks 🚨 You get it by provisioning enough backup capacity where it's needed, and by giving some traffic priority access to restoration bandwidth when everything is fighting over the same spare room 💅 Here's the layout:

  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
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |M|E|N|r|           16          |r|r|r|r|          1            |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 | Rest. Priority|  TTR  |  EOR  |        (Reserved)             |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 2: Restoration Priority Parameter

This parameter has three fields and a reserved area, as defined below. 🎀

Restoration Priority Field (8-bit unsigned integer): there are 3 priority values, listed from lowest priority to highest priority:

  • 0 - best effort
  • 1 - normal
  • 2 - high

These priority values are described in [Y.2172], where best-effort priority is the same as Priority level 3, normal priority is Priority level 2, and high priority is Priority level 1. There are several ways to elaborate on restoration priority, and the two current parameters are described below. 🌸

Time-to-Restore (TTR) Field (4-bit unsigned integer): this is the total amount of time it takes to restore the traffic streams in a given restoration class that got hit by the failure ⏱️ How long that takes depends on the technology used for restoration. A fast recovery period of < 200 ms is based on current experience with Synchronous Optical Network (SONET) rings, and a slower recovery period of 2 seconds is suggested so a voice call can recover without getting dropped 📞 So the suggested TTR ranges are:

  • 0 - Unspecified Time-to-Restore
  • 1 - Best Time-to-Restore: <= 200 ms
  • 2 - Normal Time-to-Restore <= 2 s

Extent of Restoration (EOR) Field (4-bit unsigned integer): this is the percentage of traffic in the restoration class that can actually be restored 📊 It depends on how much spare capacity was engineered. For example, all high-priority restoration traffic may be "guaranteed" at 100% by the service provider 👑 Other classes might have lower chances of successful restoration, and the restoration extent for those lower priority classes depends on the SLAs worked out between the service provider and the customer. 🤝

EOR values are assigned as follows:

  • 0 - unspecified EOR
  • 1 - high priority restored at 100%; medium priority restored at 100%
  • 2 - high priority restored at 100%; medium priority restored at 80%
  • 3 - high priority restored >= 80%; medium priority restored >= 80%
  • 4 - high priority restored >= 80%; medium priority restored >= 60%
  • 5 - high priority restored >= 60%; medium priority restored >= 60%

Reserved: these 2 octets are reserved 🔒 The Reserved bits MAY be designated for other uses in the future. Senders conforming to this version of the Y.1541 QOSM SHALL set the Reserved bits to zero. Receivers conforming to this version of the Y.1541 QOSM SHALL ignore the Reserved bits. 🙈

4. Y.1541-QOSM Considerations and Processing Example ✨

in this section we're going to see the Y.1541 QOSM in action and how the current QoS-NSLP and QSPEC functionality gets used 🧚 Good news: no new processing capabilities are needed to enable the Y.1541 QOSM (apart from the two OPTIONAL new parameters specified in Section 3). 💖

4.1. Deployment Considerations 🏠

[TRQ-QoS-SIG] really emphasizes deploying Y.1541 QNEs at the borders of supporting domains 🧱 There might be domain setups where interior QNEs are useful too, and the example below covers that possibility. 🦋

4.2. Applicable QSPEC Procedures 📋

All procedures defined in Section 5.3 of [RFC5975] are applicable to this QOSM. 💅

4.3. QNE Processing Rules 🛠️

Section 7 of [TRQ-QoS-SIG] describes the information processing in Y.1541 QNEs. 🔍

Section 8 of [Y.1541] defines the accumulation rules for individual performance parameters (e.g., delay, jitter). ➕

When a QoS NSIS initiator (QNI) specifies the Y.1541 QoS Class number, <Y.1541 QoS Class>, that alone is a sufficient specification of objectives for the <Path Latency>, <Path Jitter>, and <Path BER> parameters 🎯 As described in Section 2, some Y.1541 Classes don't set objectives for all the performance parameters above. For example, Classes 2, 3, and 4 don't specify an objective for <Path Jitter> (referred to as IP Packet Delay Variation). 🙃 If the QoS Class leaves a parameter unspecified, then that parameter need not be included in the accumulation processing. ✨

4.4. Processing Example 🎬

As described in the example given in Section 3.4 of [RFC5975] and as illustrated in Figure 3, the QoS NSIS initiator (QNI) sends an end-to-end, interdomain QoS NSLP RESERVE message that carries the Initiator QSPEC 📨 For the Y.1541 QOSM, the Initiator QSPEC specifies the <Y.1541 QOS Class>, <TMOD>, <TMOD Extension>, <Admission Priority>, <Restoration Priority>, and maybe other QSPEC parameters for the flow. As described in Section 3, the TMOD extension parameter contains the OPTIONAL Y.1541-QOSM-specific terms, and restoration priority is also an OPTIONAL Y.1541-QOSM-specific parameter. 🌈

As Figure 3 shows below, the RESERVE message may cross multiple domains that support different QOSMs 🗺️ In this illustration, the Initiator QSPEC shows up in a QoS NSLP RESERVE message at the ingress node of the local-QOSM domain. As described in [RFC5974] and [RFC5975], at the ingress edge node of the local-QOSM domain, the end-to-end, interdomain QoS-NSLP message may trigger the generation of a Local QSPEC, and the Initiator QSPEC gets encapsulated within the messages signaled through the local domain 🎁 The Local QSPEC handles QoS processing in the local-QOSM domain, and the Initiator QSPEC handles QoS processing outside the local domain. As specified in [RFC5975], if any QNE can't meet the requirements designated by the Initiator QSPEC to support an optional QSPEC parameter (i.e., with the M bit set to zero for the parameter), the QNE sets the N flag (not supported flag) for the parameter to one 🚩 For example, if the QNE can't support accumulating end-to-end delay with the <Path Latency> parameter, where the M flag for <Path Latency> is set to zero (marking it as an optional parameter), the QNE sets the N flag (not supported flag) for <Path Latency> to one. 🙌

Also, the Y.1541-QOSM requires negotiation of the <Y.1541 QoS Class> across domains 🤝 This negotiation can use the existing procedures already defined in [RFC5974]. For example, the QNI sets the <Desired QoS>, <Minimum QoS>, and <Available QoS> objects to include <Y.1541 QoS Class>, which specifies objectives for the <Path Latency>, <Path Jitter>, and <Path BER> parameters. If the QoS Class leaves a parameter unspecified, then that parameter need not be included in the accumulation processing. 💜 The QNE/domain SHOULD set the Y.1541 class and cumulative parameters, e.g., <Path Latency>, that can be achieved in the <QoS Available> object (but not less than what's specified in <Minimum QoS>). This could include, for example, setting the <Y.1541 QoS Class> to a lower class than specified in <QoS Desired> (but not lower than specified in <Minimum QoS>). If the <Available QoS> fails to satisfy one or more of the <Minimum QoS> objectives, the QNE/domain notifies the QNI and the reservation is aborted 💀 Otherwise, the QoS NSIS Receiver (QNR) notifies the QNI of the <QoS Available> for the reservation. ✅

When the available <Y.1541 QoS Class> has to be reduced from the desired <Y.1541 QoS Class> (say, because the delay objective was exceeded), there's an incentive to respond with an available value for delay in the <Path Latency> parameter 📉 If the available <Path Latency> is 150 ms (still useful for many applications) and the desired QoS is Class 0 (with its 100 ms objective), then the response would be that Class 0 can't be achieved, and Class 1 is available (with its 400 ms objective). Plus, this QOSM lets the response include an available <Path Latency> = 150 ms, which makes accepting the available <Y.1541 QoS Class> more likely 🥹 There are lots of long paths where the propagation delay alone exceeds the Y.1541 Class 0 objective, so this feature adds flexibility to commit to exceeding the Class 1 objective when possible. 🌟

This example shows Y.1541-QOSM negotiation of the <Y.1541 QoS Class> and the cumulative parameter values that can be achieved end-to-end 🔗 It also shows how the QNI can use the cumulative values collected in <QoS Available> to decide whether a lower <Y.1541 QoS Class> than the one in <QoS Desired> is acceptable. 🧠

  |------|   |------|                           |------|   |------|
  | e2e  |<->| e2e  |<------------------------->| e2e  |<->| e2e  |
  | QOSM |   | QOSM |                           | QOSM |   | QOSM |
  |      |   |------|   |-------|   |-------|   |------|   |      |
  | NSLP |   | NSLP |<->| NSLP  |<->| NSLP  |<->| NSLP |   | NSLP |
  |Y.1541|   |local |   |local  |   |local  |   |local |   |Y.1541|
  | QOSM |   | QOSM |   | QOSM  |   | QOSM  |   | QOSM |   | QOSM |
  |------|   |------|   |-------|   |-------|   |------|   |------|
  -----------------------------------------------------------------
  |------|   |------|   |-------|   |-------|   |------|   |------|
  | NTLP |<->| NTLP |<->| NTLP  |<->| NTLP  |<->| NTLP |<->| NTLP |
  |------|   |------|   |-------|   |-------|   |------|   |------|
    QNI         QNE        QNE         QNE         QNE       QNR
  (End)  (Ingress Edge) (Interior)  (Interior) (Egress Edge)  (End)

Figure 3: Example of Y.1541-QOSM Operation 🦋✨

4.5. Bit-Level QSPEC Example ✨

okay bestie, this example is giving everything 💅 The QOS Desired spec has the TMOD-1 parameters, the extended TMOD parameters from this spec, and the Y.1541 Class parameter. The QOS Available spec uses Latency, Jitter, and Loss so the numbers can pile up and be compared against the Y.1541 Class objectives 🧮🦋

This example assumes that all the parameters MUST be supported by the QNEs, so all M-flags are set to 1 🔥 (yes, MUST is in caps on purpose, it's a real requirement, not vibes)

      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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |  Vers.|QType=I|QSPEC Proc.=0/1|0|R|R|R|      Length = 23      |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |E|r|r|r|  Type = 0 (QoS Des.)  |r|r|r|r|      Length = 10      |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |1|E|0|r|    ID = 1 <TMOD-1>    |r|r|r|r|      Length = 5       |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |  TMOD Rate-1 [r] (32-bit IEEE floating point number)          |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |  TMOD Size-1 [b] (32-bit IEEE floating point number)          |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |  Peak Data Rate-1 [p] (32-bit IEEE floating point number)     |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |  Minimum Policed Unit-1 [m] (32-bit unsigned integer)         |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |  Maximum Packet Size [MPS] (32-bit unsigned integer)          |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |1|E|N|r|           15          |r|r|r|r|          1            |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |  Peak Bucket Size [Bp] (32-bit IEEE floating point number)    |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |1|E|N|r|           14          |r|r|r|r|          1            |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |Y.1541 QoS Cls.|                (Reserved)                     |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |E|r|r|r|  Type = 1 (QoS Avail) |r|r|r|r|      Length = 11      |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |1|E|N|r|           3           |r|r|r|r|          1            |
     +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
     |                Path Latency (32-bit integer)                  |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |1|E|N|r|           4           |r|r|r|r|          4            |
     +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
     |          Path Jitter STAT1(variance) (32-bit integer)         |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |          Path Jitter STAT2(99.9%-ile) (32-bit integer)        |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |       Path Jitter STAT3(minimum Latency) (32-bit integer)     |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |       Path Jitter STAT4(Reserved)        (32-bit integer)     |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |1|E|N|r|           5           |r|r|r|r|          1            |
     +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
     |             Path Packet Loss Ratio (32-bit floating point)    |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |1|E|N|r|           14          |r|r|r|r|          1            |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |Y.1541 QoS Cls.|                (Reserved)                     |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 4: An Example QSPEC (Initiator) 🎀

where 32-bit floating point numbers are as specified in [IEEE754]. 🧠

4.6. Preemption Behavior 🫶

the default QNI behavior of tearing down a preempted reservation is followed in the Y.1541 QOSM, so no drama there 💀 And the restoration priority parameter from earlier doesn't rely on preemption at all, so the two don't get tangled up. ✨

5. IANA Considerations 📋

this section adds more codepoint assignments to the QSPEC Parameter ID registry and creates one brand-new registry for the Restoration Priority Parameter (with initial values filled in), all following BCP 26 [RFC5226]. It also spells out the procedural rules IANA has to follow when allocating new codepoints for that new registry 🌸

5.1. Assignment of QSPEC Parameter IDs 🦋

this document specifies the following QSPEC parameters, which were assigned in the QSPEC Parameter ID registry created in [RFC5975]:

  • TMOD Extension parameter (Section 3.1, ID=15)
  • Restoration Priority parameter (Section 3.2, ID=16)

5.2. Restoration Priority Parameter Registry 👑

the Registry for Restoration Priority has assignments for 3 fields in the 4-octet word, plus a Reserved section of that word 🍓

this specification creates the following registry, structured exactly as defined below.

5.2.1. Restoration Priority Field 💖

the Restoration Priority Field is 8 bits long.

the following values are allocated by this specification:

  • 0-2: assigned as specified in Section 3.2:
    • 0: best-effort priority
    • 1: normal priority
    • 2: high priority

further values are as follows:

  • 3-255: Unassigned

The registration procedure is Specification Required.

5.2.2. Time to Restore Field ⏱️

the Time to Restore Field is 4 bits long.

the following values are allocated by this specification:

  • 0-2: assigned as specified in Section 3.2:
    • 0 - Unspecified Time-to-Restore
    • 1 - Best Time-to-Restore: <= 200 ms
    • 2 - Normal Time-to-Restore <= 2 s

further values are as follows:

  • 3-15: Unassigned

The registration procedure is Specification Required.

5.2.3. Extent of Restoration Field 🌈

the Extent of Restoration (EOR) Field is 4 bits long.

the following values are allocated by this specification:

  • 0-5: assigned as specified in Section 3.2:
    • 0 - unspecified EOR
    • 1 - high priority restored at 100%; medium priority restored at 100%
    • 2 - high priority restored at 100%; medium priority restored at 80%
    • 3 - high priority restored >= 80%; medium priority restored >= 80%
    • 4 - high priority restored >= 80%; medium priority restored >= 60%
    • 5 - high priority restored >= 60%; medium priority restored >= 60%

further values are as follows:

  • 6-15: Unassigned

The registration procedure is Specification Required.

6. Security Considerations 🔐

this part is serious, bestie, so read it carefully 🚨

the security considerations of [RFC5974] and [RFC5975] apply to this document.

the restoration priority parameter opens the door to theft-of-service attacks 😱 Users could claim an emergency priority for their flows without any real need, and that could effectively stop serious emergency calls from getting through. Several options exist for countering this, for example:

  • only some user groups (e.g., the police) are authorized to set the emergency priority bit
  • any user is authorized to employ the emergency priority bit for particular destination addresses (e.g., police or fire departments)

There are no other known security considerations based on this document. 🫡

7. Acknowledgements 💜

the authors thank Attila Bader, Cornelia Kappler, Sven Van den Bosch, and Hannes Tschofenig for their helpful comments and discussion 🫶

8. References 📚

8.1. Normative References 🧷

  • [IEEE754] ANSI/IEEE, "ANSI/IEEE 754-1985, IEEE Standard for Binary Floating-Point Arithmetic", 1985.
  • [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
  • [RFC5974] Manner, J., Karagiannis, G., and A. McDonald, "NSIS Signaling Layer Protocol (NSLP) for Quality-of-Service Signaling", RFC 5974, October 2010.
  • [RFC5975] Ash, G., Bader, A., Kappler, C., and D. Oran, "QSPEC Template for the Quality-of-Service NSIS Signaling Layer Protocol (NSLP)", RFC 5975, October 2010.
  • [Y.1221] ITU-T Recommendation Y.1221, "Traffic control and congestion control in IP based networks", March 2002.
  • [Y.1540] ITU-T Recommendation Y.1540, "Internet protocol data communication service - IP packet transfer and availability performance parameters", December 2007.
  • [Y.1541] ITU-T Recommendation Y.1541, "Network Performance Objectives for IP-Based Services", February 2006.
  • [Y.2172] ITU-T Recommendation Y.2172, "Service restoration priority levels in Next Generation Networks", June 2007.

8.2. Informative References 🌷

  • [COMPOSITION] Morton, A. and E. Stephan, "Spatial Composition of Metrics", Work in Progress, July 2010.
  • [E.361] ITU-T Recommendation E.361, "QoS Routing Support for Interworking of QoS Service Classes Across Routing Technologies", May 2003.
  • [RFC2205] Braden, B., Zhang, L., Berson, S., Herzog, S., and S. Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification", RFC 2205, September 1997.
  • [RFC2210] Wroclawski, J., "The Use of RSVP with IETF Integrated Services", RFC 2210, September 1997.
  • [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, "Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers", RFC 2474, December 1998.
  • [RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., and W. Weiss, "An Architecture for Differentiated Services", RFC 2475, December 1998.
  • [RFC2597] Heinanen, J., Baker, F., Weiss, W., and J. Wroclawski, "Assured Forwarding PHB Group", RFC 2597, June 1999.
  • [RFC3246] Davie, B., Charny, A., Bennet, J., Benson, K., Le Boudec, J., Courtney, W., Davari, S., Firoiu, V., and D. Stiliadis, "An Expedited Forwarding PHB (Per-Hop Behavior)", RFC 3246, March 2002.
  • [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.
  • [RFC5835] Morton, A. and S. Van den Berghe, "Framework for Metric Composition", RFC 5835, April 2010.
  • [TRQ-QoS-SIG] ITU-T Supplement 51 to the Q-Series, "Signaling Requirements for IP-QoS", January 2004.

Authors' Addresses 🎀

okay bestie, this is the squad that made it happen 🫶 five AT&T Labs and Alcatel-Lucent people, each with their own contact deets. here's the full roster, exactly as it's listed:

   Gerald Ash
   AT&T Labs
   200 Laurel Avenue South
   Middletown, NJ  07748
   USA

   EMail: gash5107@yahoo.com


   Al Morton
   AT&T Labs
   200 Laurel Avenue South
   Middletown, NJ  07748
   USA

   Phone: +1 732 420 1571
   Fax:   +1 732 368 1192
   EMail: acmorton@att.com
   URI:   http://home.comcast.net/~acmacm/
   Martin Dolly
   AT&T Labs
   200 Laurel Avenue South
   Middletown, NJ  07748
   USA

   EMail: mdolly@att.com


   Percy Tarapore
   AT&T Labs
   200 Laurel Avenue South
   Middletown, NJ  07748
   USA

   EMail: tarapore@att.com


   Chuck Dvorak
   AT&T Labs
   180 Park Ave Bldg 2
   Florham Park, NJ  07932
   USA

   Phone: + 1 973-236-6700
   EMail: cdvorak@att.com


   Yacine El Mghazli
   Alcatel-Lucent
   Route de Nozay
   Marcoussis cedex  91460
   France

   Phone: +33 1 69 63 41 87
   EMail: yacine.el_mghazli@alcatel.fr

that's the whole crew 💖 Gerald, Al, Martin, Percy, Chuck and Yacine, all of them locked in on making this spec real 👑 if you need to reach any of them, the info above is everything you need 📬✨

📦 where this page comes from