RFC 5975
QSPEC Template for the Quality-of-Service NSIS Signaling Layer Protocol (NSLP)
QSPEC Template for the Quality-of-Service NSIS Signaling Layer Protocol (NSLP) ✨
Okay bestie, here's the deets on this doc 🎀 It's an Experimental RFC (not a Standards Track spec, so it's for trying out and examining, not a final standard) 🧪 Published by the IETF in October 2010, with ISSN 2070-1721 📅 It's all about the QSPEC template for QoS NSLP 🌈
The authors are G. Ash (AT&T), A. Bader (Ericsson), C. Kappler (ck technology concepts), and D. Oran (Cisco Systems, Inc.), and they're all listed as editors 🫶 The header doesn't list any documents it obsoletes or updates, so this one stands on its own 💅
Abstract
The QoS NSIS signaling layer protocol (NSLP) is used to signal QoS reservations, and it doesn't care which QoS model (QOSM) you use, like IntServ or Diffserv 🦋 Instead, all the QOSM-specific info goes in its own object called the QSPEC 📦 This doc defines a template for the QSPEC, along with a bunch of QSPEC parameters 💜 Those parameters give everyone a shared language that can be reused across several QOSMs, which is how the protocol stays extensible and interoperable ✨ The base protocol is QOSM-agnostic, but the parameters that can ride in the QSPEC object are kinda closely tied to specific models 👑 The node that starts the NSIS signaling adds an Initiator QSPEC, which lists the QSPEC parameters that downstream nodes must interpret, or else the reservation fails 😭 That way the NSIS initiator's intention survives all the way along the signaling path 🫶
Status of This Memo
This document is not an Internet Standards Track specification 🙈 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 document is a candidate for any level of Internet Standard, so check Section 2 of RFC 5741 if you're curious 🤓
Want the current status, any errata, or a way to send feedback? Head to http://www.rfc-editor.org/info/rfc5975 🦋
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), as in effect on the date of publication. Please read those 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 💅
Table of Contents
1. Introduction ....................................................4
1.1. Conventions Used in This Document ..........................6
2. Terminology .....................................................6
3. QSPEC Framework .................................................7
3.1. QoS Models .................................................7
3.2. QSPEC Objects ..............................................9
3.3. QSPEC Parameters ..........................................11
3.3.1. Traffic Model Parameter ............................12
3.3.2. Constraints Parameters .............................14
3.3.3. Traffic-Handling Directives ........................16
3.3.4. Traffic Classifiers ................................17
3.4. Example of QSPEC Processing ...............................17
4. QSPEC Processing and Procedures ................................20
4.1. Local QSPEC Definition and Processing .....................20
4.2. Reservation Success/Failure, QSPEC Error Codes,
and INFO-SPEC Notification ................................23
4.2.1. Reservation Failure and Error E Flag ...............24
4.2.2. QSPEC Parameter Not Supported N Flag ...............25
4.2.3. INFO-SPEC Coding of Reservation Outcome ............25
4.2.4. QNE Generation of a RESPONSE Message ...............26
4.2.5. Special Case of Local QSPEC ........................27
4.3. QSPEC Procedures ..........................................27
4.3.1. Two-Way Transactions ...............................28
4.3.2. Three-Way Transactions .............................30
4.3.3. Resource Queries ...................................32
4.3.4. Bidirectional Reservations .........................33
4.3.5. Preemption .........................................33
4.4. QSPEC Extensibility .......................................33
5. QSPEC Functional Specification .................................33
5.1. General QSPEC Formats .....................................33
5.1.1. Common Header Format ...............................34
5.1.2. QSPEC Object Header Format .........................36
5.2. QSPEC Parameter Coding ....................................37
5.2.1. <TMOD-1> Parameter .................................37
5.2.2. <TMOD-2> Parameter .................................38
5.2.3. <Path Latency> Parameter ...........................39
5.2.4. <Path Jitter> Parameter ............................40
5.2.5. <Path PLR> Parameter ...............................41
5.2.6. <Path PER> Parameter ...............................42
5.2.7. <Slack Term> Parameter .............................43
5.2.8. <Preemption Priority> and <Defending Priority>
Parameters .........................................43
5.2.9. <Admission Priority> Parameter .....................44
5.2.10. <RPH Priority> Parameter ..........................45
5.2.11. <Excess Treatment> Parameter ......................46
5.2.12. <PHB Class> Parameter .............................48
5.2.13. <DSTE Class Type> Parameter .......................49
5.2.14. <Y.1541 QoS Class> Parameter ......................50
6. Security Considerations ........................................51
7. IANA Considerations ............................................51
8. Acknowledgements ...............................................55
9. Contributors ...................................................55
10. Normative References ..........................................57
11. Informative References ........................................59
Appendix A. Mapping of QoS Desired, QoS Available, and QoS
Reserved of NSIS onto AdSpec, TSpec, and RSpec of RSVP IntServ .62
Appendix B. Example of TMOD Parameter Encoding ....................621. Introduction 🌸
Okay so the QoS NSIS signaling layer protocol (NSLP) [RFC5974] is what signals QoS reservations for a data flow 🦋 It also provides forwarding resources (QoS) for that flow, and it sets up and maintains state at the nodes along the flow's path ✨ QoS NSLP's design is conceptually similar to the split between RSVP [RFC2205] and the IntServ architecture [RFC2210], where the signaling protocol is kept separate from the info the Resource Management Function (RMF) needs 💅 [RFC5974] describes the signaling protocol, and this document describes the RMF-related info that rides in the QSPEC (QoS Specification) object inside QoS NSLP messages 🎀
[RFC5974] defines four QoS NSLP messages -- RESERVE, QUERY, RESPONSE, and NOTIFY -- and each one may carry the QSPEC object 💜 This document describes the template for that QSPEC object 🧚 The QSPEC carries info on traffic descriptions, resources required, resources available, and other stuff the RMF needs 🌈 So the QSPEC template is super tied to QoS NSLP, and you should be familiar with [RFC5974] to really get this doc 🤓
A QoS-enabled domain supports a particular QoS model (QOSM), which is basically a way to achieve QoS for a traffic flow ✨ A QOSM bundles QoS provisioning methods and a QoS architecture, and it defines how the RMF behaves when it reserves resources for each flow, including the inputs and outputs 👑 QoS NSLP can signal reservations for different QOSMs, since all the QOSM-specific info is wrapped up in the QSPEC object, and only the RMF for a given QOSM needs to interpret the QSPEC 🫶 Examples of QOSMs are IntServ, Diffserv admission control, and those specified in [CL-QOSM], [RFC5976], and [RFC5977] 🦋
QSPEC parameters include, for example:
- a mandatory traffic model (TMOD) parameter,
- constraints parameters such as path latency and path jitter,
- traffic handling directives such as excess treatment, and
- traffic classifiers such as PHB class.
The base protocol is QOSM-agnostic, but the parameters that can be carried in the QSPEC object are possibly closely coupled to specific models 💖
QSPEC objects loosely correspond to the TSpec, RSpec, and AdSpec objects specified in RSVP 🌸 They may contain, respectively, a description of QoS Desired, QoS Reserved, and QoS Available 🧁 Going beyond RSVP, the QSPEC also lets you indicate a range of acceptable QoS by defining a QSPEC object that denotes minimum QoS 🔥 Using these QSPEC objects isn't tied to particular message types, so it's super flexible 💅 A QSPEC object collecting info about available resources may travel in any QoS NSLP message, for example a QUERY message or a RESERVE message, as defined in [RFC5974] 🦋 The QSPEC travels in QoS NSLP messages but is opaque to QoS NSLP, and only the RMF interprets it 🙈
Interoperability between QoS NSIS entities (QNEs) in different domains gets a major boost from a common set of QSPEC parameters 🌈 A QoS NSIS initiator (QNI) that starts the QoS NSLP signaling adds an Initiator QSPEC object containing parameters that describe the desired QoS, normally based on the QOSM it supports ✨ QSPEC parameters flagged by the QNI must be interpreted by all QNEs on the path, or else the reservation fails 😭 QSPEC parameters not flagged by the QNI may be skipped if not understood 🫶 More QSPEC parameters can be defined by informational specification documents, which keeps QoS NSLP extensible and flexible 👑
A Local QSPEC can be defined within a local domain with the Initiator QSPEC encapsulated, and the Local QSPEC must be functionally consistent with the Initiator QSPEC in terms of defined source traffic and other constraints 🎀 In other words, a domain-specific local QSPEC can be defined and processed inside a local domain, which could, for example, enable simpler processing by QNEs within that domain 💜
Section 3.4 has an example of QSPEC processing, so peek at that if you want to see it in action 🧚
1.1. 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 RFC 2119 [RFC2119] 📚 Bestie, those are the official BCP 14 words, so read them as RFC 2119 defines them 🤓
2. Terminology ✨
okay so this is the glossary bit, and bestie, every term here is load-bearing 💅
- Initiator QSPEC: The Initiator QSPEC is included in a QoS NSLP message by the QNI/QNR. 🎀 It travels end-to-end to the QNR/QNI and is never removed. It's the OG one, lowkey iconic.
- Local QSPEC: A Local QSPEC is used in a local domain and is domain specific. 🏠 It encapsulates the Initiator QSPEC and is removed at the egress of the local domain.
- Minimum QoS: QSPEC object that, together with a description of QoS Desired or QoS Available, allows the QNI to specify a QoS range, i.e., an upper and lower bound. 📉 If the QoS Desired cannot be reserved, QNEs are going to decrease the reservation until the minimum QoS is hit. Note that the term "minimum" is used generically, since for some parameters, such as loss rate and latency, what is specified is the maximum acceptable value. 🙈 so "minimum" is kinda a vibe, not a literal rule
- QNE: QoS NSIS Entity, a node supporting QoS NSLP. ⭐
- QNI: QoS NSIS Initiator, a node initiating QoS NSLP signaling. 🚀
- QNR: QoS NSIS Receiver, a node terminating QoS NSLP signaling. 🧚
- QoS Available: QSPEC object containing parameters describing the available resources. They are used to collect information along a reservation path. 🛣️
- QoS Desired: QSPEC object containing parameters describing the desired QoS for which the sender requests reservation. 💖
- QoS Model (QOSM): a method to achieve QoS for a traffic flow, e.g., IntServ Controlled Load; specifies the subset of QSPEC QoS constraints and traffic handling directives that a QNE implementing that QOSM is capable of supporting and how resources will be managed by the RMF. 👑 this one is a whole mood
- QoS Reserved: QSPEC object containing parameters describing the reserved resources and related QoS parameters. 🦋
- QSPEC: the object of QoS NSLP that contains all QoS-specific information. 🌈
- QSPEC parameter: Any parameter appearing in a QSPEC; for example, traffic model (TMOD), path latency, and excess treatment parameters. 🍓
- QSPEC Object: Main building blocks containing a QSPEC parameter set that is the input or output of an RMF operation. 🧱
- QSPEC Type: Identifies a particular QOSM used in the QSPEC 🏷️
- Resource Management Function (RMF): Functions that are related to resource management and processing of QSPEC parameters. ⚙️
3. QSPEC Framework
okay the big picture is giving layers 🧁 The overall framework for the QoS NSLP is that [RFC5974] defines QoS signaling and semantics, the QSPEC template defines the container and semantics for QoS parameters and objects, and informational specifications define QoS methods and procedures for using QoS signaling and QSPEC parameters/objects within specific QoS deployments. QoS NSLP is a generic QoS signaling protocol that can signal for many QOSMs. ✨ one protocol, lots of outfits 👗
3.1. QoS Models
so a QOSM is basically a way to get QoS for a traffic flow 🦋, like IntServ Controlled Load [CL-QOSM], Resource Management with Diffserv [RFC5977], and QoS signaling for Y.1541 QoS classes [RFC5976]. A QOSM specifies a set of QSPEC parameters that describe the QoS desired and how resources will be managed by the RMF. The RMF implements functions that are related to resource management and processes the QSPEC parameters. 🛠️
QOSMs affect the operation of the RMF in NSIS-capable nodes and the information carried in QSPEC objects. Under some circumstances (e.g., aggregation), they may cause a separate NSLP session to be instantiated by having the RMF as a QNI. 🌸 QOSM specifications may define RMF triggers that cause the QoS NSLP to run semantics within the underlying QoS NSLP signaling state and messaging processing rules, as defined in Section 5.2 of [RFC5974]. New QoS NSLP message processing rules can only be defined in extensions to QoS NSLP. If a QOSM specification defines triggers that deviate from existing QoS NSLP processing rules, the fallback for QNEs not supporting that QOSM are the QoS NSLP state transition/message processing rules. 🙃 that fallback part is so important, don't skip it bestie
The QOSM specification includes how the requested QoS resources will be described and how they will be managed by the RMF. For this purpose, the QOSM specification defines a set of QSPEC parameters it uses to describe the desired QoS and resource control in the RMF, and it may define additional QSPEC parameters. 🎀
When a QoS NSLP message travels through different domains, it may encounter different QOSMs. Since QOSMs use different QSPEC parameters for describing resources, the QSPEC parameters included by the QNI may not be understood in other domains. The QNI therefore can flag those QSPEC parameters it considers vital with the M flag. QSPEC parameters with the M flag set must be interpreted by the downstream QNEs, or the reservation fails. 💀 no M flag, no mercy. QSPEC parameters without the M flag set should be interpreted by the downstream QNEs, but may be ignored if not understood. 🫶
A QOSM specification SHOULD include the following:
- role of QNEs, e.g., location, frequency, statefulness, etc.
- QSPEC definition including QSPEC parameters
- QSPEC procedures applicable to this QOSM
- QNE processing rules describing how QSPEC information is treated and interpreted in the RMF, e.g., admission control, scheduling, policy control, QoS parameter accumulation (e.g., delay)
- at least one bit-level QSPEC example
- QSPEC parameter behavior for new QSPEC parameters that the QOSM specification defines
- a definition of what happens in case of preemption if the default QNI behavior (teardown preempted reservation) is not followed (see Section 4.3.5)
A QOSM specification MAY include the following:
- definitions of additional QOSM-specific error codes, as discussed in Section 4.2.3
- the QoS-NSLP options a QOSM wants to use, when several options are available for a QOSM (e.g., Local QSPEC to either a) hide the Initiator QSPEC within a local domain message, or b) encapsulate the Initiator QSPEC). 🧩 the list is long but it's all good vibes
QOSMs are free, subject to IANA registration and review rules, to extend QSPECs by adding parameters of any of the kinds supported by the QSPEC. This includes traffic description parameters, constraint parameters, and traffic handling directives. QOSMs are not permitted, however, to reinterpret or redefine the QSPEC parameters specified in this document. 🚫 hard boundary, no cap. Note that signaling functionality is only defined by the QoS NSLP document [RFC5974] and not by this document or by QOSM specification documents. 🌈 signaling lives in [RFC5974] and nowhere else, periodt ✨
3.2. QSPEC Objects ✨
Okay bestie, so the QSPEC is the QoS NSLP object that holds all the QSPEC objects and parameters 💖. QSPEC objects are the main building blocks of the QSPEC parameter set, which is what goes into and comes out of an RMF operation 🧚. QSPEC parameters are the parameters showing up in a QSPEC, and a QSPEC must include the traffic model parameter (TMOD) 🎀. It may optionally include constraints (like path latency), traffic handling directives (like excess treatment), and traffic classifiers (like PHB class). The RMF handles the resource management stuff and processes all those QSPEC parameters, so it's the real MVP 👑.
A QSPEC is made of a QSPEC version number plus QSPEC objects 💅. IANA hands out a new QSPEC version number only when the current version gets deprecated or deleted (as a specification requires). A new version number is NOT needed just because new QSPEC parameters got specified 🙈. Later QSPEC versions MUST be backward compatible with earlier ones, meaning a version n+1 device must support version n (or earlier) 🫶. And if a version n (or earlier) device gets an NSLP message asking for version n+1, it replies with an 'Incompatible QSPEC' error code (0x0f), as discussed in Section 4.2.3. That lets the QNE that sent the message retry with a lower QSPEC version, which is honestly such a polite move 🌸.
This document gives you a template for the QSPEC so QOSMs can actually work together 🦋. Figure 1 shows the QSPEC being built from up to 4 QSPEC objects: QoS Desired, QoS Available, QoS Reserved, and Minimum QoS. Each one holds a bunch of QSPEC parameters. A QSPEC can contain only some of those objects, like just QoS Desired, which is super flexible ✨.
+---------------------------------------+
| QSPEC Objects |
+---------------------------------------+
\________________ ______________________/
V
+----------+----------+---------+-------+
|QoS Desir.|QoS Avail.|QoS Rsrv.|Min QoS|
+----------+----------+---------+-------+
\____ ____/\___ _____/\___ ____/\__ ___/
V V V V
+-------------+... +-------------+...
|QSPEC Para. 1| |QSPEC Para. n|
+-------------+... +-------------+...
Figure 1: Structure of the QSPECUsing the 4 QSPEC objects (QoS Desired, QoS Available, QoS Reserved, and Minimum QoS) is covered in Section 4.3, which walks through 3 message sequences and 7 object combinations 🍓. The four objects MUST all be supported by QNEs, and they MAY show up in any QSPEC object carried in any QoS NSLP message (RESERVE, QUERY, RESPONSE, NOTIFY). Check out [RFC5974] for what the QoS NSLP RESERVE, QUERY, RESPONSE, and NOTIFY messages actually do.
QoS Desired describes the resources the QNI wants to reserve, so it's a read-only object. The QSPEC parameters in it may NOT be overwritten 🔒. QoS Desired is always included in a RESERVE message and sometimes included in a QUERY message (see Section 4.3 for the details).
QoS Available is a bit of a diva. As Section 4.3 explains, it can travel in a RESERVE message, a RESPONSE Message, or a QUERY message, and it can collect info on the resources currently available along the path 🛤️. When it's in one of these, it's read-write, which means its QSPEC parameters can be updated but NOT deleted. So each QNE MUST inspect all parameters of this object, and if the resources available to that QNE are less than what a parameter says, the QNE MUST adapt that parameter to match 💀. By the time the message reaches its recipient, <QoS Available> reflects the bottleneck of what's available on the path. A QUERY can use this to gather the available resources along a data path, which is giving detective energy 🕵️♀️.
When QoS Available rides in a RESPONSE message, it's just carrying the result of an earlier measurement made by a RESERVE or QUERY message back to the initiator. So in that case it's read-only 🫠. There's one more exception, described in Section 4.3.2 (Case 3): the QNI sends QoS Available in a RESERVE message as a read-only QSPEC object (see Section 4.3.2 for the details).
The QoS Reserved object reflects the resources that are actually being reserved. It's read-only, and it's always included in a RESPONSE message if QoS Desired was included in the RESERVE message (see Section 4.3 for the details) 💜.
Minimum QoS has no equivalent in RSVP, so it's a genuinely new idea 🌈. It lets the QNI define a range of acceptable QoS levels by putting both the desired QoS value and the minimum acceptable QoS in the same message. Heads up: "minimum" is used loosely here, since for some parameters, like loss rate and latency, what you specify is actually the maximum acceptable value 🙃. It's read-only and may be included in a RESERVE, RESPONSE, or QUERY message (see Section 4.3). The desired QoS goes in a QoS Desired and/or a QoS Available object seeded to the desired value. The minimum acceptable QoS value MAY be coded in the Minimum QoS object. As the message travels toward the QNR, QNEs on the path update QoS Available. If its value drops below the Minimum QoS value, the reservation fails and gets aborted 😭. When this method is used, the QNR tells the QNI what QoS Available value it ended up with, since the reservation may need to be adapted to match (see Section 4.3 for the details).
Also, the relationship between QSPEC objects and RSVP objects is covered in Appendix A 🎀.
3.3. QSPEC Parameters ✨
QSPEC parameters give everyone a common language for building QSPEC objects 🗣️. This document defines a bunch of them, but separate QOSM specification documents can define more. For example, QSPEC parameters are defined in [RFC5976] and [RFC5977] 🍭.
One QSPEC parameter, <TMOD>, is extra special 🌟. It describes the traffic the resources are reserved for. The QNI must include this parameter, and ALL QNEs must interpret it. Every other QSPEC parameter gets filled in by a QNI only if it's relevant to the QoS desired. For those, the QNI sets the M flag if downstream QNEs must interpret them. If QNEs can't interpret a parameter, the reservation fails 💔. QSPEC parameters that the QNI fills in without the M flag set should be interpreted by downstream QNEs, but they may be ignored if they're not understood.
In this document, "interpret" means that, when the RMF processes QSPEC parameters, it handles each one following the commonly accepted normative procedures from the references given for that parameter 📚. A QNE only needs to interpret a QSPEC parameter if the QNI actually populated it in the QSPEC. If it's not populated, the QNE obviously doesn't interpret it 🙄.
Now for the local domain drama 🏠. When an ingress QNE in a local domain defines a Local QSPEC and encapsulates the Initiator QSPEC, the QNEs in the interior of that local domain only need to process the Local QSPEC and can ignore the encapsulated Initiator QSPEC. But edge QNEs in the local domain DO need to interpret the QSPEC parameters populated in the Initiator QSPEC with the M flag set, and they should interpret the ones populated without the M flag set 🧚.
As we covered in the previous section, QoS parameters may get overwritten depending on which QSPEC object and which message they show up in 🔁.
3.3.1. Traffic Model Parameter ✨
okay so the <Traffic Model> (TMOD) parameter is the one the QNI has to include in the Initiator QSPEC, and every downstream QNE has to be able to read it 💅 it's mandatory, no cap. TMOD is basically a container for 5 sub-parameters [RFC2212]:
- rate (r) specified in octets per second
- bucket size (b) specified in octets
- peak rate (p) specified in octets per second
- minimum policed unit (m) specified in octets
- maximum packet size (MPS) specified in octets
TMOD is giving token bucket vibes 🪣 with a rate (r) and a bucket size (b), plus a peak rate (p), minimum policed unit (m), and maximum packet size (MPS) on top 🎀
Both b and r MUST be positive 🫶 The rate r is measured in octets of IP packets per second, and it can go all the way from 1 octet per second up to 40 teraoctets per second 🔥 The bucket depth b is also in octets and can be anywhere from 1 octet up to 250 gigaoctets. The peak rate p is measured in octets of IP packets per second too, and it has the same range and suggested representation as the bucket rate 🦋
The peak rate is the maximum speed the source (and any reshaping, which we'll get to) is allowed to blast bursts of traffic into the network 💥 To be precise, the amount of data sent over any time period can't go over MPS+pT, where MPS is the maximum packet size and T is the length of the time period 🧚 And p MUST be greater than or equal to the token bucket rate, r 💜 If the peak rate is unknown or unspecified, then p MUST be set to infinity ♾️
The minimum policed unit, m, is an integer measured in octets 🌸 When policing and checking conformance to the TMOD, every IP packet smaller than m gets counted as being exactly size m. The maximum packet size, MPS, is the biggest packet that still conforms to the traffic spec, also measured in octets. The flow MUST be rejected if the requested maximum packet size is bigger than the MTU of the link 🚫 Both m and MPS MUST be positive, and m MUST be less than or equal to MPS 🍓
Policing checks arriving traffic against the TMOD parameters at the edge of the network, so the traffic stays in line with the token bucket 👀 Reshaping tries to restore traffic's (possibly distorted) shape so it conforms to the TMOD parameters again. And traffic that breaks the TMOD gets caught because the reshaping fails and the reshaping buffer overflows 😭
The token bucket and peak rate parameters mean traffic MUST obey this rule: over all time periods, the amount of data sent can't exceed MPS+min[pT, rT+b-MPS], where r and b are the token bucket parameters, MPS is the maximum packet size, and T is the length of the time period. (Note that when p is infinite, this just reduces to the standard token bucket requirement 🙈) For this accounting, links MUST count packets smaller than the minimum policing unit as being of size m. Packets that show up at an element and cause a violation of the MPS + min[pT, rT+b-MPS] bound are considered non-conformant 🚨
All 5 of the sub-parameters MUST be included in the TMOD parameter 💅 The TMOD parameter can be set to describe the traffic source. For example, if TMOD is set to specify bandwidth only, then set r = peak rate = p, b = large, and m = large. Another example: if TMOD is set for TCP traffic, then set r = average rate, b = large, and p = large 🧁
When the 5 TMOD sub-parameters are included in QoS Available, they tell you stuff like what TMOD resources are available along the path a data flow takes 🗺️ The value of TMOD at a QNE is an estimate of the TMOD resources that QNE has for packets heading along the path up to the next QNE, including its outgoing link (if that link exists). The QNI MUST account for the resources of the ingress link, if that link exists 🫶 Working out this value SHOULD take into account all the information the QNE has about the path, including administrative and policy controls, as well as physical resources 🧠
The output composed value is the minimum of the QNE's value and the input composed value for r, b, p, and MPS, and the maximum of the QNE's value and the input composed value for m. When this gets composed end-to-end, the QNR (or the QNI, in a RESPONSE message) learns the minimal TMOD resources along the path from QNI to QNR 👑
Two TMOD parameters are defined in Section 5, <TMOD-1> and <TMOD-2>. The second one (<TMOD-2>) is there for some Diffserv applications 💖 For example, Diffserv Expedited Forwarding (EF) traffic is usually assumed to be shaped at the ingress by a single rate token bucket, so one TMOD parameter is enough to signal EF traffic ✨ Diffserv Assured Forwarding (AF) traffic is different, though. It needs two sets of token bucket parameters: one for the average traffic and one for the burst traffic 🌈
[RFC2697] defines a Single Rate Three Color Marker (srTCM). It meters a traffic stream and marks each packet as green, yellow, or red based on three traffic parameters: Committed Information Rate (CIR), Committed Burst Size (CBS), and Excess Burst Size (EBS). A packet is marked green if it doesn't exceed the CBS, yellow if it does exceed the CBS but not the EBS, and red otherwise 🚦 [RFC2697] spells out specific procedures that use two token buckets running at the same rate. So 2 TMOD parameters are enough to tell apart 3 levels of drop precedence 🎯 There's also an example of this in the Appendix to [RFC2597] 📚
3.3.2. Constraints Parameters 🎀
okay so <Path Latency>, <Path Jitter>, <Path PLR>, and <Path PER> are QSPEC parameters for the desired path latency, path jitter, packet loss ratio, and path packet error ratio. These are all cumulative, which means a single QNE can't decide whether the desired path latency (or whatever) is actually available, so it can't decide whether a reservation fails by itself 😭 Instead, when these parameters show up in <Desired QoS>, the QNI SHOULD also include the matching parameters in a QoS Available QSPEC object, so the info gets collected 🫶
The <Path Latency> parameter adds up the latency of the packet forwarding process at each QNE. Latency here means the mean packet delay, measured in microseconds, that each QNE adds. That delay comes from link propagation delay, packet processing, and queuing 🕰️ Each QNE MUST add the propagation delay of its outgoing link, if that link exists 💅 The QNI SHOULD also add the propagation delay of the ingress link, if that link exists. The composition rule for <Path Latency> is summation, clamped at (2^32) - 1 as the maximum value 🔢 When composed end-to-end, the QNR (or the QNI, in a RESPONSE message) learns the minimal packet delay along the path from QNI to QNR. The whole point is to give a minimum path latency for services that estimate or bound the extra path delay [RFC2212] 🧚
The <Path Jitter> parameter adds up the jitter of the packet forwarding process at each QNE. Jitter here is the nominal jitter, measured in microseconds, that each QNE adds 🌊 IP packet jitter (aka delay variation) is defined in [RFC3393], Section 3.4 (Type-P-One-way-ipdv). The [RFC3393] selection function includes the packet with minimum delay, so the distribution matches 2-point delay variation in [Y.1540]. The suggested evaluation interval is 1 minute ⏱️ This jitter comes from packet-processing limits and includes any variable queuing delay that might be there. Each QNE MUST add the jitter of its outgoing link, if that link exists. The QNI SHOULD also add the jitter of the ingress link, if that link exists 💖 The composition method for <Path Jitter> is a combination of several statistics describing the delay variation distribution, with a clamp on the maximum value. (Quick note: the way nominal QNE jitter gets accumulated and estimated is specified in clause 8 of [Y.1541] 🤓) When composed end-to-end, the QNR (or the QNI, in a RESPONSE message) learns the nominal packet jitter along the path from QNI to QNR. Its purpose is to give a nominal path jitter for services that estimate or bound the extra path delay [RFC2212] 🦋
The <Path PLR> parameter is the unit-less ratio of total lost IP packets to total transmitted IP packets 📉 It adds up the packet loss ratio (PLR) of the forwarding process at each QNE, where each QNE's PLR is the PLR it adds. Each QNE MUST add the PLR of its outgoing link, if that link exists. The QNI MUST add the PLR of the ingress link, if that link exists 🫶 The composition rule for <Path PLR> is summation with a clamp on the maximum value. (This assumes the PLR values are low enough that the summation error doesn't matter. A more accurate composition function is in clause 8 of [Y.1541] 🧠) When composed end-to-end, the QNR (or the QNI, in a RESPONSE message) learns the minimal packet PLR along the path from QNI to QNR 💅
Packet error ratio [Y.1540, Y.1541] is the unit-less ratio of total errored IP packet outcomes to the total of successful IP packet transfer outcomes plus errored IP packet outcomes in a population of interest. It has a resolution of at least 10^-9 🔬 If a value has lesser resolution, the unused digits MUST be set to zero 🍓 The number of errored packets you observe is directly tied to how confident you can be in the result 🤓 The <Path PER> parameter adds up the packet error ratio (PER) of the forwarding process at each QNE, where each QNE's PER is the PER it adds. Each QNE MUST add the PER of its outgoing link, if that link exists. The QNI SHOULD also add the PER of the ingress link, if that link exists 💜 The composition rule for <Path PER> is summation with a clamp on the maximum value. (Again, this assumes the PER values are low enough that summation error isn't significant, and a more accurate composition function is specified in clause 8 of [Y.1541] 🙈) When composed end-to-end, the QNR (or the QNI, in a RESPONSE message) learns the minimal packet PER along the path from QNI to QNR ✨
The slack term parameter is the difference between the desired delay and the delay you get from using bandwidth reservation, and it's used to reduce the resource reservation for a flow [RFC2212] 🫧
3.3.3. Traffic-Handling Directives ✨
okay bestie, so an application MAY like to reserve resources for packets AND pick a specific traffic-handling behavior, like <Excess Treatment> 🎀. Also, as we covered in Section 3.1, an application MAY like to define RMF triggers that make the QoS NSLP run semantics inside the underlying QoS NSLP signaling state / messaging processing rules, as defined in Section 5.2 of [RFC5974] 🦋. ngl, new QoS NSLP message processing rules can only be defined in extensions to the QoS NSLP, so no freelancing 💅. Just like constraints parameters and other QSPEC parameters, Traffic Handling Directives parameters can be defined in QOSM specifications for QOSM-specific resource management stuff 🧚. Some of these are already defined in [RFC5976], [RFC5977], and [CL-QOSM]. Generally, a Traffic Handling Directives parameter is expected to be set by the QNI in <QoS Desired>, and NOT included in <QoS Available>. If one shows up in <QoS Available>, QNEs may change its value 👀.
The <Preemption Priority> parameter is the priority of the new flow, and it gets compared with the <Defending Priority> of flows that are already admitted 👑. Once a flow is admitted, its preemption priority becomes irrelevant (it's giving "mission accomplished" 🌸). The <Defending Priority> parameter is what gets compared against the preemption priority of new flows. For any specific flow, its preemption priority MUST always be less than or equal to the defending priority. <Admission Priority> and <RPH Priority> are an essential way to differentiate flows for emergency services, Emergency Telecommunications Service (ETS), E911, etc. They get a higher admission priority than normal priority flows and best-effort priority flows 🚨💖.
The <Excess Treatment> parameter describes how the QNE will process out-of-profile traffic. Excess traffic MAY be dropped, shaped, and/or re-marked 🍓.
3.3.4. Traffic Classifiers
okay so an application MAY like to reserve resources for packets with a particular Diffserv per-hop behavior (PHB) [RFC2475] 🌈. Note that PHB class is normally set by a downstream QNE to tell the QNI how to mark traffic so it gets the treatment that admission control designated. Setting the parameter from the QNI side is not precluded though, so it's not a hard no 🙈. An application MAY also like to reserve resources for packets with a particular QoS class, e.g., Y.1541 QoS class [Y.1541] or Diffserv-aware MPLS traffic engineering (DSTE) class type [RFC3564, RFC4124] ✨. These parameters are useful in various QOSMs, e.g., [RFC5976], [RFC5977], and other QOSMs that are yet to be defined (e.g., DSTE-QOSM). This section is meant to give QOSMs guidelines on how to encode these parameters. The PHB class parameter gets illustrated in the example in the following section 🎀.
3.4. Example of QSPEC Processing
This section shows how the QSPEC operates and gets used inside the NSLP 🧚. The example configuration is shown in Figure 2 🗺️.
+----------+ /-------\ /--------\ /--------\
| Laptop | | Home | | Cable | | Diffserv |
| Computer |-----| Network |-----| Network |-----| Network |----+
+----------+ | No QOSM | |DQOS QOSM | | RMD QOSM | |
\-------/ \--------/ \--------/ |
|
+-----------------------------------------------+
|
| /--------\ +----------+
| | XG | | Handheld |
+---| Wireless |-----| Device |
| XG QOSM | +----------+
\--------/Figure 2: Example Configuration of QoS-NSLP/QSPEC Operation
In this setup, a laptop and a handheld wireless device are the endpoints for some app that has QoS requirements 💻📱. Let's assume both endpoints stay still during the session for now, and we'll get to mobile endpoints later 🫶.
For this session, the laptop is connected to a home network with no QoS support. That home network hooks into a CableLabs-type cable access network with dynamic QoS (DQOS) support, like the one specified in [DQOS] for cable access networks. That network connects to a Diffserv core network that uses the Resource Management in Diffserv QoS Model [RFC5977]. On the other side of the Diffserv core is a wireless access network built on generation "X" technology, with QoS support as defined by generation "X". And finally, the handheld endpoint connects to that wireless access network 📶.
We're assuming the laptop is the QNI and the handheld is the QNR 💖. The QNI signals an Initiator QSPEC object to get the QoS it wants on the path.
The QNI sets QoS Desired, QoS Available, and possibly Minimum QoS QSPEC objects in the Initiator QSPEC, and it initializes QoS Available to QoS Desired 🪄. Each QNE on the path reads and interprets those parameters in the Initiator QSPEC and checks whether QoS Available resources can be reserved. If not, the QNE reduces the respective parameter values in QoS Available and reserves those values. The minimum parameter values are given in Minimum QoS, if it's populated. If it isn't, they're zero 🤏. If one or more parameters in QoS Available fails to satisfy the corresponding minimum values in Minimum QoS, the QNE generates a RESPONSE message to the QNI and the reservation is aborted 💀. Otherwise, the QNR generates a RESPONSE to the QNI with the QoS Available for the reservation ✅. If a QNE can't reserve QoS Desired resources, the reservation fails 😭.
The QNI fills in QSPEC parameters so its traffic gets treated correctly in the domains down the path 🛤️. Let's say the QNI wants QoS guarantees similar to the IntServ Controlled Load service, and it's also curious what path latency it can get. To make sure things get treated right further down the path, the QNI puts <PHB Class> in <QoS Desired>. So the QNI includes this in the QSPEC:
QoS Desired = <TMOD> <PHB Class>
QoS Available = <TMOD> <Path Latency>Since <Path Latency> and <PHB Class> aren't vital from the QNI's perspective, it doesn't raise their M flags 🙃.
There are three possibilities when a RESERVE message shows up at a QNE on a domain border. The example describes them:
- the QNE just leaves the QSPEC as is.
- the QNE can add a Local QSPEC and encapsulate the Initiator QSPEC (see the discussion in Section 4.1; this is new in QoS NSLP, RSVP doesn't do this 🆕).
- the QNE can 'hide' the initiator RESERVE message, so only the edge QNE processes it. That edge QNE then bypasses the intermediate nodes between the domain edges and issues its own local RESERVE message (see Section 3.3.1 of [RFC5974]). For this new local RESERVE message, the QNE acts as the QNI, and the QSPEC in the domain is an Initiator QSPEC. RSVP does something similar when it makes aggregate reservations. In that case there isn't a new intra-domain (aggregate) RESERVE for each newly arriving inter-domain (per-flow) RESERVE. The aggregate reservation just gets updated by the border QNE (or QNI) as needed. This is also how RMD works [RFC5977] 🧠.
For example, at the RMD domain, a local RESERVE with its own RMD Initiator QSPEC for the RMD-QOSM gets generated from the original Initiator QSPEC, following the procedures in Section 4.5 of [RFC5974] and in [RFC5977] 🌸. The ingress QNE to the RMD domain maps the TMOD parameters in the original Initiator QSPEC to the equivalent TMOD parameter that only represents the peak bandwidth in the Local QSPEC. The local RMD QSPEC also needs <PHB Class>, which in this case was provided by the QNI 🎀.
Also, if the node can update QoS Available at the egress to the RMD domain, it does so on behalf of the entire RMD domain. If it can't (because the M flag isn't set for <Path Latency>), it raises the parameter-specific, Not Supported N flag. That's a warning to the QNR that the final latency value in QoS Available is imprecise ⚠️.
In the XG domain, the Initiator QSPEC is translated into a local QSPEC using a similar procedure to the one described above. The Local QSPEC becomes the current QSPEC used within the XG domain, and the Initiator QSPEC gets encapsulated. This saves the QNEs inside the XG domain from re-translating the Initiator QSPEC, and it simplifies processing in the local domain 🙌. At the egress edge of the XG domain, the translated Local QSPEC gets removed, and the Initiator QSPEC goes back to the number one position 🔄.
If the reservation succeeds, the RESERVE request eventually arrives at the QNR. (If it fails, the QNE where it failed aborts the RESERVE and sends an error RESPONSE back to the QNI 😬.) If the RII was included in the QoS NSLP message, the QNR generates a positive RESPONSE with the QSPEC objects QoS Reserved and QoS Available. The parameters in QoS Reserved are the same as in QoS Desired, with values copied from QoS Available. So the QNR includes these QSPEC objects in the RESPONSE:
QoS Reserved = <TMOD> <PHB Class>
QoS Available = <TMOD> <Path Latency>Now, if the handheld on the right of Figure 2 is mobile and moves through different XG wireless networks, the QoS might change along the path, since different XG wireless networks might support different QOSMs 🚶♀️. That means QoS NSLP/QSPEC processing has to renegotiate the QoS Available on the path. From the QSPEC's point of view, this is like a new reservation on the new section of the path. It's basically the same as any other rerouting event, since to the QNEs on the new path, it looks like a new reservation 🛣️. In this mobile scenario, the new segment might support a different QOSM than the old one. So the QNI would now signal a new reservation explicitly (or implicitly, with the next refreshing RESERVE message) to account for the different QOSM in the XG wireless domain. More details on rerouting are in [RFC5974] 🔁.
For bit-level examples of QSPECs, check out the documents that specify QOSMs: [CL-QOSM], [RFC5976], and [RFC5977] 🔍.
4. QSPEC Processing and Procedures ✨
Three flags are used in QSPEC processing: the M flag, the E flag, and the N flag. They're explained in this section 🏳️. The QNI sets the M flag for each QSPEC parameter it populates that MUST be interpreted by downstream QNEs. If a QNE doesn't support the parameter, it sets the N flag and fails the reservation 💔. If the QNE supports the parameter but can't meet the resources the parameter requests, it sets the E flag and fails the reservation 🚫.
If the M flag isn't set, the downstream QNE SHOULD interpret the parameter. If the QNE doesn't support the parameter, it sets the N flag and forwards the reservation 📨. If the QNE supports the parameter but can't meet the resources the parameter requests, it sets the E flag and fails the reservation 🥲.
4.1. Local QSPEC Definition and Processing ✨
Okay bestie, so a QNE sitting at the edge of a local domain has two moves 💅 Option a) is to translate the Initiator QSPEC into a Local QSPEC and encapsulate the Initiator QSPEC inside the RESERVE message. Option b) is to 'hide' the Initiator QSPEC from the local domain and reserve resources by generating a brand new RESERVE message through that domain, carrying the Local QSPEC. Either way, the Initiator QSPEC parameters get interpreted right at the local domain edges 🎀
A Local QSPEC can give you a simpler control plane inside the local domain 🦋 The edge nodes still have to interpret the Initiator QSPEC parameters. Then they can either start a parallel session with a Local QSPEC, or define a Local QSPEC and encapsulate the Initiator QSPEC, as shown in Figure 3. The Initiator/Local QSPEC bit tells you whether a QSPEC is an Initiator QSPEC or a Local QSPEC. The QSPEC Type shows, for example, that the initiator of the local QSPEC uses a certain QOSM, like CL-QSPEC Type. It can be really useful for the QNI to signal a QSPEC Type based on some QOSM 🌸 That does mean populating certain QOSM-related parameters, but it lets a downstream QNE pick from whatever QOSM-related processes it has. So the QNI fills in the QSPEC Type (say, CL-QSPEC Type) and sets the Initiator/Local QSPEC bit to 'Initiator'. A local QNE can decide, for whatever reasons, to insert a Local QSPEC Type, like RMD-QSPEC Type. It sets the local QSPEC Type to RMD-QSPEC, sets the Initiator/Local QSPEC bit to 'Local', and encapsulates the Initiator QSPEC in the RESERVE or whatever NSLP message it's using 🧚
+--------------------------------+\
| QSPEC Type, QSPEC Procedure | \
+--------------------------------+ / Common QSPEC Header
| Init./Local QSPEC bit=Local |/
+================================+\
| Local-QSPEC Parameter 1 | \
+--------------------------------+ \
| .... | Local-QSPEC Parameters
+--------------------------------+ /
| Local-QSPEC Parameter n | /
+--------------------------------+/
| +----------------------------+ |
| | QSPEC Type, QSPEC Procedure| |
| +----------------------------+ |
| | Init./Local QSPEC bit=Init.| |
| +============================+ |
| | | | Encapsulated Initiator QSPEC
| | .... | |
| +----------------------------+ |
+--------------------------------+
Figure 3: Defining a Local QSPECHere's the vibe: the QoS-NSLP only sees and passes one QSPEC up to the RMF 👑 So the QSPEC type is allowed to change within a local domain. Here's how the roles split up:
- the QNI signals its QoS requirements with the Initiator QSPEC,
- the ingress edge QNE in the local domain translates the Initiator QSPEC parameters into equivalent parameters in the local QSPEC,
- the QNEs in the local domain only interpret the Local QSPEC parameters, and
- the egress QNE in the local domain processes the Local QSPEC and also interprets the QSPEC parameters in the Initiator QSPEC.
Now the big rule 😤 The Local QSPEC MUST be consistent with the Initiator QSPEC. Basically, it MUST NOT specify a lower level of resources than the Initiator QSPEC does. For example, in RMD the TMOD parameters in the original Initiator QSPEC get mapped to the equivalent TMOD parameter that only represents the peak bandwidth in the Local QSPEC. Keep it honest, no cap 💖
Also, it's possible to use both approaches: hiding a QSPEC through a local domain by starting a new RESERVE at the domain edge, and defining a Local QSPEC and encapsulating the Initiator QSPEC. However, it is not expected that both the hiding and encapsulating functions would be used at the same time for the same flow 🙈
Figure 4 shows the support of Local QSPECs for a single flow, so you can see exactly where the Initiator and Local QSPECs get used. The QNI starts an end-to-end, inter-domain QoS NSLP RESERVE message that carries the Initiator QSPEC for the Y.1541 QOSM. As the diagram shows, the RESERVE message crosses multiple domains that support different QOSMs. In this example, the Initiator QSPEC shows up in a QoS NSLP RESERVE message at the ingress node of the local-QOSM domain. At the ingress edge node, that end-to-end, inter-domain QoS-NSLP message triggers the creation of a Local QSPEC, and the Initiator QSPEC gets encapsulated inside the messages signaled through the local domain. The Local QSPEC handles QoS processing inside the local-QOSM domain, and the Initiator QSPEC handles QoS processing outside it 🦋
In this example, the QNI sets the <QoS Desired>, <Minimum QoS>, and <QoS Available> objects to include objectives for the <Path Latency>, <Path Jitter>, and <Path PER> parameters. The QNE or local domain fills in the cumulative parameters (like <Path Latency>) that can be achieved in the <QoS Available> object, but never less than what <Minimum QoS> asks for. If <QoS Available> fails to satisfy one or more of the <Minimum QoS> objectives, the QNE or local domain notifies the QNI, and the reservation is aborted 😭 If any QNE can't meet the requirements the Initiator QSPEC sets for a QSPEC parameter with the M bit set to zero, that QNE sets the N flag for that parameter to one. Otherwise, the QNR tells the QNI what <QoS Available> is for the reservation ✨
|------| |------| |------| |------|
| 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 4: Example of Initiator and Local Domain QOSM Operation4.2. Reservation Success/Failure, QSPEC Error Codes, and INFO-SPEC Notification 🌈
A reservation can go sideways for a few reasons 💀 It may fail because the resources it wants aren't available. That's a reservation failure condition.
- a reservation may fail because the desired resources are not available. This is a reservation failure condition.
- a reservation may fail because the QSPEC is erroneous or because of a QNE fault. This is an error condition.
A reservation may still be successful even when some parameters can't be interpreted or updated properly 🫶
- a QSPEC parameter cannot be interpreted because it is an unknown QSPEC parameter type. This is a QSPEC parameter not supported condition. However, the reservation does not fail. The QNI can still decide whether to keep or tear down the reservation, depending on the procedures specified by the QNI's QOSM.
The next sections cover what happens with unsuccessful reservations, and reservations where some parameters couldn't be met, like this:
- details on flags used inside the QSPEC to convey information on success or failure of individual parameters. The formats and semantics of all flags are given in Section 5.
- the content of the INFO-SPEC [RFC5974], which carries a code indicating the outcome of reservations.
- the generation of a RESPONSE message to the QNI containing both QSPEC and INFO-SPEC objects.
Also, when there are routers along the path between the QNI and QNR where QoS can't be provided, the QoS-NSLP generic flag BREAK (B) gets set 🚨 You can read more about the BREAK flag in Section 3.3.5 of [RFC5974].
4.2.1. Reservation Failure and Error E Flag 💅
Every QSPEC parameter has its own 'reservation failure error E flag', which shows which parameters (if any) couldn't be satisfied. When a resource can't be satisfied for a particular parameter, the QNE that spots the problem raises the E flag in that parameter. The TMOD parameter and all QSPEC parameters with the M flag set MUST be examined by the RMF. All QSPEC parameters with the M flag not set SHOULD be examined by the RMF, with the E flag set to show whether the parameter could or couldn't be satisfied. On top of that, the E flag in the corresponding QSPEC object MUST be raised when a resource can't be satisfied for that parameter. If the reservation failure can't be pinned down to a single parameter, only the E flag in the QSPEC object gets raised 🙈
When an RMF can't interpret the QSPEC because the coding is erroneous, it raises the matching reservation failure E flags in the QSPEC. Normally, all QSPEC parameters MUST be examined by the RMF, and the erroneous ones get flagged properly. Sometimes, though, an error condition pops up and the E flag of the error-causing QSPEC parameter gets raised (if possible), but processing of the remaining parameters might get aborted 😭
Here's the catch: if the QSPEC and/or any QSPEC parameter is found to be erroneous, then any QSPEC parameters that weren't satisfied get ignored, and the E Flags in the QSPEC object MUST NOT be set for those parameters (unless they're erroneous themselves) 💀
Whether E flags mean reservation failure or error can be figured out from the matching error code in the INFO-SPEC in QoS NSLP, as discussed below 🔥
4.2.2. QSPEC Parameter Not Supported N Flag 🦋
Each QSPEC parameter has an associated 'Not Supported N flag'. If that flag is set, then at least one QNE along the data transmission path between the QNI and QNR can't interpret the specified QSPEC parameter. A QNE MUST set the Not Supported N flag if it can't interpret the QSPEC parameter. If the M flag for the parameter isn't set, the message should continue to be forwarded but with the N flag set, and the QNI gets to choose whether to tear down the reservation 🌸
If a QNE in the path doesn't support a QSPEC parameter, like <Path Latency>, and sets the N flag, then downstream QNEs that do support the parameter SHOULD still update it, even with the N flag set. The catch is that the N flag means the cumulative value only gives a bound, and the QNI/QNR decides whether or not to accept the reservation with the N flag set 🫶
4.2.3. INFO-SPEC Coding of Reservation Outcome 💖
Okay so, as [RFC5974] says, the RESPONSE message always has an INFO-SPEC with an appropriate 'error' code 🫶. It usually also has a QSPEC with QSPEC objects too, which we unpack in Section 4.3 ("QSPEC Procedures") ✨. The RESPONSE message MAY omit the QSPEC in case of a successful reservation, so no stress if it's missing 🌸
Here are the guidelines for setting the error codes in the INFO-SPEC. They're based on the codes in Section 5.1.3.6 of [RFC5974] 🧚
- NSLP error class 2 (Success) /
0x01(Reservation Success) 🎀: This code is set when all QSPEC parameters have been satisfied. In this case, no E Flag is set, but one or more N flags may be set. Main character success ✨ - NSLP error class 4 (Transient Failure) /
0x07(Reservation Failure) 💀: This code is set when at least one QSPEC parameter couldn't be satisfied, or when a QSPEC parameter with M flag set couldn't be interpreted. E flags are set for the parameters that couldn't be satisfied at each QNE, up to the QNE that issued the RESPONSE message. The N flag is set for the parameters that at least one QNE couldn't interpret. Lowkey the most dramatic one. QNEs receiving the RESPONSE message MUST remove the corresponding reservation, no exceptions 😭 - NSLP error class 3 (Protocol Error) /
0x0c(Malformed QSPEC) 🙈: Some QSPEC parameters had associated errors. E Flags are set for the parameters that had errors, and the QNE where the error was found rejects the reservation. Yikes, not it 💅 - NSLP error class 3 (Protocol Error) /
0x0f(Incompatible QSPEC) 🌈: A higher version QSPEC got signaled and the QNE doesn't support it. Version drama, iykyk 💜 - NSLP error class 6 (QoS Model Error) 👑: QOSM error codes can be defined by QOSM specification documents. There's a registry for them in Section 7, IANA Considerations 📋
4.2.4. QNE Generation of a RESPONSE Message 🦋
- Successful Reservation Condition 🌟
When a RESERVE message arrives at a QNR and no E Flag is set, the reservation is successful. A RESPONSE message may be generated with INFO-SPEC code 'Reservation Success' as described above and in Section 4.3 ("QSPEC Procedures"). Slay, everything went right 🎀
- Reservation Failure Condition 🥀
When a QNE detects that a reservation failure occurs for at least one parameter, it sets the E Flags for the QSPEC parameters and QSPEC object that failed to be satisfied. According to [RFC5974], QNE behavior depends on whether it's stateful or not. When a stateful QNE determines the reservation failed, it formulates a RESPONSE message that includes an INFO-SPEC with the 'reservation failure' error code and QSPEC object. The QSPEC in the RESPONSE message includes the failed QSPEC parameters marked with the E Flag, so everyone can clearly see who messed up 🙈
The default action for a stateless QoS NSLP QNE that detects a reservation failure condition is that it MUST continue to forward the RESERVE message to the next stateful QNE, with the E Flags appropriately set for each QSPEC parameter. The next stateful QNE then formulates the RESPONSE message as described above. Passing the tea along the chain 🍓
- Malformed QSPEC Error Condition 💀
When a stateful QNE detects that one or more QSPEC parameters are erroneous, the QNE sets the error code 'malformed QSPEC' in the INFO-SPEC. In this case, the QSPEC object, with the E Flags appropriately set for the erroneous parameters, is returned within the INFO-SPEC object. The QSPEC object can be truncated or fully included within the INFO-SPEC. Options, bestie 🫶
According to [RFC5974], QNE behavior depends on whether it's stateful or not. When a stateful QNE determines a malformed QSPEC error condition, it formulates a RESPONSE message that includes an INFO-SPEC with the 'malformed QSPEC' error code and QSPEC object.
The QSPEC in the RESPONSE message includes, if possible, only the erroneous QSPEC parameters and no others. The erroneous QSPEC parameter(s) are marked with the E Flag to clearly identify them. If QSPEC parameters are returned in the INFO-SPEC that aren't marked with the E flag, then any values of those parameters are irrelevant and MUST be ignored by the QNI. Don't even look at them, periodt 💅
The default action for a stateless QoS NSLP QNE that detects a malformed QSPEC error condition is that it MUST continue to forward the RESERVE message to the next stateful QNE, with the E Flags appropriately set for each QSPEC parameter. The next stateful QNE will then act as described in [RFC5974] ✨
A 'malformed QSPEC' error code takes precedence over the 'reservation failure' error code. So the case of reservation failure and QSPEC/RMF error conditions are disjoint, and the same E Flag can be used in both cases without ambiguity. No mix-ups, we love a clean separation 🌸
4.2.5. Special Case of Local QSPEC 🏡
When an unsuccessful reservation problem occurs inside a local domain where a Local QSPEC is used, only the topmost (local) QSPEC is affected. For example, E flags get raised and stuff. The encapsulated Initiator QSPEC is untouched 🧸 However, when the message (RESPONSE in case of stateful QNEs, RESERVE in case of stateless QNEs) reaches the edge of the local domain, the Local QSPEC gets removed. The edge QNE must update the Initiator QSPEC on behalf of the entire domain, reflecting the information received in the Local QSPEC. This update covers both parameter values and flags. Note that some intelligence is needed to map the E flags and so on from the local QSPEC to the Initiator QSPEC. Even if the parameters in the local and Initiator QSPECs don't match directly, E flags could still be raised in the latter. Big brain energy 🧠✨
4.3. QSPEC Procedures 🎀
While the QSPEC template aims to put minimal restrictions on how QSPEC objects get used, interoperability between QNEs and between QOSMs must be ensured. So we give an exhaustive list of QSPEC object combinations for the message sequences described in QoS NSLP [RFC5974]. A specific QOSM may prescribe that only a subset of the procedures below may be used 💅
Note that QoS NSLP doesn't mandate using a RESPONSE message. A positive RESPONSE message is only generated if the QNE includes an RII (Request Identification Information) in the RESERVE message. A negative RESPONSE message is always generated in case of an error or failure. Some of the QSPEC procedures below only make sense when a RESPONSE message is possible. In these cases the QNI SHOULD include an RII 🫶
4.3.1. Two-Way Transactions 🦋
Here, the QNI issues a RESERVE message, which may be replied to by a RESPONSE message. There are 3 cases for QSPEC object usage:
MESSAGE | OBJECT | OBJECTS INCLUDED | OBJECTS INCLUDED
SEQUENCE | COMBINATION | IN RESERVE MESSAGE | IN RESPONSE MESSAGE
-----------------------------------------------------------------
0 | 0 | QoS Desired | QoS Reserved
| | |
0 | 1 | QoS Desired | QoS Reserved
| | QoS Available | QoS Available
| | |
0 | 2 | QoS Desired | QoS Reserved
| | QoS Available | QoS Available
| | Minimum QoS |
Table 1: Message Sequence 0: Two-Way Transactions
Defining Object Combinations 0, 1, and 2Case 1:
If only QoS Desired is included in the RESERVE message, the implicit assumption is that exactly these resources must be reserved. If that isn't possible, the reservation fails. The parameters in QoS Reserved are copied from the parameters in QoS Desired. If the reservation succeeds, the RESPONSE message can be omitted. If a QNE on the path requested a RESPONSE message, the QSPEC in the RESPONSE message can be omitted too 🌷
Case 2:
When QoS Available is also included in the RESERVE message, some parameters will appear only in QoS Available and not in QoS Desired. The value of these parameters is collected for informational purposes only, like path latency 📊
Some parameters in QoS Available can be the same as in QoS Desired. For these, the implicit message is that the QNI would be satisfied by a reservation with lower parameter values than those specified in QoS Desired. For these parameters, the QNI seeds the parameter values in QoS Available to those in QoS Desired (except for cumulative parameters such as <Path Latency>) 🌊
Each QNE interprets the parameters in QoS Available according to its current capabilities. Reservations in each QNE are based on the current parameter values in QoS Available, plus any parameters that only appear in QoS Desired. The drawback is that if the resulting reservation gets gradually smaller towards the QNR, QNEs close to the QNI end up with an oversized reservation. That can mean unnecessary costs for the user 😬 Of course, in the RESPONSE the QNI learns what the actual reservation is (from the QoS Reserved object) and can immediately issue a properly sized refreshing RESERVE. The upside is that the reservation is performed in half-a-roundtrip time ⚡
The QSPEC parameter IDs and values included in the QoS Reserved object in the RESPONSE message MUST be the same as those in the QoS Desired object in the RESERVE message. For the QSPEC parameters that were also included in the QoS Available object in the RESERVE message, their value is copied from the QoS Available object (in RESERVE) into the QoS Reserved object (in RESPONSE). For the other QSPEC parameters, the value is copied from the QoS Desired object. The reservation would fail if the corresponding QoS couldn't be reserved 🧁
All parameters in the QoS Available object in the RESPONSE message are copied with their values from the QoS Available object in the RESERVE message, whether or not they've also been copied into the QoS Desired object. The parameters in the QoS Available object can be overwritten in the RESERVE message, but they can't be overwritten in the RESPONSE message 🔒
In this case, the QNI SHOULD request a RESPONSE message, since otherwise it won't learn what QoS is available 🙏
Case 3:
This case is handled as case 2, except that the reservation fails when QoS Available becomes less than Minimum QoS for one parameter. If a parameter appears in the QoS Available object but not in the Minimum QoS object, it's assumed there's no minimum value for that parameter 🫧
Regarding Traffic Handling Directives, the default rule is that all QSPEC parameters that the QNI included in the RESERVE message are also included in the RESPONSE message by the QNR, with the value they had when they arrived at the QNR. When traveling in the RESPONSE message, all Traffic Handling Directives parameters are read-only. A QOSM specification may define its own Traffic Handling Directives parameters and processing rules, so check that too 🌈
4.3.2. Three-Way Transactions 🎀
Okay so in this one, the QNR sends a QUERY, and the QNI replies with a RESERVE message if the reservation worked 💅. Then the QNR sends a RESPONSE message back to the QNI. There are 3 cases for how QSPEC objects get used, and each one has its own vibe ✨
MSG.|OBJ.|OBJECTS INCLUDED |OBJECTS INCLUDED |OBJECTS INCLUDED
SEQ.|COM.|IN QUERY MESSAGE |IN RESERVE MESSAGE |IN RESPONSE MESSAGE
-------------------------------------------------------------------
1 |0 |QoS Desired |QoS Desired |QoS Reserved
| | | |
1 |1 |QoS Desired |QoS Desired |QoS Reserved
| |(Minimum QoS) |QoS Available |QoS Available
| | |(Minimum QoS) |
| | | |
1 |2 |QoS Desired |QoS Desired |QoS Reserved
| |QoS Available |QoS Available |
Table 2: Message Sequence 1: Three-Way Transactions
Defining Object Combinations 0, 1, and 2Cases 1 and 2:
So the main idea here is that the sender (the QNR in this scenario) needs to tell the receiver (the QNI in this scenario) what QoS it wants 💖. To do that, it sends a QUERY message with a QoS Desired QSPEC object. If the QoS is negotiable, it also adds a (possibly zero) Minimum QoS object, like in Case 2 🫶.
The RESERVE message includes the QoS Available object if the sender signaled that QoS is negotiable, which means it included the Minimum QoS object. If the Minimum QoS object from the sender was in the QUERY message, the QNI also puts the Minimum QoS object in the RESERVE message 🌸.
For a successful reservation, the RESPONSE message in Case 1 is optional, and so is the QSPEC inside it 🤷♀️. In Case 2 though, the RESPONSE message is necessary so the QNI can actually learn about the QoS available 😭.
Case 3:
This is the 'RSVP-style' scenario 🦋. The sender (the QNR in this scenario) issues a QUERY message with a QoS Desired object, telling the receiver (the QNI in this scenario) what QoS it wants, same as before. It also includes a QoS Available object to collect path properties. Note that here the path properties are collected with the QUERY message, whereas in the previous case, 2 path properties were collected in the RESERVE message 👀.
Some parameters in the QoS Available object may be the same as in the QoS Desired object. For these parameters, the implicit message is that the sender would be satisfied by a reservation with lower parameter values than the ones specified in QoS Desired 💅.
It's possible for the QoS Available object to contain parameters that don't appear in the QoS Desired object. Those are assumed to be collected for informational purposes only, like path latency 🧚. The parameter values in the QoS Available object are seeded according to the sender's capabilities. Each QNE remaps or approximately interprets those values according to its current capabilities ✨.
The receiver (the QNI in this scenario) signals the QoS Desired object like this: for parameters that appear in both the QoS Available object and the QoS Desired object in the QUERY message, it takes the (possibly remapped) QSPEC parameter values from the QoS Available object. For parameters that only appear in the QoS Desired object, it adopts the parameter values from the QoS Desired object 🎀.
The parameters in the QoS Available QSPEC object in the RESERVE message are copied with their values from the QoS Available QSPEC object in the QUERY message. Note that the parameters in the QoS Available object can be overwritten in the QUERY message, but they cannot be overwritten in the RESERVE message 🔒.
The advantage of this model over the sender-initiated reservation is that the over-reservation situation in QNEs close to the QNI (as described above) doesn't happen 🙌. On the other hand, the QUERY message may find, for example, that a particular bandwidth isn't available. When the actual reservation is performed, though, the desired bandwidth may have become free in the meantime. So the 'RSVP style' may end up with a smaller reservation than necessary 😬.
The sender includes all the QSPEC parameters it cares about in the QUERY message. Parameters that can be overwritten get updated by QNEs as the QUERY message travels towards the receiver. The receiver includes all QSPEC parameters that arrived in the QUERY message in the RESERVE message as well, with the value they had when they arrived at the receiver 💜. Again, QOSM-specific QSPEC parameters and procedures may be defined in QOSM specification documents.
In this scenario too, the QNI SHOULD request a RESPONSE message, since otherwise it won't learn what QoS is available 🥺.
When it comes to Traffic Handling Directives, the default rule is that all QSPEC parameters that were included in the RESERVE message by the QNI are also included in the RESPONSE message by the QNR, with the value they had when they arrived at the QNR. While traveling in the RESPONSE message, all Traffic Handling Directives parameters are read-only 🔐. Note that a QOSM specification may define its own Traffic Handling Directives parameters and processing rules 🌈.
4.3.3. Resource Queries 🔍
Here, the QNI issues a QUERY message to check what resources are currently available 👀. The QNR replies with a RESPONSE message.
MESSAGE | OBJECT | OBJECTS INCLUDED | OBJECTS INCLUDED
SEQUENCE | COMBINATION | IN QUERY MESSAGE | IN RESPONSE MESSAGE
-----------------------------------------------------------------
2 | 0 | QoS Available | QoS Available
Table 3: Message Sequence 2: Resource Queries
Defining Object Combination 0Note that the QoS Available object can be overwritten while it's traveling in the QUERY message, but it cannot be overwritten in the RESPONSE message 🚫✏️.
For Traffic Handling Directives, the default rule is that all QSPEC parameters that were included in the RESERVE message by the QNI are also included in the RESPONSE message by the QNR, with the value they had when they arrived at the QNR. While traveling in the RESPONSE message, all Traffic Handling Directives parameters are read-only 🔐. Note that a QOSM specification may define its own Traffic Handling Directives parameters and processing rules 💅.
4.3.4. Bidirectional Reservations ↔️
On a QSPEC level, bidirectional reservations are no different from unidirectional ones, since QSPECs for different directions never travel in the same message 🫶.
4.3.5. Preemption 💥
A flow can be preempted by a QNE based on its policy 😤. The decision to preempt a flow may account for various factors, such as the values of the QSPEC preemption priority and defending priority parameters described in Section 5.2.8. In this case, the reservation state for this flow is torn down in the QNE, and the QNE sends a NOTIFY message to the QNI, as described in [RFC5974]. The NOTIFY message carries an INFO-SPEC with the error code, as described in [RFC5974]. A QOSM specification document may specify whether a NOTIFY message also carries a QSPEC object 📄. The QNI would normally tear down the preempted reservation by sending a RESERVE message with the TEAR flag set, using the SII of the preempted reservation. However, the QNI can follow other procedures as specified in its QOSM specification document 🧐.
4.4. QSPEC Extensibility 🌱
Additional QSPEC parameters MAY need to be defined in the future, and they are defined in separate informational documents. For example, QSPEC parameters are defined in [RFC5977] and [RFC5976] 📚.
Guidelines on the technical criteria to be followed when evaluating requests for new codepoint assignments for QSPEC objects and QSPEC parameters are given in Section 7, IANA Considerations 📋.
5. QSPEC Functional Specification 🎀
This section defines the encodings of the QSPEC parameters. We first give the general QSPEC formats, and then the formats of the QSPEC objects and parameters 💖.
Network octet order ('big-endian') for all 16- and 32-bit integers, as well as 32-bit floating point numbers, is as specified in [RFC4506], [IEEE754], and [NETWORK-OCTET-ORDER] 🔢.
5.1. General QSPEC Formats 🧩
The format of the QSPEC closely follows the one used in GIST [RFC5971] and QoS NSLP [RFC5974]. Every object (and parameter) has the following general format 💅:
- The overall format is Type-Length-Value (in that order).
- Some parts of the type field are set aside for control flags.
- Length has the units of 32-bit words, and measures the length of Value. If there is no Value, Length=0. The Object length excludes the header.
- Value is a whole number of 32-bit words. If there is any padding required, the length and location MUST be defined by the object-specific format information; objects that contain variable-length types may need to include additional length subfields to do so.
- Any part of the object used for padding or defined as reserved ("r") MUST be set to 0 on transmission and MUST be ignored on reception.
- Empty QSPECs and empty QSPEC Objects MUST NOT be used.
- Duplicate objects, duplicate parameters, and/or multiple occurrences of a parameter MUST NOT be used.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Common QSPEC Header |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// QSPEC Objects //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+5.1.1. Common Header Format ✨
Okay bestie, the Common QSPEC Header is a fixed 4-octet object 💖 It holds the QSPEC Version, the QSPEC Type, an identifier for the QSPEC Procedure (see Section 4.3), and an Initiator/Local QSPEC bit 🦋
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.|I|QSPECType|r|r| QSPEC Proc. | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Here's the breakdown 🌸
Vers.: identifies the QSPEC version number. QSPEC Version 0 is assigned by this specification in Section 7 (IANA Considerations) 🎀QSPEC Type: identifies the particular type of QSPEC, e.g., a QSPEC Type corresponding to a particular QOSM. QSPEC Type 0 (default) is assigned by this specification in Section 7 (IANA Considerations) 💅QSPEC Proc.: identifies the QSPEC procedure. It's made of two times 4 bits. The first field is the Message Sequence, and the second is the QSPEC Object Combination used for that specific message sequence 🧚
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
|Mes.Sq |Obj.Cmb|
+-+-+-+-+-+-+-+-+The Message Sequence field can be any of these values 👑
0: Sender-Initiated Reservations
1: Receiver-Initiated Reservations
2: Resource QueriesThe Object Combination field can take the values between 1 and 3 that are listed in the tables in Section 4.3 🔥
Message Sequence: 0
Object Combination: 0, 1, 2
Semantic: see Table 1 in Section 4.3.1
Message Sequence: 1
Object Combination: 0, 1, 2
Semantic: see Table 2 in Section 4.3.2
Message Sequence: 2
Object Combination: 0
Semantic: see Table 3 in Section 4.3.3I: the Initiator/Local QSPEC bit tells you whether the QSPEC is an initiator QSPEC or a Local QSPEC. It's set to one of these values 🌈
0: Initiator QSPEC
1: Local QSPECLength: the total length of the QSPEC (in 32-bit words), excluding the common header 🍓
The QSPEC Objects field is a collection of QSPEC objects (QoS Desired, QoS Available, etc.). They all share a common format and each one contains several parameters 💜
5.1.2. QSPEC Object Header Format 🦋
QSPEC objects share a common header format, so they all look the same at the top 🫶
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|E|r|r|r| Object Type |r|r|r|r| Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+E Flag: set if an error occurs on object level ⭐Object Type: this is where the object's identity lives 👑
Object Type = 0: QoS Desired (parameters cannot be overwritten)
= 1: QoS Available (parameters may be overwritten; see
Section 3.2)
= 2: QoS Reserved (parameters cannot be overwritten)
= 3: Minimum QoS (parameters cannot be overwritten)The r bits are reserved 🙈
Each QSPEC or QSPEC parameter inside an object is encoded the same way, in TLV format, using a similar parameter header 🌸
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| Parameter ID |r|r|r|r| Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+M Flag: when set, it means the subsequent parameter MUST be interpreted. Otherwise, the parameter can be ignored if it isn't understood 🔥E Flag: when set, it means either a) a reservation failure where the QSPEC parameter is not met, or b) an error occurred while this parameter was being interpreted (see Section 4.2.1) 💀N Flag: Not Supported QSPEC parameter flag (see Section 4.2.2) 🧚Parameter ID: assigned consecutively to each QSPEC parameter. Parameter IDs are assigned to each QSPEC parameter defined in this document in Sections 5.2 and 7 (IANA Considerations) 🎀
Parameters are usually coded individually, like the <Excess Treatment> parameter (Section 5.2.11). But it's also possible to combine several sub-parameters into one parameter field, which is called 'container coding' ✨ This is useful if either a) the sub-parameters always show up together (like the 5 sub-parameters that jointly make up the TMOD), or b) you want more efficient coding because each sub-parameter value is much less than a 32-bit word (as described in [RFC5977]), and you want to avoid header overload 💅 When a container is defined, the Parameter ID and the M, E, and N flags refer to the container. Examples of container parameters are <TMOD> (specified below) and the PHR (Per Hop Reservation) container parameter specified in [RFC5977] 🦋
5.2. QSPEC Parameter Coding 💖
The references in the following sections point to the normative procedures for processing the QSPEC parameters and sub-parameters 🌈
5.2.1. <TMOD-1> Parameter 🫶
The <TMOD-1> parameter is made up of the <r>, <b>, <p>, <m>, and <MPS> sub-parameters [RFC2212], which all must be populated in the <TMOD-1> parameter. Note that a second TMOD QSPEC parameter, <TMOD-2>, is specified below in Section 5.2.2 ✨
Here's how the <TMOD-1> parameter is coded 💜
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1|E|0|r| 1 |r|r|r|r| 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-1 (MPS) (32-bit unsigned integer) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+The <TMOD-1> parameters are three floating point numbers in single-precision IEEE floating point format [IEEE754], followed by two 32-bit integers in network octet order. The first float is the rate (r), the second float is the bucket size (b), and the third is the peak rate (p). The first unsigned integer is the minimum policed unit (m), and the second is the maximum packet size (MPS) 🌸 The values of r and p are measured in octets per second, while b, m, and MPS are measured in octets. When the r, b, and p terms are represented as IEEE floating point values, the sign bit MUST be zero, because 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 zeroes 🔥
5.2.2. <TMOD-2> Parameter 🦋
A second QSPEC <TMOD-2> parameter is specified in case it's needed, for example, to support some Diffserv applications 🧚
Here's how the <TMOD-2> parameter is coded ✨
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| 2 |r|r|r|r| 5 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TMOD Rate-2 (r) (32-bit IEEE floating point number) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TMOD Size-2 (b) (32-bit IEEE floating point number) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Peak Data Rate-2 (p) (32-bit IEEE floating point number) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Minimum Policed Unit-2 (m) (32-bit unsigned integer) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Maximum Packet Size-2 (MPS) (32-bit unsigned integer) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+The <TMOD-2> parameters are three floating point numbers in single-precision IEEE floating point format [IEEE754], followed by two 32-bit integers in network octet order. The first float is the rate (r), the second is the bucket size (b), and the third is the peak rate (p). The first unsigned integer is the minimum policed unit (m), and the second is the maximum packet size (MPS) 💖 The values of r and p are measured in octets per second, while b, m, and MPS are measured in octets. When the r, b, and p terms are represented as IEEE floating point values, the sign bit MUST be zero, because 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 zeroes 👑
5.2.3. <Path Latency> Parameter ✨
okay bestie, the <Path Latency> parameter is giving main character energy 🦋 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| 3 |r|r|r|r| 1 |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
| Path Latency (32-bit unsigned integer) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+So the <Path Latency> [RFC2215] is one 32-bit unsigned integer, sent in network octet order 🧚. Its whole vibe is the same as the Minimal Path Latency parameter from Section 3.4 of [RFC2215] 💜. The point is to give a baseline minimum path latency for services that estimate or bound extra path delay, like the ones in [RFC2212] 🌸. Pair it with the queuing delay bound from [RFC2212] and friends and the app knows both the minimum and the maximum delivery delay. That's so much knowledge 👑
The composition rule is summation with a clamp of (2^32) - 1 on the maximum value 💅. The latencies are average values in units of one microsecond. A system with resolution less than one microsecond MUST set unused digits to zero 🙈 no sneaking in extra digits, periodt. Each QNE can add a latency between 1 and 2^28 (somewhat over two minutes), and the total across all QNEs can climb as high as (2^32)-2. If the sum goes past (2^32)-2, the end-to-end cumulative delay SHOULD be reported as indeterminate = (2^32)-1 😭
A QNE that can't accurately predict the latency of packets it's processing MUST raise the Not Supported N flag. It can either leave the value of Path Latency as is, or add its best estimate of its lower bound. A raised not-supported flag means the Path Latency value is a lower bound of the real Path Latency. The distinguished value (2^32)-1 means indeterminate latency, because the composition function caps the sum there. It basically says the composition range got exceeded 🧠
5.2.4. <Path Jitter> Parameter ✨
Now the <Path Jitter> parameter, which is giving layers 🎀
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| 4 |r|r|r|r| 4 |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
| Path Jitter STAT1(variance) (32-bit unsigned integer) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Path Jitter STAT2(99.9%-ile) (32-bit unsigned integer) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Path Jitter STAT3(minimum Latency) (32-bit unsigned integer) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Path Jitter STAT4(Reserved) (32-bit unsigned integer) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+The Path Jitter is a set of four 32-bit unsigned integers in network octet order [RFC3393, Y.1540, Y.1541] 🫶. As noted in Section 3.3.2, [RFC3393] calls the Path Jitter parameter "IP Delay Variation" 💖. It's the combo of four stats describing the jitter distribution, with a clamp of (2^32) - 1 on the maximum of each value. The jitter STATs are reported in units of one microsecond. A system with resolution less than one microsecond MUST set unused digits to zero 🙈
Each QNE can add jitter values between 1 and 2^28 (somewhat over two minutes), and the total jitter across all QNEs can go as high as (2^32)-2. If the combination of the element values goes over (2^32)-2, the end-to-end cumulative jitter SHOULD be reported as indeterminate 😭 A QNE that can't accurately predict the jitter of packets it's processing MUST raise the not-supported flag. It can either leave the value of Path Jitter as is, or add its best estimate of its STAT values. A raised not-supported flag means the Path Jitter value is a lower bound of the real Path Jitter. The distinguished value (2^32)-1 means indeterminate jitter.
A QNE that can't accurately predict the jitter of packets it's processing SHOULD set its local Path Jitter parameter to this value. Since the composition function caps the total there, getting this value at a network element or application tells you the true Path Jitter isn't known. This MAY happen because one or more network elements couldn't supply a value, or because the range of the composition calculation was exceeded 🌈
NOTE: The Jitter composition function makes use of the <Path Latency> parameter. Composition functions for loss, latency, and jitter may be found in [Y.1541]. Development continues on methods to combine jitter values to estimate the value of the complete path, and additional statistics may be needed to support new methods (the methods are standardized in [RFC5481] and [COMPOSITION]).
5.2.5. <Path PLR> Parameter ✨
Next up is <Path PLR>, the loss-ratio queen 👑
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| 5 |r|r|r|r| 1 |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
| Path Packet Loss Ratio (32-bit floating point) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+The Path PLR is a single 32-bit single precision IEEE floating point number in network octet order [Y.1541] 🦋. As defined in [Y.1540], Path PLR is the ratio of total lost IP packets to total transmitted IP packets. An evaluation interval of 1 minute is suggested in [Y.1541], and the number of losses observed is directly related to how confident you can be in the result 🧐
The composition rule for <Path PLR> is summation with a clamp of 10^-1 on the maximum value. The PLRs are reported in units of 10^-11. A system with resolution less than 10^-11 MUST set unused digits to zero 🙈. Each QNE adds its local PLR value (up to a maximum of 10^-2) to the total Path PLR value (up to a maximum of 10^-1). Whether the total Path PLR added across all QNEs is acceptable depends on the QOSM being used. The 10^-2 cap on a QNE's local PLR and the 10^-1 clamp on the accumulated end-to-end Path PLR are there to keep the simple additive accumulation accurate and to avoid more complex accumulation functions 🎀. Also, if these maximums get exceeded, the path would likely not meet the QoS objectives 😭
If the sum of the different elements' values exceeds 10^-1, the end-to-end cumulative PLR SHOULD be reported as indeterminate. A QNE that can't accurately predict the PLR of packets it's processing MUST raise the not-supported flag. It can either leave the value of Path PLR as is, or add its best estimate of its lower bound. A raised not-supported flag means the Path PLR value is a lower bound of the real Path PLR. The distinguished value 10^-1 means indeterminate PLR. A QNE that can't accurately predict the PLR of packets it's processing SHOULD set its local path PLR parameter to this value. Since the composition function caps the composed sum there, receiving this value at a network element or application means the true path PLR isn't known. This MAY happen because one or more network elements couldn't supply a value, or because the range of the composition calculation was exceeded 🌸
5.2.6. <Path PER> Parameter ✨
Now <Path PER>, the error-ratio sibling 🍓
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| 6 |r|r|r|r| 1 |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
| Path Packet Error Ratio (32-bit floating point) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+The Path PER is a single 32-bit single precision IEEE floating point number in network octet order [Y.1541] 🧚. As defined in [Y.1540], Path PER is the ratio of total errored IP packets to the total of successful IP packets plus errored IP packets. The number of errored packets observed is directly related to how confident you can be in the result 💜
The composition rule for <Path PER> is summation with a clamp of 10^-1 on the maximum value. The PERs are reported in units of 10^-11. A system with resolution less than 10^-11 MUST set unused digits to zero 🙈. Each QNE adds its local PER value (up to a maximum of 10^-2) to the total Path PER value (up to a maximum of 10^-1). Whether the total Path PER added across all QNEs is acceptable depends on the QOSM being used. The 10^-2 cap on a QNE's local PER and the 10^-1 clamp on the accumulated end-to-end Path PER are there to keep the simple additive accumulation accurate and to avoid more complex accumulation functions 🫶. Again, if these maximums get exceeded, the path would likely not meet the QoS objectives 😭
If the sum of the different elements' values exceeds 10^-1, the end-to-end cumulative PER SHOULD be reported as indeterminate. A QNE that can't accurately predict the PER of packets it's processing MUST raise the Not Supported N flag. It can either leave the value of Path PER as is, or add its best estimate of its lower bound. A raised Not Supported N flag means the Path PER value is a lower bound of the real Path PER. The distinguished value 10^-1 means indeterminate PER. A QNE that can't accurately predict the PER of packets it's processing SHOULD set its local path PER parameter to this value. Since the composition function caps the composed sum there, receiving this value at a network element or application means the true path PER isn't known. This MAY happen because one or more network elements couldn't supply a value, or because the range of the composition calculation was exceeded 🌈
5.2.7. <Slack Term> Parameter ✨
Last but not least, the <Slack Term> parameter 🎀
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| 7 |r|r|r|r| 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Slack Term (S) (32-bit unsigned integer) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Slack term S MUST be nonnegative and is measured in microseconds [RFC2212] ⭐. It's represented as a 32-bit unsigned integer, so its value can range from 0 to (2^32)-1 microseconds 💅
5.2.8. <Preemption Priority> and <Defending Priority> Parameters ✨
okay bestie, the coding for the <Preemption Priority> and <Defending Priority> sub-parameters is giving pure structure 💅 and it comes from [RFC3181] 🦋
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| 8 |r|r|r|r| 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Preemption Priority | Defending Priority |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Preemption Priority 🔥 is the priority of the new flow, compared with the defending priority of flows that were already admitted. Higher values mean higher priority.
Defending Priority 🛡️ works like this: once a flow is admitted, its preemption priority becomes irrelevant. Instead, its defending priority is what gets compared against the preemption priority of new flows. 👑
As specified in [RFC3181], <Preemption Priority> and <Defending Priority> are 16-bit integer values, and both MUST be populated if the parameter is used. No skipping one of them, periodt 🙈
5.2.9. <Admission Priority> Parameter 🎀
the coding for the <Admission Priority> parameter 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| 9 |r|r|r|r| 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Y.2171 Adm Pri.|Admis. Priority| (Reserved) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+So there are two fields for this one, and they get filled in by these rules 🧚
<Y.2171 Admission Priority> values are globally significant on an end-to-end basis, which means they count everywhere along the path ✨ High priority flows, normal priority flows, and best-effort priority flows can get access to resources depending on their admission priority value, as described in [Y.2171]. The values go like this:
<Y.2171 Admission Priority>:
0 - best-effort priority flow
1 - normal priority flow
2 - high priority flowIf the QNI signals <Y.2171 Admission Priority>, it fills in both the <Y.2171 Admission Priority> and <Admission Priority> fields with the same value. Downstream QNEs MUST NOT change the value in the <Y.2171 Admission Priority> field, so end-to-end consistency stays intact 🫶 and they MUST treat the flow priority according to the value that was populated. A QNE in a local domain MAY reset a different value of <Admission Priority> in a Local QSPEC, but (as specified in Section 4.1) the Local QSPEC MUST be consistent with the Initiator QSPEC. Translation: the local domain MUST specify an <Admission Priority> in the Local QSPEC that is functionally equivalent to the <Y.2171 Admission Priority> the QNI put in the Initiator QSPEC. Same vibe, different wrapper 💖
If the QNI signals admission priority according to [EMERGENCY-RSVP], it fills in a locally significant value in the <Admission Priority> field and puts all ones in the <Y.2171 Admission Priority> field 😭 In this case, the functional significance of the <Admission Priority> value is set by the local network administrator. Higher values mean higher priority. Downstream QNEs and RSVP nodes MAY reset the <Admission Priority> value according to the local rules the local network administrator sets, but they MUST NOT reset the value of the <Y.2171 Admission Priority> field. Hands off that field, bestie 🙅♀️
A reservation without an<Y.2171 Admission Priority>parameter MUST be treated as a reservation with an<Y.2171 Admission Priority>= 1. No exceptions, no vibes-based guessing 💀
5.2.10. <RPH Priority> Parameter 🍓
here's the coding for the <RPH Priority> parameter 💜
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| 10 |r|r|r|r| 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RPH Namespace | RPH Priority | (Reserved) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+[RFC4412] defines a resource priority header (RPH) with parameters "RPH Namespace" and "RPH Priority". If it's populated, it only applies to flows with high admission priority 👑 A registry is created in [RFC4412] and extended in [EMERG-RSVP] so IANA can assign the RPH priority parameter. In the extended registry, "Namespace Numerical Values" are assigned by IANA to RPH Namespaces, and "Priority Numerical Values" are assigned to the RPH Priority. Registry energy, I'm obsessed 🌈
Note that the <Admission Priority> parameter MAY be used in combination with the <RPH Priority> parameter, which depends on the supported QOSM. Also, if more than one RPH namespace is supported by a QOSM, then the QOSM MUST specify how the priorities belonging to the different RPH namespaces get mapped to each other 🔁
Note also that extra work is needed to communicate these flow priority values to bearer-level network elements [VERTICAL-INTERFACE] 🛠️
For the 4 priority parameters, these combinations are permissible (procedures are in the references):
1 parameter: <Admission Priority> [Y.2171]
2 parameters: <Admission Priority>, <RPH Priority> [RFC4412]
2 parameters: <Preemption Priority>, <Defending Priority> [RFC3181]
3 parameters: <Preemption Priority>, <Defending Priority>,
<Admission Priority> [3GPP-1, 3GPP-2, 3GPP-3]
4 parameters: <Preemption Priority>, <Defending Priority>,
<Admission Priority>, <RPH Priority> [3GPP-1, 3GPP-2,
3GPP-3]It's fine to have <Admission Priority> without <RPH Priority>, but it's NOT permissible to have <RPH Priority> without <Admission Priority>. (Alternatively, <RPH Priority> is ignored in instances without <Admission Priority>.) 🙃
Functionality similar to enhanced Multi-Level Precedence and Preemption service (eMLPP; as defined in [3GPP-1, 3GPP-2]) uses <Admission Priority> for the "queuing allowed" part of eMLPP, and <Preemption/Defending Priority> for the "preemption capable" and "may be preempted" parts of eMLPP. Big "it's all connected" energy 🦋
5.2.11. <Excess Treatment> Parameter 🌸
last one for this chunk, and it's a big one 😭 the coding 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| 11 |r|r|r|r| 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Excess Trtmnt |Re-mark Val| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Excess Treatment tells the QNE how it SHOULD process out-of-profile traffic, meaning traffic that isn't covered by the <TMOD> parameter. The QNI sets this parameter, and the allowed values are:
0: drop
1: shape
2: re-mark
3: no metering or policing is permittedIf there's no Excess Treatment Parameter, the default is that there are no guarantees for excess traffic, so a QNE can do whatever it finds suitable 🤷♀️
When excess treatment is set to 'drop', all marked traffic MUST be dropped by the QNE/RMF. Gone, no drama 💅
When excess treatment is set to 'shape', the QoS Desired object is expected to carry a TMOD parameter, and excess traffic gets shaped to that TMOD ✨ The bucket size in the TMOD parameter for excess traffic sets the queuing behavior. If the shaping causes unbounded queue growth at the shaper, any traffic over the TMOD for excess traffic SHOULD be dropped 🫧 If excess treatment is set to 'shape' and there's no TMOD parameter, the E flag is set for the parameter and the reservation fails 💀 If excess treatment is set to 'shape' and two TMOD parameters are specified, then the QOSM specification dictates how excess traffic should be shaped in that case.
When excess treatment is set to 're-mark', the Excess Treatment Parameter MUST carry the re-mark value, and the re-mark values and procedures MUST be specified in the QOSM specification document. For example, packets might be re-marked to belong to a particular QoS class (a Diffserv Code Point (DSCP) value) 🍓 In that case, re-marking is about a Diffserv model where packets arrive marked as part of a certain QoS class or DSCP. When they're identified as excess, they get re-marked to a different QoS class (DSCP value) listed in the 'Re-mark Value', like this:
Re-mark Value (6 bits) tells you the DSCP value [RFC2474] to re-mark packets to when they're identified as excess 🎯
If 'no metering or policing is permitted' is signaled, the QNE should accept the Excess Treatment Parameter set by the sender with special care, so that excess traffic doesn't cause a problem 🙈 Requesting the Null Meter [RFC3290] is especially strong, and should be used with caution ⚠️
A NULL metering application [RFC2997] would not include the traffic profile. Conceptually it should be possible to support this with the QSPEC, and a QSPEC without a traffic profile is not excluded by the current specification. Still, the traffic profile matters even when excess treatment isn't specified, for example when negotiating bandwidth for the best-effort aggregate. A "NULL Service QOSM" would need to be specified to describe the desired QNE Behavior and the matching QSPEC format 🧚
As an example of NULL metering behavior, in a properly configured Diffserv router, resources are shared between the aggregates by the scheduling disciplines. So if the incoming rate goes up, it affects the state of a queue within that aggregate, while all the other aggregates still get sufficient bandwidth resources 🌈 NULL metering is useful for best-effort and signaling data, since there's no need to meter and police that data. It gets policed implicitly by the allocated bandwidth and, possibly, active queue management mechanisms 💖
5.2.12. <PHB Class> Parameter ✨
Okay so the <PHB Class> parameter is coded following [RFC3140] 💅 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| 12 |r|r|r|r| 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PHB Field | (Reserved) |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+That matches [RFC3140], and the PHB Field can show up in four possible formats depending on what it's holding 🦋 Let's go through them.
Single PHB:
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| DSCP |0 0 0 0 0 0 0 0 0 0|
+---+---+---+---+---+---+---+---+Set of PHBs:
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| DSCP |0 0 0 0 0 0 0 0 1 0|
+---+---+---+---+---+---+---+---+Now for PHBs that aren't defined by a standards action, so the experimental or local-use ones that [RFC2474] allows 🧚 IANA assigns an arbitrary 12-bit PHB identification code. That code gets left-justified in the 16-bit field. Bit 15 is set to 1, and bit 14 is 0 for a single PHB or 1 for a set of PHBs. Bits 12 and 13 are zero.
Single non-standard PHB (experimental or local):
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PHB ID CODE |0 0 0 1|
+---+---+---+---+---+---+---+---+Set of non-standard PHBs (experimental or local):
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PHB ID CODE |0 0 1 1|
+---+---+---+---+---+---+---+---+Bits 12 and 13 are reserved, either for expanding the PHB identification code or for some other use down the road 🔮
In both cases, when a single PHBID is used to identify a set of PHBs (bit 14 set to 1), that set MUST constitute a PHB Scheduling Class. That means use of PHBs from the set MUST NOT cause intra-microflow traffic reordering when different PHBs from the set are applied to traffic in the same microflow. The AF1x set of PHBs [RFC2597] is a classic example of a PHB Scheduling Class 👑 Sets of PHBs that don't count as a PHB Scheduling Class can be identified by using more than one PHBID.
The registries needed to use RFC 3140 already exist (see [DSCP-REGISTRY] and [PHBID-CODES-REGISTRY]), so no new registry needs to be created for this 🎀
5.2.13. <DSTE Class Type> Parameter ✨
You can find what the parameter values mean in [RFC4124] 📖 The coding for the <DSTE Class Type> parameter 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| 13 |r|r|r|r| 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|DSTE Cls. Type | (Reserved) |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+DSTE Class Type: this tells you the DSTE class type. The values currently allowed are 0, 1, 2, 3, 4, 5, 6, and 7 💜
5.2.14. <Y.1541 QoS Class> Parameter ✨
The coding for the <Y.1541 QoS Class> parameter [Y.1541] goes 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| 14 |r|r|r|r| 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Y.1541 QoS Cls.| (Reserved) |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+Y.1541 QoS Class: this tells you the Y.1541 QoS Class. The values currently allowed are 0, 1, 2, 3, 4, 5, 6, and 7 ✨
Here's the lineup, bestie 👇
- 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. Examples are 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. Examples are VoIP and video teleconference 🎥 - Class 2: highly interactive transaction data. Mean delay
<= 100 ms, delay variation is unspecified, and loss ratio<= 10^-3. Example: signaling 🚦 - Class 3: interactive transaction data. Mean delay
<= 400 ms, delay variation is unspecified, and loss ratio<= 10^-3. Example: signaling 🛎️ - Class 4: Low Loss Only applications. Mean delay
<= 1 s, delay variation is unspecified, and loss ratio<= 10^-3. Examples are short transactions, bulk data, and video streaming 📦 - Class 5: unspecified applications, with unspecified mean delay, delay variation, and loss ratio. Examples are traditional applications of default IP networks 🌸
- Class 6: applications that are highly sensitive to loss. Mean delay
<= 100 ms, delay variation<= 50 ms, and loss ratio<= 10^-5. Examples are television transport, high-capacity TCP transfers, and Time-Division Multiplexing (TDM) circuit emulation 📺 - Class 7: applications that are highly sensitive to loss. Mean delay
<= 400 ms, delay variation<= 50 ms, and loss ratio<= 10^-5. Examples are television transport, high-capacity TCP transfers, and TDM circuit emulation 💎
6. Security Considerations ✨
QSPEC security is directly tied to QoS NSLP security 🔐 The QoS NSLP document [RFC5974] has a very detailed security discussion in Section 7, and all the considerations detailed in Section 7 of [RFC5974] apply to QSPEC.
The priority parameter opens the door to theft-of-service attacks. Users could claim an emergency priority for their flows without any real need, which would effectively stop serious emergency calls from getting through 🚨 Several options exist for countering such attacks, 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)
This one is seriously important, bestie. Emergency calls are a big deal, so please take the theft-of-service risk dead seriously 😭🙈
7. IANA Considerations 🎀
Okay so this section is the registry rulebook 📚 It sets up the registries and the starting codepoint assignments for the QSPEC template, following BCP 26 and RFC 5226 [RFC5226]. It also spells out how IANA hands out new codepoints later on. Let's go!! 💖
This spec creates the following registries, each with the structure shown below.
Object Types (12 bits)
These values are assigned in Section 5 🧚
0: QoS Desired
1: QoS Available
2: QoS Reserved
3: Minimum QoS
Further values are as follows:
4-63: Unassigned
64-67: Private/Experimental Use
68-4095: Reserved
(Note: 'Reserved' just means 'do not give these out'.)
The registration procedure is Specification Required.QSPEC Version (4 bits)
Only one value is given out here, and it's the first one 🌸
0: Version 0 QSPEC
Further values are as follows:
1-15: Unassigned
The registration procedure is Specification Required. (A
specification is required to depreciate, delete, or modify QSPEC
versions.)QSPEC Type (5 bits)
0: Default
1: Y.1541-QOSM [RFC5976]
2: RMD-QOSM [RFC5977]
Further values are as follows:
3-12: Unassigned
13-16: Local/Experimental Use
17-31: Reserved
The registration procedure is Specification Required.QSPEC Procedure (8 bits)
This one's a combo meal 🍓 The QSPEC Procedure object is made of two 4-bit parameters, the Message Sequence parameter and the Object Combination parameter, which Section 4.3 covers. Message Sequences 0 (Two-Way Transactions), 1 (Three-Way Transactions), and 2 (Resource Queries) get their own explanations in Sections 4.3.1, 4.3.2, and 4.3.3. Tables 1, 2, and 3 in Section 4.3 match each Object Combination Number to Message Sequences 0, 1, and 2. Here's the quick summary of what this spec assigns for both parameters:
MSG.|OBJ.|OBJECTS INCLUDED |OBJECTS INCLUDED |OBJECTS INCLUDED
SEQ.|COM.|IN QUERY MESSAGE |IN RESERVE MESSAGE |IN RESPONSE MESSAGE
-------------------------------------------------------------------
0 |0 |N/A |QoS Desired |QoS Reserved
| | | |
0 |1 |N/A |QoS Desired |QoS Reserved
| |N/A |QoS Available |QoS Available
| | | |
0 |2 |N/A |QoS Desired |QoS Reserved
| |N/A |QoS Available |QoS Available
| |N/A |Minimum QoS |
| | | |
1 |0 |QoS Desired |QoS Desired |QoS Reserved
| | | |
1 |1 |QoS Desired |QoS Desired |QoS Reserved
| |(Minimum QoS) |QoS Available |QoS Available
| | |(Minimum QoS) |
| | | |
1 |2 |QoS Desired |QoS Desired |QoS Reserved
| |QoS Available |QoS Available |
| | | |
2 |0 |QoS Available |N/A |QoS AvailableAnything beyond those is still open for grabs, so here's how the rest of each parameter shakes out:
Further values of the Message Sequence parameter (4 bits) are as
follows:
3-15: Unassigned
Further values of the Object Combination parameter (4 bits) are as
follows:
Message | Object
Sequence | Combination
---------------------------
0 | 3-15: Unassigned
1 | 3-15: Unassigned
2 | 1-15: Unassigned
3-15 | 0-15: Unassigned
The registration procedure is Specification Required. (A
specification is required to depreciate, delete, or modify QSPEC
Procedures.)QoS Model Error Code (8 bits)
QoS Model Error Codes can be defined for NSLP error class 6 (QoS Model Error), which Section 6.4 of [RFC5974] describes. Here's how the values are laid out 🦋
0-63: Unassigned
64-67: Private/Experimental Use
68-255: Reserved
The registration procedure is Specification Required. (A
specification is required to depreciate, delete, or modify QoS Model
Error Codes.)Parameter ID (12 bits)
Parameter IDs 1 through 14 are assigned right here, each one mapped to its section in 5.2 💜
1-14: assigned as specified in Section 5.2:
1: <TMOD-1>
2: <TMOD-2>
3: <Path Latency>
4: <Path Jitter>
5: <Path PLR>
6: <Path PER>
7: <Slack Term>
8: <Preemption Priority> and <Defending Priority>
9: <Admission Priority>
10: <RPH Priority>
11: <Excess Treatment>
12: <PHB Class>
13: <DSTE Class Type>
14: <Y.1541 QoS Class>
Further values are as follows:
15-255: Unassigned
256-259: Private/Experimental Use
260-4095: Reserved
The registration procedure is Specification Required. (A
specification is required to depreciate, delete, or modify Parameter
IDs.)Y.2171 Admission Priority Parameter (8 bits)
Values 0 through 2 come from Section 5.2.9 ✨
0-2: assigned as specified in Section 5.2.9:
0: best-effort priority flow
1: normal priority flow
2: high priority flow
Further values are as follows:
3-63: Unassigned
64-255: Reserved
The registration procedure is Specification Required.RPH Namespace Parameter (16 bits)
Okay, this one has a little backstory 📖 [RFC4412] already makes a registry for RPH Namespace and Priority values (see Section 12.6 of [RFC4412]). [EMERG-RSVP] extends that registry, and the QSPEC RPH parameter will use it too. In the extended registry, IANA assigns "Namespace Numerical Values" to RPH Namespaces, and "Priority Numerical Values" get assigned to the RPH Priority. This spec doesn't add any other IANA requirements for the RPH Namespace Parameter. Easy 🫶
Excess Treatment Parameter (8 bits)
Values 0 through 3 come from Section 5.2.11 💅
0-3: assigned as specified in Section 5.2.11:
0: drop
1: shape
2: re-mark
3: no metering or policing is permitted
Further values are as follows:
4-63: Unassigned
64-255: Reserved
The registration procedure is Specification Required.Y.1541 QoS Class Parameter (8 bits)
Values 0 through 7 come from Section 5.2.14 🌈
0-7: assigned as specified in Section 5.2.14:
0: Y.1541 QoS Class 0
1: Y.1541 QoS Class 1
2: Y.1541 QoS Class 2
3: Y.1541 QoS Class 3
4: Y.1541 QoS Class 4
5: Y.1541 QoS Class 5
6: Y.1541 QoS Class 6
7: Y.1541 QoS Class 7
Further values are as follows:
8-63: Unassigned
64-255: Reserved
The registration procedure is Specification Required.8. Acknowledgements 🫶
The authors want to give a huge thank-you, listed in alphabetical order, to David Black, Ken Carlberg, Anna Charny, Christian Dickman, Adrian Farrel, Ruediger Geib, Matthias Friedrich, Xiaoming Fu, Janet Gunn, Robert Hancock, Chris Lang, Jukka Manner, Martin Stiemerling, An Nguyen, Tom Phelan, James Polk, Alexander Sayenko, John Rosenberg, Hannes Tschofenig, and Sven van den Bosch 💖 Thanks for the super helpful suggestions, you're all iconic 👑
9. Contributors 🌸
This document is the result of the NSIS Working Group effort 🦋 Besides the authors and editors listed in Section 12, these people also contributed to the document:
Roland Bless
Institute of Telematics, Karlsruhe Institute of Technology (KIT)
Zirkel 2, Building 20.20
P.O. Box 6980
Karlsruhe 76049
Germany
Phone: +49 721 608 6413
EMail: bless@kit.edu
URI: http://tm.kit.edu/~blessChuck Dvorak
AT&T
Room 2A37
180 Park Avenue, Building 2
Florham Park, NJ 07932
Phone: +1 973-236-6700
Fax: +1 973-236-7453
EMail: cdvorak@research.att.comYacine El Mghazli
Alcatel
Route de Nozay
91460 Marcoussis cedex
FRANCE
Phone: +33 1 69 63 41 87
EMail: yacine.el_mghazli@alcatel.frGeorgios Karagiannis
University of Twente
P.O. BOX 217
7500 AE Enschede
The Netherlands
EMail: g.karagiannis@ewi.utwente.nlAndrew McDonald
Siemens/Roke Manor Research
Roke Manor Research Ltd.
Romsey, Hants SO51 0ZN
UK
EMail: andrew.mcdonald@roke.co.ukAl Morton
AT&T
Room D3-3C06
200 S. Laurel Avenue
Middletown, NJ 07748
Phone: +1 732 420-1571
Fax: +1 732 368-1192
EMail: acmorton@att.comBernd Schloer
University of Goettingen
EMail: bschloer@cs.uni-goettingen.dePercy Tarapore
AT&T
Room D1-33
200 S. Laurel Avenue
Middletown, NJ 07748
Phone: +1 732 420-4172
EMail: tarapore@.att.comLars Westberg
Ericsson Research
Torshamnsgatan 23
SE-164 80 Stockholm, Sweden
EMail: Lars.Westberg@ericsson.com10. Normative References ✨
okay bestie, these are the receipts 🧾 the stuff you have to have read before this spec makes sense. no cap, it's a long list 💅
[3GPP-1]3GPP TS 22.067 V7.0.0 (2006-03) Technical Specification, 3rd Generation Partnership Project; Technical Specification Group Services and System Aspects; enhanced Multi Level Precedence and Preemption service (eMLPP) - Stage 1 (Release 7).[3GPP-2]3GPP TS 23.067 V7.1.0 (2006-03) Technical Specification, 3rd Generation Partnership Project; Technical Specification Group Core Network; enhanced Multi-Level Precedence and Preemption service (eMLPP) - Stage 2 (Release 7).[3GPP-3]3GPP TS 24.067 V6.0.0 (2004-12) Technical Specification, 3rd Generation Partnership Project; Technical Specification Group Core Network; enhanced Multi-Level Precedence and Preemption service (eMLPP) - Stage 3 (Release 6).[RFC2119]Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. 🔑 the one that defines all those capital words, iykyk[RFC2210]Wroclawski, J., "The Use of RSVP with IETF Integrated Services", RFC 2210, September 1997.[RFC2212]Shenker, S., Partridge, C., and R. Guerin, "Specification of Guaranteed Quality of Service", RFC 2212, September 1997.[RFC2215]Shenker, S. and J. Wroclawski, "General Characterization Parameters for Integrated Service Network Elements", RFC 2215, September 1997.[RFC3140]Black, D., Brim, S., Carpenter, B., and F. Le Faucheur, "Per Hop Behavior Identification Codes", RFC 3140, June 2001.[RFC3181]Herzog, S., "Signaled Preemption Priority Policy Element", RFC 3181, October 2001.[RFC4124]Le Faucheur, F., Ed., "Protocol Extensions for Support of Diffserv-aware MPLS Traffic Engineering", RFC 4124, June 2005.[RFC4412]Schulzrinne, H. and J. Polk, "Communications Resource Priority for the Session Initiation Protocol (SIP)", RFC 4412, February 2006.[RFC4506]Eisler, M., Ed., "XDR: External Data Representation Standard", STD 67, RFC 4506, May 2006.[RFC5971]Schulzrinne, H. and R. Hancock, "GIST: General Internet Signalling Transport", RFC 5971, October 2010.[RFC5974]Manner, J., Karagiannis, G., and A. McDonald, "NSIS Signaling Layer Protocol (NSLP) for Quality-of-Service Signaling", RFC 5974, October 2010.[Y.1541]ITU-T Recommendation Y.1541, "Network Performance Objectives for IP-Based Services", February 2006.[Y.2171]ITU-T Recommendation Y.2171, "Admission Control Priority Levels in Next Generation Networks", September 2006.
11. Informative References 🌸
these ones are the extra reading 📚 nice to know, not strictly required to get the vibe
[COMPOSITION]Morton, A. and E. Stephan, "Spacial Composition of Metrics", Work in Progress, July 2010.[DQOS]CableLabs, "PacketCable Dynamic Quality of Service Specification", CableLabs Specification PKT-SP-DQOS-I12-050812, August 2005.[EMERG-RSVP]Le Faucheur, F., Polk, J., and K. Carlberg, "Resource ReSerVation Protocol (RSVP) Extensions for Admission Priority", Work in Progress, March 2010.[G.711]ITU-T Recommendation G.711, "Pulse code modulation (PCM) of voice frequencies", November 1988.[IEEE754]Institute of Electrical and Electronics Engineers, "IEEE Standard for Binary Floating-Point Arithmetic", ANSI/IEEE Standard 754-1985, August 1985.[CL-QOSM]Kappler, C., "A QoS Model for Signaling IntServ Controlled-Load Service with NSIS", Work in Progress, April 2010.[DSCP-REGISTRY]IANA, "Differentiated Services Field Codepoints",http://www.iana.org.[NETWORK-OCTET-ORDER]Wikipedia, "Endianness",http://en.wikipedia.org/wiki/Endianness.[PHBID-CODES-REGISTRY]IANA, "Per Hop Behavior Identification Codes",http://www.iana.org.[RFC1701]Hanks, S., Li, T., Farinacci, D., and P. Traina, "Generic Routing Encapsulation (GRE)", RFC 1701, October 1994.[RFC1702]Hanks, S., Li, T., Farinacci, D., and P. Traina, "Generic Routing Encapsulation over IPv4 networks", RFC 1702, October 1994.[RFC2003]Perkins, C., "IP Encapsulation within IP", RFC 2003, October 1996.[RFC2004]Perkins, C., "Minimal Encapsulation within IP", RFC 2004, October 1996.[RFC2205]Braden, R., Ed., Zhang, L., Berson, S., Herzog, S., and S. Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification", RFC 2205, September 1997.[RFC2473]Conta, A. and S. Deering, "Generic Packet Tunneling in IPv6 Specification", RFC 2473, December 1998.[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 Service", RFC 2475, December 1998.[RFC2597]Heinanen, J., Baker, F., Weiss, W., and J. Wroclawski, "Assured Forwarding PHB Group", RFC 2597, June 1999.[RFC2697]Heinanen, J. and R. Guerin, "A Single Rate Three Color Marker", RFC 2697, September 1999.[RFC2997]Bernet, Y., Smith, A., and B. Davie, "Specification of the Null Service Type", RFC 2997, November 2000.[RFC3290]Bernet, Y., Blake, S., Grossman, D., and A. Smith, "An Informal Management Model for Diffserv Routers", RFC 3290, May 2002.[RFC3393]Demichelis, C. and P. Chimento, "IP Packet Delay Variation Metric for IP Performance Metrics (IPPM)", RFC 3393, November 2002.[RFC3550]Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, July 2003.[RFC3564]Le Faucheur, F. and W. Lai, "Requirements for Support of Differentiated Services-aware MPLS Traffic Engineering", RFC 3564, July 2003.[RFC4213]Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms for IPv6 Hosts and Routers", RFC 4213, October 2005.[RFC4301]Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005.[RFC4303]Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303, December 2005.[RFC5226]Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.[RFC5481]Morton, A. and B. Claise, "Packet Delay Variation Applicability Statement", RFC 5481, March 2009.[RFC5976]Ash, G., Morton, A., Dolly, M., Tarapore, P., Dvorak, C., and Y. El Mghazli, "Y.1541-QOSM: Model for Networks Using Y.1541 Quality-of-Service Classes", RFC 5976, October 2010.[RFC5977]Bader, A., Westberg, L., Karagiannis, G., Kappler, C, and T. Phelan, "RMD-QOSM: The NSIS Quality-of-Service Model for Resource Management in Diffserv", RFC 5977, October 2010.[VERTICAL-INTERFACE]Dolly, M., Tarapore, P., and S. Sayers, "Discussion on Associating of Control Signaling Messages with Media Priority Levels", T1S1.7 and PRQC, October 2004.[Y.1540]ITU-T Recommendation Y.1540, "Internet Protocol Data Communication Service - IP Packet Transfer and Availability Performance Parameters", December 2002.
Appendix A. Mapping of QoS Desired, QoS Available, and QoS Reserved of NSIS onto AdSpec, TSpec, and RSpec of RSVP IntServ 🦋
okay so this appendix is the big "how do these two worlds fit together" moment ✨
the union of QoS Desired, QoS Available, and QoS Reserved can do everything the objects in RSVP IntServ can do 🙌 BUT getting an exact one-to-one mapping is honestly hard, so it's not perfectly clean, ngl 😭
so in RSVP, the Sender TSpec says what the app is actually going to send (think TMOD 🎀). the AdSpec collects path stuff like delay 🛤️ and both of those come from the sender. then the receiver sends back a FlowSpec, which has a Receiver TSpec describing what got reserved using the same parameters as the Sender TSpec, plus an RSpec with extra IntServ QoS Model specific params, like Rate and Slack 💜
the TSpec, AdSpec, and RSpec are all built around the receiver-initiated signaling RSVP uses and the IntServ QoS Model, so they're kinda receiver-driven, periodt 💅
here's the tea: to the authors' knowledge, the sender basically can't say "I want a max delay of X" directly. the only way is sneaky and implicit, by seeding the AdSpec and then changing it up as needed 🙈 and the RSpec only really makes sense when the receiver sends it in the RSVP RESERVE message.
so our take is that a slightly different mapping of the functionality onto objects makes more sense, and it should give us more flexible signaling models 🌈 bestie, that's the whole plot twist 👑
Source doc: RFC 5975, part 14 of 15 🌿
Appendix B. Example of TMOD Parameter Encoding 📞✨
okay so picture a VoIP app that uses RTP [RFC3550] and the G.711 Codec [G.711] 💖 the TMOD-1 parameter could be set up like this:
lowkey the simplest case is when the Minimum Policed Unit m is just the IP, UDP, and RTP headers + payload added together 🫶 the IP header in the IPv4 case is 20 octets (40 octets if you're on IPv6). the UDP header is 8 octets, and RTP uses a 12-octet header. the G.711 Codec specifies a bandwidth of 64 kbit/s (8000 octets/s). assuming RTP sends voice datagrams every 20 ms, the payload for one datagram is 8000 octets/s * 0.02 s = 160 octets 🎀
IPv4 + UDP + RTP + payload: m = 20 + 8 + 12 + 160 octets = 200 octets
IPv6 + UDP + RTP + payload: m = 40 + 8 + 12 + 160 octets = 220 octetsthe Rate r is the amount of octets per second. 50 datagrams get sent per second 🦋
IPv4: r = 50 1/s * m = 10,000 octets/s
IPv6: r = 50 1/s * m = 11,000 octets/sthe bucket size b is the maximum burst. in this example, a burst of 10 packets is used 🌸
IPv4: b = 10 * m = 2000 octets
IPv6: b = 10 * m = 2200 octetsa bunch of extra headers (like for encapsulation) can be included in the datagram too 🧚 here's a non-exhaustive list. for any additional headers, m, r, and b have to be set accordingly 💅
Protocol Header Size
--------------------------+------------
GRE [RFC1701] | 8 octets
GREIP4 [RFC1702] | 4-8 octets
IP4INIP4 [RFC2003] | 20 octets
MINENC [RFC2004] | 8-12 octets
IP6GEN [RFC2473] | 40 octets
IP6INIP4 [RFC4213] | 20 octets
IPsec [RFC4301, RFC4303] | variable
--------------------------+------------Authors' Addresses 🌈
Gerald Ash (Editor)
AT&T
EMail: gash5107@yahoo.com
Attila Bader (Editor)
Traffic Lab
Ericsson Research
Ericsson Hungary Ltd.
Laborc u. 1 H-1037
Budapest Hungary
EMail: Attila.Bader@ericsson.com
Cornelia Kappler (Editor)
ck technology concepts
Berlin, Germany
EMail: cornelia.kappler@cktecc.de
David R. Oran (Editor)
Cisco Systems, Inc.
7 Ladyslipper Lane
Acton, MA 01720, USA
EMail: oran@cisco.com📦 where this page comes from
- ietf: rfc5975 2010-10
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms