RFC 5974
NSIS Signaling Layer Protocol (NSLP) for Quality-of-Service Signaling
RFC 5974: NSIS Signaling Layer Protocol (NSLP) for Quality-of-Service Signaling 🎀
Okay bestie, let's start with the header 💅 This one is an Experimental doc from the IETF stream, with ISSN 2070-1721, dated October 2010. The authors are J. Manner (Aalto University), G. Karagiannis (University of Twente/Ericsson), and A. McDonald (Roke) 🦋. The header doesn't list any RFCs it obsoletes or updates, so it's standing on its own, no cap ✨
Abstract ✨
Okay so this spec is all about the NSIS Signaling Layer Protocol (NSLP) for signaling Quality of Service (QoS) reservations on the Internet 🌸 It follows the framework and requirements that were developed in NSIS. Paired with General Internet Signaling Transport (GIST), it gives you stuff similar to RSVP, but it also extends it, which is so iconic 👑
The QoS NSLP doesn't care what QoS specification or architecture is underneath it, and it supports different reservation models 🧚 The big glow-up is that it drops support for multicast flows, so it's simpler. This doc explains the overall approach, the design decisions, and gives examples, and it also specifies the object and message formats and the processing rules 💖
Status of This Memo 🌈
Bestie, this is not an Internet Standards Track spec. It's published so people can examine it, try implementing it, and evaluate it 🍓
It defines an Experimental Protocol for the Internet community. It's a product of the Internet Engineering Task Force (IETF) and it represents the consensus of the IETF community. It got public review and was approved for publication by the Internet Engineering Steering Group (IESG). Not every IESG-approved doc is a candidate for any level of Internet Standard, so check out Section 2 of RFC 5741 if you want the deets 🫶
For the current status, any errata, and how to send feedback, go to http://www.rfc-editor.org/info/rfc5974 ✨
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 these carefully, because they describe your rights and restrictions for this document 📜 Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions, and they are provided without warranty as described in the Simplified BSD License 💅
Table of Contents 🗺️
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 6
3.1. Overall Approach . . . . . . . . . . . . . . . . . . . . . 6
3.1.1. Protocol Messages . . . . . . . . . . . . . . . . . . 9
3.1.2. QoS Models and QoS Specifications . . . . . . . . . . 10
3.1.3. Policy Control . . . . . . . . . . . . . . . . . . . . 12
3.2. Design Background . . . . . . . . . . . . . . . . . . . . 13
3.2.1. Soft States . . . . . . . . . . . . . . . . . . . . . 13
3.2.2. Sender and Receiver Initiation . . . . . . . . . . . . 13
3.2.3. Protection against Message Re-ordering and
Duplication . . . . . . . . . . . . . . . . . . . . . 14
3.2.4. Explicit Confirmations . . . . . . . . . . . . . . . . 14
3.2.5. Reduced Refreshes . . . . . . . . . . . . . . . . . . 14
3.2.6. Summary Refreshes and Summary Tear . . . . . . . . . . 15
3.2.7. Message Scoping . . . . . . . . . . . . . . . . . . . 15
3.2.8. Session Binding . . . . . . . . . . . . . . . . . . . 16
3.2.9. Message Binding . . . . . . . . . . . . . . . . . . . 16
3.2.10. Layering . . . . . . . . . . . . . . . . . . . . . . . 17
3.2.11. Support for Request Priorities . . . . . . . . . . . . 18
3.2.12. Rerouting . . . . . . . . . . . . . . . . . . . . . . 19
3.2.13. Preemption . . . . . . . . . . . . . . . . . . . . . . 24
3.3. GIST Interactions . . . . . . . . . . . . . . . . . . . . 24
3.3.1. Support for Bypassing Intermediate Nodes . . . . . . . 25
3.3.2. Support for Peer Change Identification . . . . . . . . 25
3.3.3. Support for Stateless Operation . . . . . . . . . . . 26
3.3.4. Priority of Signaling Messages . . . . . . . . . . . . 26
3.3.5. Knowledge of Intermediate QoS-NSLP-Unaware Nodes . . . 26
4. Examples of QoS NSLP Operation . . . . . . . . . . . . . . . . 26
4.1. Sender-Initiated Reservation . . . . . . . . . . . . . . . 27
4.2. Sending a Query . . . . . . . . . . . . . . . . . . . . . 28
4.3. Basic Receiver-Initiated Reservation . . . . . . . . . . . 29
4.4. Bidirectional Reservations . . . . . . . . . . . . . . . . 31
4.5. Aggregate Reservations . . . . . . . . . . . . . . . . . . 33
4.6. Message Binding . . . . . . . . . . . . . . . . . . . . . 34
4.7. Reduced-State or Stateless Interior Nodes . . . . . . . . 38
4.7.1. Sender-Initiated Reservation . . . . . . . . . . . . . 38
4.7.2. Receiver-Initiated Reservation . . . . . . . . . . . . 40
4.8. Proxy Mode . . . . . . . . . . . . . . . . . . . . . . . . 41
5. QoS NSLP Functional Specification . . . . . . . . . . . . . . 42
5.1. QoS NSLP Message and Object Formats . . . . . . . . . . . 42
5.1.1. Common Header . . . . . . . . . . . . . . . . . . . . 42
5.1.2. Message Formats . . . . . . . . . . . . . . . . . . . 44
5.1.3. Object Formats . . . . . . . . . . . . . . . . . . . . 47
5.2. General Processing Rules . . . . . . . . . . . . . . . . . 60
5.2.1. State Manipulation . . . . . . . . . . . . . . . . . . 61
5.2.2. Message Forwarding . . . . . . . . . . . . . . . . . . 62
5.2.3. Standard Message Processing Rules . . . . . . . . . . 62
5.2.4. Retransmissions . . . . . . . . . . . . . . . . . . . 62
5.2.5. Rerouting . . . . . . . . . . . . . . . . . . . . . . 63
5.3. Object Processing . . . . . . . . . . . . . . . . . . . . 65
5.3.1. Reservation Sequence Number (RSN) . . . . . . . . . . 65
5.3.2. Request Identification Information (RII) . . . . . . . 66
5.3.3. BOUND-SESSION-ID . . . . . . . . . . . . . . . . . . . 67
5.3.4. REFRESH-PERIOD . . . . . . . . . . . . . . . . . . . . 67
5.3.5. INFO-SPEC . . . . . . . . . . . . . . . . . . . . . . 68
5.3.6. SESSION-ID-LIST . . . . . . . . . . . . . . . . . . . 70
5.3.7. RSN-LIST . . . . . . . . . . . . . . . . . . . . . . . 71
5.3.8. QSPEC . . . . . . . . . . . . . . . . . . . . . . . . 71
5.4. Message Processing Rules . . . . . . . . . . . . . . . . . 72
5.4.1. RESERVE Messages . . . . . . . . . . . . . . . . . . . 72
5.4.2. QUERY Messages . . . . . . . . . . . . . . . . . . . . 77
5.4.3. RESPONSE Messages . . . . . . . . . . . . . . . . . . 78
5.4.4. NOTIFY Messages . . . . . . . . . . . . . . . . . . . 79
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 80
6.1. QoS NSLP Message Type . . . . . . . . . . . . . . . . . . 81
6.2. NSLP Message Objects . . . . . . . . . . . . . . . . . . . 81
6.3. QoS NSLP Binding Codes . . . . . . . . . . . . . . . . . . 82
6.4. QoS NSLP Error Classes and Error Codes . . . . . . . . . . 82
6.5. QoS NSLP Error Source Identifiers . . . . . . . . . . . . 83
6.6. NSLP IDs and Router Alert Option Values . . . . . . . . . 83
7. Security Considerations . . . . . . . . . . . . . . . . . . . 83
7.1. Trust Relationship Model . . . . . . . . . . . . . . . . . 85
7.2. Authorization Model Examples . . . . . . . . . . . . . . . 87
7.2.1. Authorization for the Two-Party Approach . . . . . . . 87
7.2.2. Token-Based Three-Party Approach . . . . . . . . . . . 88
7.2.3. Generic Three-Party Approach . . . . . . . . . . . . . 90
7.3. Computing the Authorization Decision . . . . . . . . . . . 90
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 91
9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 91
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 91
10.1. Normative References . . . . . . . . . . . . . . . . . . . 91
10.2. Informative References . . . . . . . . . . . . . . . . . . 91
Appendix A. Abstract NSLP-RMF API . . . . . . . . . . . . . . . . 94
A.1. Triggers from QOS-NSLP towards RMF . . . . . . . . . . . . 94
A.2. Triggers from RMF/QOSM towards QOS-NSLP . . . . . . . . . 96
A.3. Configuration Interface . . . . . . . . . . . . . . . . . 99
Appendix B. Glossary . . . . . . . . . . . . . . . . . . . . . . 1001. Introduction 🦋
Okay, so this doc defines a Quality of Service (QoS) NSIS Signaling Layer Protocol (NSLP), which we'll just call the "QoS NSLP" 💖 It sets up and maintains state at the nodes along a data flow's path, so that the flow gets some forwarding resources. It's meant to meet the QoS-related requirements of RFC 3726 [RFC3726]. The QoS NSLP is part of a bigger suite of signaling protocols, and the NSIS framework [RFC4080] outlines how that suite is structured ✨ The abstract NTLP got turned into a real, concrete protocol called GIST (General Internet Signaling Transport) [RFC5971], and the QoS NSLP leans on GIST to handle a lot of the signaling message delivery 🫶
The QoS NSLP is conceptually similar to RSVP [RFC2205] 🌸 It uses soft-state, peer-to-peer refresh messages as its main way of managing state. That means state installation and refresh happen between pairs of adjacent NSLP nodes, not end-to-end along the whole signaling path, which is a very main character move 👑 The QoS NSLP also extends the set of reservation mechanisms to meet the requirements of RFC 3726 [RFC3726]. In particular, it supports sender-initiated or receiver-initiated reservations, plus a kind of bidirectional reservation, and it allows reservations between arbitrary nodes, like edge-to-edge or end-to-access, and so on 🧚 On the flip side, there's currently no support for IP multicast 🙈
Here's a key distinction: the signaling protocol is one thing, and the info the Resource Management Function (RMF) needs is another. This document covers the signaling protocol, while [RFC5975] covers the RMF-related info carried in the QSPEC (QoS Specification) object inside QoS NSLP messages 💅 It's similar to how RSVP got decoupled from the IntServ architecture [RFC1633] ✨ The QSPEC carries info about the resources available, the resources required, traffic descriptions, and other stuff the RMF needs 🎀
Here's how this doc is laid out 🗺️ The overall protocol design is outlined in Section 3.1. The rest of Section 3 goes into more detail on how the QoS NSLP works and gets used. Section 4 then walks through a bunch of examples to make things clearer. Those two sections are the ones to read if you're interested in what the protocol can do overall. The functional specification in Section 5 has the detailed object and message formats and processing rules, so that's the one implementers should build from 🫶 The last sections cover IANA allocation issues and security considerations 💜
Part 1 of 21. The rest of the spec is coming, bestie 🦋
2. Terminology ✨
okay so bestie, first things first: the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be read the way they're explained in RFC 2119 [RFC2119]. no cap, these words are doing heavy lifting here 🫶
the terminology defined by GIST [RFC5971] applies to this document too, so if you see GIST stuff, go check that one 🌸
okay now the extra terms the doc uses 💅
QNE: an NSIS Entity (NE), which supports the QoS NSLP. 🦋
QNI: the first node in the sequence of QNEs that issues a reservation request for a session. the main character who starts the whole reservation 👑
QNR: the last node in the sequence of QNEs that receives a reservation request for a session. the one at the end of the line who catches it 🎀
P-QNE: Proxy-QNE, a node set to reply to messages with the PROXY scope flag set. 🧚
Session: A session defines an association between a QNI and QNR related to a data flow. Intermediate QNEs on the path, the QNI, and the QNR use the same identifier to refer to the state stored for the association. The same QNI and QNR may have more than one session active at any one time. ✨ so basically everyone on the path agrees on one name for the state, and the same QNI and QNR can have multiple sessions going at once. iconic multitasking 💜
Session Identification (SESSION-ID, SID): This is a cryptographically random and (probabilistically) globally unique identifier of the application-layer session that is associated with a certain flow. Often, there will only be one data flow for a given session, but in mobility/multihoming scenarios, there may be more than one, and they may be differently routed [RFC4080]. 🔥 the SID is random, mostly globally unique, and tied to the app-layer session. usually one flow per session, but with mobility or multihoming you can get more flows, and they might take different routes 🌈 (see [RFC4080] for the deets)
Source or message source: The one of two adjacent NSLP peers that is sending a signaling message (maybe the upstream or the downstream peer). Note that this is not necessarily the QNI. 🙈 the message source is whichever adjacent peer is sending the signaling message, could be upstream or downstream, and it is NOT automatically the QNI. don't mix them up bestie 💀
QoS NSLP operation state: State used/kept by the QoS NSLP processing to handle messaging aspects. 🍓 this is the bookkeeping the QoS NSLP keeps for handling its messages.
QoS reservation state: State used/kept by the Resource Management Function to describe reserved resources for a session. 💖 and this one is the Resource Management Function's notes about what's reserved for a session.
Flow ID: This is essentially the Message Routing Information (MRI) in GIST for path-coupled signaling. 🦋 the Flow ID is basically the MRI from GIST when we're doing path-coupled signaling. so cute, they're related 🫶
Figure 1 shows the components that have a role in a QoS NSLP signaling session. The flow sender and receiver would in most cases be part of the QNI and QNR nodes. Yet, these may be separate nodes, too. 🌸 okay here's the picture of who's who. the flow sender and receiver are usually inside the QNI and QNR, but they can also be their own separate nodes. flexible era 🌈
QoS NSLP nodes
IP address (QoS-unaware NSIS nodes are IP address
= Flow not shown) = Flow
Source | | | Destination
Address | | | Address
V V V
+--------+ Data +------+ +------+ +------+ +--------+
| Flow |-------|------|------|------|-------|------|---->| Flow |
| Sender | Flow | | | | | | |Receiver|
+--------+ | QNI | | QNE | | QNR | +--------+
| | | | | |
+------+ +------+ +------+
=====================>
<=====================
Signaling
Flow
Figure 1: Components of the QoS NSLP ArchitectureA glossary of terms and abbreviations used in this document can be found in Appendix B. 📚 if you get lost on any of these abbreviations, Appendix B is your cheat sheet, bestie ✨
3. Protocol Overview 🧚
3.1. Overall Approach 💅
This section presents a logical model for the operation of the QoS NSLP and associated provisioning mechanisms within a single node. The model is shown in Figure 2. 🦋 this is the "what happens inside one box" section, and the picture is right below 👀
+-----------------+
| Local |
| Applications or |
|Management (e.g.,|
| for aggregates) |
+-----------------+
^
V
V
+----------+ +----------+ +---------+
| QoS NSLP | | Resource | | Policy |
|Processing|<<<<<<>>>>>>>|Management|<<<>>>| Control |
+----------+ +----------+ +---------+
. ^ | * ^
| V . * ^
+----------+ * ^
| NTLP | * ^
|Processing| * V
+----------+ * V
| | * V
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
. . * V
| | * .............................
. . * . Traffic Control .
| | * . +---------+.
. . * . |Admission|.
| | * . | Control |.
+----------+ +------------+ . +---------+.
<-.-| Input | | Outgoing |-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.->
| Packet | | Interface | .+----------+ +---------+.
===>|Processing|====| Selection |===.| Packet |====| Packet |.==>
| | |(Forwarding)| .|Classifier| Scheduler|.
+----------+ +------------+ .+----------+ +---------+.
.............................
<.-.-> = signaling flow
=====> = data flow (sender --> receiver)
<<<>>> = control and configuration operations
****** = routing table manipulation
Figure 2: QoS NSLP in a NodeThis diagram shows an example implementation scenario where QoS conditioning is performed on the output interface. However, this does not limit the possible implementations. For example, in some cases, traffic conditioning may be performed on the incoming interface, or it may be split over the input and output interfaces. 🌈 the picture is just one example, not the only way to build it, so don't panic if your node does things differently 💖
Also, the interactions with the Policy Control component may be more complex, involving interaction with the Resource Management Function, and the AAA infrastructure. 🔥 policy control can get messy, with RMF and AAA all in the mix 😭
From the perspective of a single node, the request for QoS may result from a local application request or from processing an incoming QoS NSLP message. The request from a local application includes not only user applications but also network management and the policy control module. For example, a request could come from multimedia applications, initiate a tunnel to handle an aggregate, interwork with some other reservation protocol (such as RSVP), and contain an explicit teardown triggered by a AAA policy control module. In this sense, the model does not distinguish between hosts and routers. 🎀 so a QoS request can come from an app or from an incoming NSLP message. it can be video calls, tunnels, RSVP interworking, even a teardown from AAA policy. and the model doesn't care whether the box is a host or a router, iykyk 🦋
Incoming messages are captured during input packet processing and handled by GIST. Only messages related to QoS are passed to the QoS NSLP. GIST may also generate triggers to the QoS NSLP (e.g., indications that a route change has occurred). The QoS request is handled by the RMF, which coordinates the activities required to grant and configure the resource. It also handles policy-specific aspects of QoS signaling. 🧚 GIST catches the incoming messages, only the QoS-related ones get passed up, and GIST can also poke the QoS NSLP when something like a route change happens. then the RMF takes the wheel: it coordinates granting and setting up the resource, and handles the policy bits too 💅
The grant processing involves two local decision modules, 'policy control' and 'admission control'. Policy control determines whether the user is authorized to make the reservation. Admission control determines whether the network of the node has sufficient available resources to supply the requested QoS. If both checks succeed, parameters are set in the packet classifier and in the link-layer interface (e.g., in the packet scheduler) to obtain the desired QoS. Error notifications are passed back to the request originator. The Resource Management Function may also manipulate the forwarding tables at this stage to select (or at least pin) a route; this must be done before interface-dependent actions are carried out (including sending outgoing messages over any new route), and is in any case invisible to the operation of the protocol. 🔥 two checks, two bouncers: policy control asks "is this user allowed?" and admission control asks "is there room?" 🙈 if both say yes, the classifier and scheduler get set up for the QoS. if something fails, the error goes back to whoever asked. the RMF can also touch the forwarding tables to pin a route, and that MUST happen before any interface-dependent stuff (including sending messages on a new route). and yeah, the protocol can't see any of it 🫣
Policy control is expected to make use of the authentication infrastructure or the authentication protocols external to the node itself. Some discussion can be found in a separate document on authorization issues [qos-auth]. More generally, the processing of policy and Resource Management Functions may be outsourced to an external node, leaving only 'stubs' co-located with the NSLP node; this is not visible to the protocol operation. A more detailed discussion of authentication and authorization can be found in Section 3.1.3. 🌸 policy control is supposed to lean on outside authentication stuff, and there's a separate authorization doc [qos-auth] if you want the tea. the policy and RMF work can also get shipped off to an external box, with just little 'stubs' left next to the NSLP node, and the protocol doesn't notice. more authentication and authorization drama lives in Section 3.1.3 ✨
Admission control, packet scheduling, and any part of policy control beyond simple authorization have to be implemented using specific definitions for types and levels of QoS. A key assumption is made that the QoS NSLP is independent of the QoS parameters (e.g., IntServ service elements). These are captured in a QoS model and interpreted only by the resource management and associated functions, and are opaque to the QoS NSLP itself. QoS models are discussed further in Section 3.1.2. 🦋 admission control, scheduling, and the fancier policy stuff all need specific QoS definitions. the big assumption here is that the QoS NSLP doesn't care what the QoS parameters are (like IntServ service elements). those live in a QoS model that only the resource management side reads, and the NSLP treats them as a black box 🖤 more model talk is in Section 3.1.2 💜
The final stage of processing for a resource request is to indicate to the QoS NSLP protocol processing that the required resources have been configured. The QoS NSLP may generate an acknowledgment message in one direction, and may forward the resource request in the other. Message routing is carried out by the GIST module. Note that while Figure 2 shows a unidirectional data flow, the signaling messages can pass in both directions through the node, depending on the particular message and orientation of the reservation. 👑 last stop: once the resources are set up, the NSLP gets told. it MAY send an ack one way and MAY forward the request the other way, and GIST handles the routing. also, Figure 2 only shows data going one way, but signaling can zoom both directions depending on the message and how the reservation is oriented 🌈✨
3.1.1. Protocol Messages 📨
okay so the QoS NSLP has four message types, and they all have their own vibe 💅
- RESERVE 🎀: this is the ONLY message that touches QoS NSLP reservation state. It's the one that creates, refreshes, modifies, and removes state. Like, the result is the same whether a RESERVE shows up once or a bunch of times, which is so reliable of it 🫶
- QUERY 🔍: a QUERY asks for info about the data path without making a reservation. You can use it to make reservations or to support certain QoS models, and the info it gets can feed into admission control at a QNE (like in measurement-based admission control). Also, a QUERY does NOT change existing reservation state, so it's a total non-threat 🙈
- RESPONSE 💌: RESPONSE is the reply, giving info about the result of an earlier QoS NSLP message. It can explicitly confirm the state change signaled in a RESERVE, or answer a QUERY, or throw an error code if the QNE or QNR can't provide the info or the answer is negative. A RESPONSE never installs or modifies reservation state, so it's just vibes and facts ✨
- NOTIFY 📣: NOTIFY messages pass info along to a QNE. The difference from RESPONSE is that they're sent asynchronously and don't have to refer to any particular state or earlier message. The info in a NOTIFY is usually about error conditions. Examples: telling an upstream peer that state got torn down, or telling someone a reservation got preempted 😭
QoS NSLP messages go peer-to-peer, which means a QNE treats its adjacent upstream or downstream peer as the source of each message 🧚
Every protocol message has a common header that says what type it is and has various flag bits. Message formats are defined in Section 5.1.2, and message processing rules are in Section 5.4 🌸
QoS NSLP messages carry three types of objects, bestie 👑
- Control Information: these carry general info for QoS NSLP processing, like sequence numbers or whether a response is required 🔢
- QoS specifications (QSPECs): these describe the actual resources needed, and they depend on the QoS model being used. They can also hold other control info that the RMF's processing uses, on top of any resource description 🧁
- Policy objects: these hold the data used to authorize resource reservation 🔐
Object formats are in Section 5.1.3, and object processing rules are in Section 5.3 🎀
3.1.2. QoS Models and QoS Specifications 🌈
the QoS NSLP is super flexible about the exact patterns of signaling messages that get exchanged 💖 Decoupling the QoS NSLP from the QSPEC means the QoS NSLP can stay ignorant about how traffic, resources, etc. get described, and it can just treat the QSPEC as an opaque object. Different QoS models can be designed without changing the QoS NSLP protocol spec at all. Only the RMF for a given QoS model needs to interpret the QSPEC, and the Resource Management Function (RMF) reserves resources for each flow 🦋
the QSPEC does a similar job to the TSpec, RSpec, and AdSpec objects used with RSVP, which are specified in RFC 2205 [RFC2205] and RFC 2210 [RFC2210]. At each QNE, the QSPEC gets interpreted by the Resource Management Function and the Policy Control Function for traffic and policy control. That includes admission control and configuring the packet classifier and scheduler 💅
The QoS NSLP doesn't mandate any particular behavior for the RMF. Instead, it gives interoperability at the signaling-protocol level, and leaves validating RMF behavior to contracts outside the protocol itself 📜 The RMF can use various elements from the QoS NSLP message, not just the QSPEC object 🫶
Still, this spec assumes resource sharing is possible between flows with the same SESSION-ID that come from the same QNI, or between flows with a different SESSION-ID that are related through the BOUND-SESSION-ID object 🤝 For flows with the same SESSION-ID, resource sharing only applies when the existing reservation isn't just replaced (the REPLACE flag in the common header tells you that). We assume the QoS model supports resource sharing between flows. A QoS Model can choose to do something more general, like supporting relative operations on existing reservations, such as ADDING or SUBTRACTING a certain amount of resources from the current reservation. A QoS Model can also choose to allow resource sharing more broadly, e.g., between all flows with the same Differentiated Service Code Point (DSCP) 🍓
The QSPEC carries a collection of objects that can describe QoS specifications in lots of different ways. A generic template is defined in [RFC5975]. It has object formats for generally useful bits of a QoS description, and it's designed to keep things interoperable when you're using the basic set of objects 🧚 A QSPEC describing the requested resources will usually contain objects that every implementation needs to understand. It can also get extra objects specific to a QoS model, for a more exact definition the RMF can use. The RMF may then be better able to use its own resource management mechanisms, which may be link specific, as a result 💜
A QoS Model defines how the RMF behaves, including its inputs and outputs, and how QSPEC info gets used to describe available resources, required resources, traffic descriptions, and the control info the RMF needs. A QoS Model also describes the minimum set of parameters QNEs should use in the QSPEC when they signal about that QoS Model ✨
QoS Models can be local (private to one network), implementation/vendor specific, or global (implementable by different networks and vendors). All QSPECs should follow the design of the QSPEC template 🌸
The definition of a QoS model may also affect how local behavior gets implemented in the areas where the QoS NSLP gives implementers freedom. For example, it may be useful to identify recommended behavior for how a forwarded RESERVE message relates to a received one, or for when extra signaling sessions should be started based on existing sessions, like the ones needed for aggregate reservations. In some cases, there may be suggestions about whether state that may optionally be retained should be held in particular scenarios. A QoS model may also specify reservation preemption. For example, an incoming resource request might cause removal of an earlier established reservation 🔥
3.1.3. Policy Control 🔐
Getting access to network resources, like network access in general or access to QoS, usually involves some kind of policy control. One example is authorizing the resource requester 🙋♀️ Policy control for QoS NSLP resource reservation signaling is conceptually organized like this, shown in Figure 3:
+-------------+
| Policy |
| Decision |
| Point (PDP) |
+------+------+
|
/-\-----+-----/\
//// \\\\
|| ||
| Policy transport |
|| ||
\\\\ ////
\-------+------/
|
+-------------+ QoS signaling +------+------+
| Entity |<==============>| QNE = Policy|<=========>
| requesting | Data Flow | Enforcement |
| resource |----------------|-Point (PEP)-|---------->
+-------------+ +-------------+
Figure 3: Policy Control with the QoS NSLP SignalingFrom the QoS NSLP point of view, the policy control model is basically a two-party model between neighboring QNEs 👯 The actual policy decision might involve a third entity (the Policy Decision Point, PDP), but that happens outside the QoS NSLP protocol, using existing policy infrastructure (Common Open Policy Service (COPS), Diameter, etc.). So the policy control model for the whole end-to-end chain of QNEs is transitive, with each QNE exchanging policy info with its QoS NSLP policy peer 🔗
Authorization often depends on who's making the request, and authentication may be required 🪪 The GIST channel security mechanisms provide one way to authenticate the QoS NSLP peer that sent the request, so they can be used when making the authorization decision 🛡️
Extra info can also be provided to help with the authorization decision. This might include alternative ways of authenticating the request 💫
The QoS NSLP doesn't currently have objects to carry authorization info. At the time of writing, there's a separate individual work, [NSIS-AUTH], that defines this for the QoS NSLP and the NAT and firewall (NATFW) NSLP 📚
Policy enforcement is likely to concentrate on border nodes between administrative domains 🚧 This may mean nodes inside the domain are "Policy-Ignorant Nodes" that do no per-request authentication or authorization, and rely on the border nodes to do the enforcement. In that case, policy management between the ingress and egress edges of a domain depends on the internal chain of trust between the nodes in the domain. If that isn't acceptable, a separate signaling session can be set up between the ingress and egress edge nodes to exchange policy info 🎀
3.2. Design Background 🧠
This section covers some of the key functionality behind the QoS NSLP spec 💖
3.2.1. Soft States 🫧
The NSIS protocol suite takes a soft-state approach to state management. That means reservation state in QNEs must be refreshed periodically 🔄 How often state installation gets refreshed is expressed in the REFRESH-PERIOD object. This object holds a value in milliseconds for how long the signaled state stays valid. To keep the reservation alive past that lifetime, you send a RESERVE message periodically ⏰
3.2.2. Sender and Receiver Initiation ✨
okay so the QoS NSLP supports BOTH sender-initiated and receiver-initiated reservations 🦋 bestie, that's the vibe.
For a sender-initiated reservation, RESERVE messages travel in the same direction as the data flow being signaled for. The QNI is at the side of the source of the data flow 💅
For a receiver-initiated reservation, RESERVE messages travel in the opposite direction. The QNI is at the side of the receiver of the data flow 🌸
ngl this is the part where people mix up who's in charge, so read this twice 🙈
Note: these definitions follow the definitions in Section 3.3.1 of RFC 4080 [RFC4080]. The main issue is about which node is in charge of requesting and maintaining the resource reservation. In a receiver-initiated reservation, even though the sender sends the initial QUERY, the receiver is still in charge of making the actual resource request and maintaining the reservation. Main character energy for the receiver fr fr 👑
3.2.3. Protection against Message Re-ordering and Duplication 🎀
okay this one is so iconic 😭 RESERVE messages affect the installed reservation state. Unlike NOTIFY, QUERY, and RESPONSE messages, the ORDER in which RESERVE messages are received influences the eventual reservation state stored at a QNE. Like, the most recent RESERVE message replaces the current reservation 💀
So to protect against RESERVE messages getting re-ordered or duplicated, the QoS NSLP uses a Reservation Sequence Number (RSN) 🔥 The RSN has local significance only, i.e., between a QNE and its downstream peers. Only the neighbors care about it, no drama beyond that 🫶
3.2.4. Explicit Confirmations 🌈
A QNE may require a confirmation that the end-to-end reservation is in place, or a reply to a query along the path. For such requests, it MUST be able to keep track of which request each response refers to.
Hmm wait, I need to be careful: the original says "it must be able", which is lowercase, so it is not a BCP 14 requirement. I'll keep it exactly as written: it must be able to keep track of which request each response refers to. This is supported by including a Request Identification Information (RII) object in a QoS NSLP message ✨
3.2.5. Reduced Refreshes 🦋
For scalability, the QoS NSLP supports an abbreviated form of refresh RESERVE message. In this case, the refresh RESERVE references the reservation using the RSN and the SESSION-ID, and does not include the full reservation specification (including QSPEC). By default, state refresh should be performed with reduced refreshes in order to save bytes during transmission. Stateless QNEs will require full refresh since they do not store the whole reservation information 💖
If the stateful QNE does not support reduced refreshes, or there is a mismatch between the local and received RSN, the stateful QNE MUST reply with a RESPONSE carrying an INFO-SPEC indicating the error. Furthermore, the QNE MUST stop sending reduced refreshes to this peer if the error indicates that support for this feature is lacking 🙅♀️
bestie, the MUST here is a hard rule, don't skip it 💅
3.2.6. Summary Refreshes and Summary Tear 🧚
For limiting the number of individual messages, the QoS NSLP supports summary refresh and summary tear messages. When sending a refreshing RESERVE for a certain (primary) session, a QNE may include a SESSION-ID-LIST object where the QNE indicates (secondary) sessions that are also refreshed. An RSN-LIST object must also be added. The SESSION-IDs and RSNs are stacked in the objects such that the index in both stacks refer to the same reservation state, i.e., the SESSION-ID and RSN at index i in both objects refers to the same session. If the receiving stateful QNE notices unknown SESSION-IDs or a mismatch with RSNs for a session, it will reply back to the upstream stateful QNE with an error 🍓
In order to tear down several sessions at once, a QNE may include SESSION-ID-LIST and RSN-LIST objects in a tearing reserve. The downstream stateful QNE must then also tear down the other sessions indicated. The downstream stateful QNE MUST silently ignore any unknown SESSION-IDs.
GIST provides a SII-Handle for every downstream session. The SII-Handle identifies a peer and should be the same for all sessions whose downstream peer is the same. The QoS NSLP uses this information to decide whether summary refresh messages can be sent or when a summary tear is possible ✨
3.2.7. Message Scoping 🎀
A QNE may use local policy when deciding whether to propagate a message or not. For example, the local policy can define/configure that a QNE is, for a particular session, a QNI and/or a QNR. The QoS NSLP also includes an explicit mechanism to restrict message propagation by means of a scoping mechanism 💜
For a RESERVE or a QUERY message, two scoping flags limit the part of the path on which state is installed on the downstream nodes that can respond. When the SCOPING flag is set to zero, it indicates that the scope is "whole path" (default). When set to one, the scope is "single hop". When the PROXY scope flag is set, the path is terminated at a pre-defined Proxy QNE (P-QNE). This is similar to the Localized RSVP [lrsvp] 🌸
The propagation of a RESPONSE message is limited by the RII object, which ensures that it is not forwarded back along the path further than the node that requested the RESPONSE 🦋
3.2.8. Session Binding 👑
Session binding is defined as the enforcement of a relation between different QoS NSLP sessions (i.e., signaling flows with different SESSION-IDs (SIDs) as defined in GIST [RFC5971]).
Session binding indicates a unidirectional dependency relation between two or more sessions by including a BOUND-SESSION-ID object. A session with SID_A (the binding session) can express its unidirectional dependency relation to another session with SID_B (the bound session) by including a BOUND-SESSION-ID object containing SID_B in its messages.
The concept of session binding is used to indicate the unidirectional dependency relation between the end-to-end session and the aggregate session in case of aggregate reservations. In case of bidirectional reservations, it is used to express the unidirectional dependency relation between the sessions used for forward and reverse reservation. Typically, the dependency relation indicated by session binding is purely informative in nature and does not automatically trigger any implicit action in a QNE. A QNE may use the dependency relation information for local resource optimization or to explicitly tear down reservations that are no longer useful. However, by using an explicit binding code (see Section 5.1.3.4), it is possible to formalize this dependency relation, meaning that if the bound session (e.g., session with SID_B) is terminated, the binding session (e.g., the session with SID_A) MUST be terminated also 🔥
A message may include more than one BOUND-SESSION-ID object. This may happen, e.g., in certain aggregation and bidirectional reservation scenarios, where an end-to-end session has a unidirectional dependency relation with an aggregate session and at the same time it has a unidirectional dependency relation with another session used for the reverse path 🧚
3.2.9. Message Binding 💅
QoS NSLP supports binding of messages in order to allow for expressing dependencies between different messages. The message binding can indicate either a unidirectional or bidirectional dependency relation between two messages by including the MSG-ID object in one message ("binding message") and the BOUND-MSG-ID object in the other message ("bound message"). The unidirectional dependency means that only RESERVE messages are bound to each other whereas a bidirectional dependency means that there is also a dependency for the related RESPONSE messages. The message binding can be used to speed up signaling by starting two signaling exchanges simultaneously that are synchronized later by using message IDs 🫶
This can be used as an optimization technique, for example, in scenarios where aggregate reservations are used. Section 4.6 provides more details ✨
3.2.10. Layering 🌈
The QoS NSLP supports layered reservations. Layered reservations may occur when certain parts of the network (domains) implement one or more local QoS models or when they locally apply specific transport characteristics (e.g., GIST unreliable transfer mode instead of reliable transfer mode). They may also occur when several per-flow reservations are locally combined into an aggregate reservation 💖
3.2.10.1. Local QoS Models 🎀
A domain may have local policies regarding QoS model implementation, i.e., it may map incoming traffic to its own locally defined QoS models. The QSPEC allows this functionality, and the operation is transparent to the QoS NSLP. The use of local QoS models within a domain is performed in the RMF 🦋
3.2.10.2. Local Control Plane Properties 🧚
The way signaling messages are handled is mainly determined by the parameters that are sent over the GIST-NSLP API and by the domain internal configuration. A domain may have a policy to implement local transport behavior. It may, for instance, elect to use an unreliable transport locally in the domain while still keeping end-to-end reliability intact 🌸
The QoS NSLP supports this situation by allowing two sessions to be set up for the same reservation. The local session has the desired local transport properties and is interpreted in internal QNEs. This solution poses two requirements: the end-to-end session MUST be able to bypass intermediate nodes, and the egress QNE needs to bind both sessions together. Bypassing intermediate nodes is achieved with GIST. The local session and the end-to-end session are bound at the egress QNE by means of the BOUND-SESSION-ID object 👑
3.2.10.3. Aggregate Reservations 🍓
In some cases, it is desirable to create reservations for an aggregate, rather than on a per-flow basis, in order to reduce the amount of reservation state needed as well as the processing load for signaling messages. Note that the QoS NSLP does not specify how reservations need to be combined in an aggregate or how end-to-end properties need to be computed, but only provides signaling support for aggregate reservations 💜
The essential difference with the layering approaches described in Sections 3.2.10.1 and 3.2.10.2 is that the aggregate reservation needs a MRI that describes all traffic carried in the aggregate (e.g., a DSCP in case of IntServ over Diffserv). The need for a different MRI mandates the use of two different sessions, as described in Section 3.2.10.2 and in the RSVP aggregation solution in RFC 3175 [RFC3175] 🔥
Edge QNEs of the aggregation domain that want to maintain some end-to-end properties may establish a peering relation by sending the end-to-end message transparently over the domain (using the intermediate node bypass capability described above). Updating the end-to-end properties in this message may require some knowledge of the aggregated session (e.g., for updating delay values). For this purpose, the end-to-end session contains a BOUND-SESSION-ID carrying the SESSION-ID of the aggregate session ✨
3.2.11. Support for Request Priorities ✨
okay so this part is about the fact that some messages or reservations are more important than others 💅 and the spec has mechanisms to give those ones priority 👑
in mobile scenarios, losing a message during call setup is honestly less of a disaster than losing one during handover 🙈 so certain signaling messages may need priority over others. this only happens when GIST or QoS NSLP processing is the congested part or the scarce resource 😭
certain reservations may need priority over others when QoS resources are oversubscribed 🔥 in that case, existing reservations can get preempted to make room for new higher-priority ones. the typical approach is giving each reservation a setup priority and a holding priority 🎀 the Resource Management Function at each QNE keeps track of resource consumption at each priority level. a reservation gets established when resources at its setup priority level are still available. it can cause preemption of reservations with a lower holding priority than its own setup priority 💀
reservation priority is a QSPEC parameter, so it's outside the scope of this specification 🦋 but the GIST specification has a mechanism that supports a number of levels of message priority, which you can request over the NSLP-GIST API 🧚
3.2.12. Rerouting 🦋
the QoS NSLP needs to adapt when routes change in the data path 🌸 this assumes it can detect rerouting events, create a QoS reservation on the new path, and optionally tear down reservations on the old path. it's giving main character energy ✨
from an NSLP perspective, rerouting detection can happen in two ways 👀 it can come through NetworkNotification from GIST, or from information seen at the NSLP. in the latter case, the QoS NSLP node can detect changes in its QoS NSLP peers by keeping track of a Source Identification Information (SII) handle 🧠 it gives info similar in nature to the RSVP_HOP object described in RFC 2205 [RFC2205]. when a RESERVE message arrives with an existing SESSION-ID and a different SII, the QNE knows its upstream or downstream peer has changed. that's the upstream peer for sender-oriented reservations and the downstream peer for receiver-oriented ones, respectively 🫶
reservation on the new path happens when a RESERVE message arrives at the QNE beyond the point where the old and new paths diverge 💖 if the QoS NSLP suspects a reroute has happened, a full RESERVE message (including the QSPEC) would be sent. a refreshing RESERVE (with no QSPEC) gets flagged as an error by a QNE on the new path if that QNE doesn't have the reservation installed (because it wasn't on the old path), or if it previously had a different previous-hop QNE. that QNE then sends back an error message, which results in a full RESERVE message being sent 😭 so rapid recovery at the NSLP layer needs short refresh periods, ngl 🏃♀️ detection before the next RESERVE message arrives is only possible at the IP layer, or by monitoring GIST peering relations (for example, by watching the Time to Live (TTL), which is the number of GIST hops between NSLP peers, or by observing changes in the outgoing interface towards a GIST peer) 🧚 these mechanisms can offer implementation-specific optimizations and they're outside the scope of this specification.
once the QoS NSLP knows about the route change, it needs to set up the reservation on the new path 🎀 it does this by sending a new RESERVE message. if the next QNE is actually unchanged, this refreshes or updates the existing reservation. otherwise, it leads to the reservation being installed on the new path 💅
receiver-initiated reservation sessions work a bit differently 👑 if the routing changes in the middle of the path, the node at the divergence point notices its downstream path has changed (indicated by a NetworkNotification from GIST) and must send a QUERY with the R-flag downstream. the QUERY gets processed as above, and eventually it hits a QNE for which the path downstream towards the QNI remains (this is the convergence point) 🌈 that node must then send a full RESERVE upstream to set up reservation state along the new path. it should not send the QUERY further downstream, since that would have no real use. likewise, when the QNE that sent the QUERY receives the RESERVE, it should not send the RESERVE further upstream 🙈
after the reservation on the new path is set up, the branching node may want to tear down the reservation on the old path, sooner than normal soft-state timeout would do it 🔥 this works by keeping track of the old SII-Handle provided over the GIST API. the QoS NSLP can use this handle to route messages explicitly to the next node.
if the old path is downstream, the QNE can send a tearing RESERVE using the old SII-Handle 💜 if the old path is upstream, the QNE can send a NOTIFY with the code for "Route Change". that NOTIFY is forwarded upstream until it reaches a QNE that can issue a tearing RESERVE downstream. a separate document discusses the effect of mobility on QoS NSLP signaling in detail [NSIS-MOB] 📚
a QNI or a branch node may want to keep the reservation on the old branch 🥺 for example, this could happen when a mobile node has had a mobility event and wants to keep its reservation to the old attachment point in case it moves back there. for this purpose, there's a REPLACE flag in the QoS NSLP common header. when it's not set, it indicates that the reservation on the old branch should be kept 🦋
keeping old reservations affects the resources available to other nodes, so the operator of the access network must make the final call on whether this behavior is allowed 🫶 also, the QNEs in the access network may add this flag even if the mobile node didn't use it initially.
the latency in detecting that a new downstream peer exists or that truncation has happened depends on GIST ⏱️ the default QUERY message transmission interval is 30 seconds. you can find more details on how NSLPs can affect the discovery of new peers or rerouting in the GIST specification 🌸
3.2.12.1. Last Node Behavior 🧚
the QoS NSLP is designed so reservations can be installed at a subset of the nodes along a path 💖 the usage scenarios include cases where the data flow endpoints don't support the QoS NSLP.
if the data flow receiver doesn't support the QoS NSLP, some special considerations need to be given to node discovery and rerouting at the end of the signaling path 👀
there are three cases for the last node on the signaling path:
- the last node is the data receiver,
- the last node is a configured proxy for the data receiver, or
- the last node is not the data receiver and is not explicitly configured to act as a signaling proxy on behalf of the data receiver.
cases (1) and (2) can be handled by the QoS NSLP itself during the initial path setup, since the QNE knows it should terminate the signaling 💅 case (3) needs some help from GIST, which provides messages across the API to indicate that no further GIST nodes supporting the QoS NSLP are present downstream. probing for downstream route changes needs to continue once the reservation is installed, so any changes in this situation get detected 🔍
two particular scenarios need to be considered in this third case 🫶 the first one is called "Path Extension". here, rerouting happens so that an additional QNE gets inserted into the signaling path between the old last node and the data receiver, as shown in Figure 4.
/-------\ Initial route
/ v
/-\
/--|B|--\ +-+
/ \-/ \ |x| = QoS NSLP aware
+-+ /-\ +-+
----|A| |D|
+-+ \-/ /-\
\ +-+ / |x| = QoS NSLP unaware
\--|C|--/ \-/
+-+
\ ^
\-------/ Updated route
Figure 4: Path Extensionwhen rerouting occurs, the data path changes from A-B-D to A-C-D 🛣️ initially the signaling path ends at A. even though A starts out as the last node, it needs to keep trying to send messages downstream to probe for path changes, unless it has been explicitly configured as a signaling proxy for the data flow receiver 🙈 this is required so the signaling path change gets detected, and C becomes the new last QNE 🎉
the second case is called "Path Truncation" ✂️ here, rerouting happens so that the QNE that was the last node on the signaling path is no longer on the data path. this is shown in Figure 5.
/-------\ Initial route
/ v
+-+
/--|B|--\ +-+
/ +-+ \ |x| = QoS NSLP aware
+-+ /-\ +-+
----|A| |D|
+-+ \-/ /-\
\ /-\ / |x| = QoS NSLP unaware
\--|C|--/ \-/
\-/
\ ^
\-------/ Updated route
Figure 5: Path Truncationwhen rerouting occurs, the data path again changes from A-B-D to A-C-D 💜 the signaling path initially ends at B, but this node isn't on the new path anymore. in this case, the normal GIST path change detection procedures at A detect the path change and notify the QoS NSLP. GIST also notifies the signaling application that no downstream GIST nodes supporting the QoS NSLP are present 😭 and then node A takes over as the last node on the signaling path 👑
3.2.12.2. Handling Spurious Route Change Notifications ✨
okay so GIST pings the QoS NSLP with a NetworkNotification whenever it thinks a rerouting event might have happened 🛣️ and bestie, sometimes it's not even a real route change 💀 the QoS NSLP often can't tell either, even after it hears from the "new" peer 🙈
when GIST hands over a RecvMessage, it also gives the NSLP an SII-Handle so the NSLP can aim a signaling message at a specific peer 🎯 the SII-Handle changes if the signaling peer changes, but it's NOT guaranteed to stay the same after a rerouting event where the peer didn't change, so the QoS NSLP's reservation maintenance after a route change has robustness mechanisms built in 🛡️ the goal is to avoid accidentally tearing down a reservation when the peer QNE is still the same even after a "route change" notification from GIST. main character protection 👑
here's a simple example 👇
(1) +-+
/-----\ |x| = QoS NSLP aware
+-+ /-\ (3) +-+ +-+
----|A| |B|-----|C|----
+-+ \-/ +-+ /-\
\-----/ |x| = QoS NSLP unaware
(2) \-/
Figure 6: Spurious Reroute Alertingso the initial route is A-B-C using links (1) and (3) 🦋 then link (1) dies and the path reroutes over links (2) and (3) 😭 the set of QNEs along the path doesn't change at all, it's still A-C in both cases, because B doesn't support the QoS NSLP 🙃
when the outgoing interface at A changes, GIST may send a NetworkNotification up to the NSLP. the QoS NSLP at A then tries to repair the path by installing the reservation on the path (2),(3). BUT here the old and new paths are literally the same, so it's giving "wait, why are we doing this" 💅
to install the new reservation, A sends a RESERVE message, and GIST carries it to C (finding the new next peer as needed) ✈️ that RESERVE also asks for a RESPONSE from the QNR. when C gets this RESERVE through the RecvMessage call from GIST, the SII-Handle is unchanged from what A used before 🤔
then the QNR sends a RESPONSE, which gets forwarded from C back to A. this confirms the reservation was installed on the new path 🎉 this time the SII-Handle that GIST passes with the RecvMessage call is different from what was seen before, because the interface being used on A changed 🔄
now A can try to tear down the reservation on the old path 🧹 it sends a RESERVE message with the TEAR flag set down the old path, using the GIST explicit routing mechanism and specifying the SII-Handle that relates to the "old" peer QNE 🎯
if RSNs were incremented for each of these RESERVE and RESERVE-with-TEAR messages, the reservation would get torn down at C and any QNEs further along the path 😱 nope, not happening. so the RSN gets used in a special way ✨ the RESERVE down the new path is sent with the new current RSN set to the old RSN plus 2 💖 and the RESERVE-with-TEAR down the old path is sent with an RSN set to the new current RSN minus 1 🌸 that's the peer it was receiving RESERVE messages from (see for more details). the RSN math is doing the heavy lifting here, iykyk 🧮
3.2.13. Preemption
3.2.13. Preemption 👑
okay preemption is lowkey a building-blocks situation 🧱 the QoS NSLP gives you the signaling pieces to implement preemption, but this spec does NOT define how preemption should work. it just provides signaling mechanisms that QoS models can use 🧩 for example, an INFO-SPEC object can be added to messages to say the signaled session got preempted 🙀 and a BOUND-SESSION-ID object can carry the Session ID of the flow that caused the preemption of the signaled session 💜 how QoS models actually use these is out of scope for the QoS NSLP spec, so that's a them problem 🤷♀️
3.3. GIST Interactions 🫶
the QoS NSLP uses GIST to deliver ALL of its messages 📬 messages go from the NSLP to GIST through an API (defined in Appendix B of [RFC5971]). that API also carries extra info, like an identifier for the signaling application (e.g., 'QoS NSLP'), the session identifier, the MRI, and the intended direction (towards data sender or receiver) 🧭 going the other way, GIST gives the QoS NSLP the same info on reception. other metadata (like the session identifier and MRI) can also be passed across this interface 🎁
the QoS NSLP keeps message and reservation state per session 🗂️ a session is identified by a Session Identifier (SESSION-ID). the SESSION-ID is the primary index for stored NSLP state, and it needs to be constant and unique (with a sufficiently high probability) along a path through the network ✨ the QoS NSLP picks the value for Session-ID, and then GIST and the QoS NSLP both use it to refer to that session 💅
right now the QoS NSLP spec mainly considers the path-coupled MRM 🛤️ but extensions may specify how other types of MRMs can be used with the QoS NSLP, so stay tuned 👀
when GIST passes QoS NSLP data up to the NSLP for processing, it must also indicate the value of the 'D' (Direction) flag for that message in the MRI 🏳️🌈
the QoS NSLP doesn't provide any way to interact with firewalls or Network Address Translators (NATs) 🚫 it assumes GIST provides a basic NAT traversal service 🌐
3.3.1. Support for Bypassing Intermediate Nodes
okay so sometimes the QoS NSLP wants to restrict handling of its messages to specific nodes 🎀 this is needed to support layering (explained in Section 3.2.10), where only the edge QNEs of a domain process the message 🏰 that needs a mechanism at the GIST level (which the QoS NSLP can invoke) to bypass the intermediate nodes between the edges of the domain 🚪
the intermediate nodes get bypassed using multiple levels of the router alert option 🚨 so internal routers are configured to handle only certain levels of router alerts. this works by marking the message at the ingress, i.e., modifying the QoS NSLP default NSLPID value to an NSLPID predefined value (see Section 6.6) 🏷️ the egress stops the marking by reassigning the QoS NSLP default NSLPID value to the original RESERVE message 🔙 the exact operation of modifying the NSLPID must be specified in the relevant QoS model specification, so the model specs are where the juicy details live 📜
3.3.2. Support for Peer Change Identification
there are a bunch of situations where a QNE needs to figure out who its adjacent QNE peer is, the one that sent a signaling application message 🕵️♀️ for example, it might be to enforce the policy that "state can only be modified by messages from the node that created it" 🔐 or keeping track of peer identity might be a (fallback) mechanism for rerouting detection at the NSLP layer 🧯
this is handled in the GIST service interface with the SII-handle 🪪 as shown in the example above, we assume the SII-handling supports both its own SII and its peer's SII 🫂
tracking the SII of a certain reservation also gives the QoS NSLP a way to detect route changes 🔍 when a QNE gets a RESERVE referring to existing state but with a different SII, it knows its upstream peer changed 😮 it can then use the old SII to start a teardown along the old section of the path 🧹 this works in the GIST service interface when the peer's SII (which is stored on message reception) gets passed to GIST upon message transmission 🔁
3.3.3. Support for Stateless Operation
stateless or reduced-state QoS NSLP operation makes the most sense when some nodes can also operate statelessly at the GIST level 🌙 those nodes shouldn't have to worry about keeping reverse state, message fragmentation and reassembly (at GIST), congestion control, or security associations 🙌 a stateless or reduced-state QNE can tell the underlying GIST about this situation, and the GIST service interface does that with the Retain-State attribute in the MessageReceived primitive 💫
3.3.4. Priority of Signaling Messages
the QoS NSLP generates messages with a range of performance requirements for GIST 🏎️ those requirements can come from a prioritization at the QoS NSLP (Section 3.2.11) or from the responsiveness that certain applications supported by the QoS NSLP expect ⚡ the GIST service interface supports this with the 'priority' transfer attribute 🥇
3.3.5. Knowledge of Intermediate QoS-NSLP-Unaware Nodes
sometimes it's useful to know there are routers along the path where QoS can't be provided 🕳️ the GIST service interface helps by tracking IP-TTL and Original-TTL in the RecvMessage primitive 📊 a difference between the two tells you how many QoS-NSLP-unaware nodes there are 🔢 in that case, the QNE that spots this difference should set the "B" (BREAK) flag 🚩 if a QNE gets a QUERY or RESERVE message with the BREAK flag set, and then generates a QUERY, RESERVE, or RESPONSE message, it can set the BREAK flag in those messages too 🔁
BUT there are situations where the egress QNE in a local domain may have some other way to provide QoS [RFC5975] 🪄 for example, in a local domain that knows about RMD-QOSM [RFC5977] (or a similar QoS Model) and that uses either NTLP stateless nodes or NSIS-unaware nodes, the end-to-end RESERVE or QUERY message bypasses those NTLP stateless or NSIS-unaware nodes 🚀 the reservation inside the local domain can still be signaled by the RMD-QOSM (or a similar QoS Model) 💅 so in those situations, the "B" (BREAK) flag in the end-to-end RESERVE or QUERY message should not be set by the edges of the local domain 🙅♀️
4. Examples of QoS NSLP Operation ✨
the QoS NSLP can be used in a number of ways 🎨 the examples here give an indication of some of the basic processing. however, they are not exhaustive and do not attempt to cover the details of the protocol processing 🧚
4.1. Sender-Initiated Reservation
okay bestie, this is the classic one 💖 the sender kicks things off and the reservation gets built hop by hop 🦋
QNI QNE QNE QNR
| | | |
| RESERVE | | |
+--------->| | |
| | RESERVE | |
| +--------->| |
| | | RESERVE |
| | +--------->|
| | | |
| | | RESPONSE |
| | |<---------+
| | RESPONSE | |
| |<---------+ |
| RESPONSE | | |
|<---------+ | |
| | | |
| | | |
Figure 7: Basic Sender-Initiated Reservationso first the QNI builds a RESERVE message 🎀 it holds a QSPEC object from whichever QoS model it picked, and that object spells out the QoS parameters it needs ✨
GIST carries the RESERVE over to the next QNE 🧚 then the QoS NSLP processing gets the message and checks it out. policy control and admission control decisions get made here 💅 the QoS model in use also shapes how all of this plays out 🌸 then the node does whatever is appropriate (like installing the reservation) based on the QSPEC object in the message 🔥
after that, the QoS NSLP makes a brand new RESERVE message, usually built from the one it received 💜 GIST forwards it to the next QNE 🦋
the same thing happens at every QNE down the path until the message reaches the QNR 👑 a node can tell it's the QNR either directly (say, it's the destination of the data flow) or by using GIST to confirm there are no more QNEs between it and the data flow destination 🌈
any node can ask for a RESPONSE by putting a Request Identification Information (RII) object into its RESERVE messages 🎀 if the message already has an RII, an interested QNE must not add a new RII object or replace the old one 🙈 instead it has to remember the RII value so it can match up a RESPONSE that belongs to the RESERVE ✨ when that RESPONSE shows up, the QNE sends it upstream toward the node that originated the RII 💖
in this example the RESPONSE goes peer-to-peer back along the reverse of the path the RESERVE took (using GIST path state) 🦋 that means every QNE on this segment sees it 👀 but it only goes as far as the node that originally asked for it 💅
the reservation can be refreshed later by sending more RESERVE messages with the full reservation info, same as the first time 🔁 you can also modify the reservation the same way, by changing the QSPEC data to ask for a different set of resources 🌸
refreshing can also get lighter, kind of like what RFC 2961 [RFC2961] proposes for RSVP 🫶 once a RESPONSE comes back saying the reservation was installed successfully, the refreshing RESERVE messages can just point at the existing reservation instead of repeating the whole specification 😭
4.2. Sending a Query
QUERY messages are the info-gatherers 🔍 they can collect information from QNEs along the path, like checking what resources are free before anyone makes a reservation 🧚
to run a query along a path, the QNE builds a QUERY message 🎀 it includes a QSPEC with the actual query for the QNEs on the path, an RII object so the response can be matched back to the query, and an indicator of the query scope (next node, whole path, or proxy) 💜 then GIST forwards it along the path 🦋
when a QNE gets a QUERY, it should look at it and make a new message based on it, with the query objects changed as needed 💅 for example, if the query asks whether a flow can be admitted, a node handling it might record how much bandwidth is available 🌸 the new message then goes to GIST for more forwarding, unless that node knows it's the QNR or it's already the limit of the scope set in the QUERY 🙈
at the QNR, a RESPONSE message has to be generated if the QUERY includes an RII object 🫶 a bunch of objects from the received QUERY get copied into the RESPONSE 🎀 GIST then sends it peer-to-peer back along the path 🦋
each QNE that gets the RESPONSE should check the RII object to see if it 'belongs' to that QNE (meaning, it was the one that created it) ✨ if it doesn't, the QNE just hands the message back to GIST to go upstream 💖
and if something went wrong while processing a RESERVE, the RESPONSE might carry an RSN instead of an RII 😬 so a QNE also needs to be ready to look for an RSN object when no RII was there, and act based on the error code set in the INFO-SPEC of the RESPONSE 🚨
4.3. Basic Receiver-Initiated Reservation
so in the NSIS framework [RFC4080], some signaling apps let one end of the data flow take charge of asking the network for special treatment (like a resource reservation) 👑 both ends then agree on whether it's going to be sender- or receiver-initiated 🤝 if it's receiver-initiated, both ends also agree on whether a "One Pass With Advertising" (OPWA) [opwa95] model is in use 🌈 that negotiation can happen through mechanisms outside the scope of NSIS 🫶
to make a receiver-initiated reservation, the QNR builds a QUERY message, which MUST contain a QSPEC object from its chosen QoS model (check Figure 8) 🎀 the QUERY has to have the RESERVE-INIT flag set ✨ this QUERY doesn't need to trigger a RESPONSE, so the QNI must not include the RII object (Section 5.4.2) in it 🙈 the QUERY can also be used to gather info along the path, which travels in the QSPEC object 🧚 one example of that info is the "One Pass With Advertising" (OPWA) model [opwa95] 💜 this QUERY also causes GIST reverse-path state to get installed 🦋
QNR QNE QNE QNI
sender receiver
| | | |
| QUERY | | |
+--------->| | |
| | QUERY | |
| +--------->| |
| | | QUERY |
| | +--------->|
| | | |
| | | RESERVE |
| | |<---------+
| | RESERVE | |
| |<---------+ |
| RESERVE | | |
|<---------+ | |
| | | |
| RESPONSE | | |
+--------->| | |
| | RESPONSE | |
| +--------->| |
| | | RESPONSE |
| | +--------->|
| | | |
Figure 8: Basic Receiver-Initiated ReservationGIST carries the QUERY to the next downstream QoS NSLP node 🧚 there, the QoS NSLP processing picks it up and examines it 👀 the QoS model in use shapes the processing, which may also include gathering info on path characteristics that could help predict the end-to-end QoS 🔮
the QNE then generates a new QUERY, usually based on the one it got 💅 GIST forwards it to the next QNE 🦋 the same thing repeats at more QNEs along the path, all the way to the flow receiver 🌸 the receiver notices the QUERY carries the RESERVE-INIT flag, and uses the info in the QUERY (like the QSPEC) to build a RESERVE message 🎀
the RESERVE goes peer-to-peer back along the reverse of the path the QUERY took (using GIST reverse-path state) 🔙 just like the sender-initiated version, any node can put an RII into its RESERVE messages 💖 a RESPONSE then gets sent back to confirm the resources are set up ✅ and the reservation can be refreshed later with RESERVE messages going upstream 🫶
4.4. Bidirectional Reservations
"bidirectional reservation" is the name for two different cases that this spec supports 💜
- Binding two sender-initiated reservations together, e.g., one sender-initiated reservation from QNE A to QNE B and another one from QNE B to QNE A (Figure 9). 🦋
- Binding a sender-initiated and a receiver-initiated reservation together, e.g., a sender-initiated reservation from QNE A towards QNE B, and a receiver-initiated reservation from QNE A towards QNE B for the data flow in the opposite direction (from QNE B to QNE A). This case is especially handy when one end of the communication has everything it needs to set up both sessions (Figure 10). 🌈
both ends have to agree on which kind of bidirectional reservation they want to use 🤝 and yep, that negotiation can also happen through mechanisms outside the scope of NSIS 🫶
the two-sender-initiated scenario is in Figure 9 💅 RESERVE messages for both directions might visit different QNEs along the path because of asymmetric routing 🔀 both directions of the flows get bound together by inserting the BOUND-SESSION-ID object at the QNI and QNR 🔗 RESPONSE messages are optional and aren't shown in the picture, to keep things simple 🙈
A QNE QNE B
| | FLOW-1 | |
|===============================>|
|RESERVE-1 | | |
QNI+--------->|RESERVE-1 | |
| +-------------------->|QNR
| | | |
| | FLOW-2 | |
|<===============================|
| | |RESERVE-2 |
| RESERVE-2 |<---------+QNI
QNR|<--------------------+ |
| | | |
Figure 9: Bidirectional Reservation for Sender+Sender Scenariothe sender-plus-receiver scenario is in Figure 10 🧚 here QNI A sends out two RESERVE messages, one for the sender-initiated reservation and one for the receiver-initiated reservation 💜 the two RESERVE messages can be interleaved, so the order might get mixed up 🌀
A QNE QNE B
| | FLOW-1 | |
|===============================>|
|RESERVE-1 | | |
QNI+--------->|RESERVE-1 | |
| +-------------------->|QNR
| | | |
| | FLOW-2 | |
|<===============================|
| | | QUERY-2 |
| | QUERY-2 |<---------+QNR
QNI|<--------------------+ |
| | | |
|RESERVE-2 | | |
QNI+--------->|RESERVE-2 | |
| +-------------------->|QNR
| | | |
Figure 10: Bidirectional Reservation for Sender+Receiver Scenario4.5. Aggregate Reservations ✨
okay so bestie, to cut down on signaling and per-flow state in the network, the reservations for a bunch of flows can get bundled together 🫶 it's giving tidy, no cap 💅
QNI QNE QNE/QNI' QNE' QNR'/QNE QNR
aggregator deaggregator
| | | | | |
| RESERVE | | | | |
+--------->| | | | |
| | RESERVE | | | |
| +--------->| | | |
| | | RESERVE | | |
| | +-------------------->| |
| | | RESERVE' | | |
| | +=========>| RESERVE' | |
| | | +=========>| RESERVE |
| | | | +--------->|
| | | | RESPONSE'| |
| | | RESPONSE'|<=========+ |
| | |<=========+ | |
| | | | | RESPONSE |
| | | | RESPONSE |<---------+
| | |<--------------------+ |
| | RESPONSE | | | |
| |<---------+ | | |
| RESPONSE | | | | |
|<---------+ | | | |
| | | | | |
| | | | | |Figure 11: Sender-Initiated Reservation with Aggregation
so the end-to-end per-flow reservation kicks off with the messages in Figure 11 labelled RESERVE 🦋
then at the aggregator, a reservation for the aggregated flow gets started (that's the RESERVE' in Figure 11) 🌸 it can use the same QoS model as the end-to-end reservation, but it's got an MRI identifying the aggregated flow (like a tunnel, for example) instead of the individual flows 🧚
this document does not specify how the QSPEC of the aggregate session can be derived from the QSPECs of the end-to-end sessions 🙈 that one's a mystery for another day, bestie
the messages used for signaling the individual reservations need to be marked so the intermediate routers won't inspect them 💜 the QoS NSLP follows a marking policy for this, and you can also check out RFC 3175 for more on it ✨
all the routers basically run the same algorithm for deciding which messages to process, so every message sits at aggregation level 0 👑 but here's the twist: messages get their aggregation level incremented when they enter an aggregation region, and decremented when they exit it 🌈 with this technique, the interior routers don't have to rewrite any RAO values 🎀 the aggregating and deaggregating routers, though, have to tell the interfaces and their aggregation levels apart, and they also do the message rewriting at those boundaries 💅
specifically, the Aggregator does the marking by changing the QoS NSLP default NSLPID value to a predefined NSLPID value (see Section 6.6) 🔥 once that's done, a RAO value can be uniquely derived from each predefined NSLPID 💖 the RAO doesn't have to have a one-to-one relationship with a specific NSLPID though, so no stress 🫶
Aggregator Deaggregator
+---+ +---+ +---+ +---+
|QNI|-----|QNE|-----|QNE|-----|QNR| aggregate
+---+ +---+ +---+ +---+ reservation
+---+ +---+ ..... ..... +---+ +---+
|QNI|-----|QNE|-----. .-----. .-----|QNE|-----|QNR| end-to-end
+---+ +---+ ..... ..... +---+ +---+ reservation
Figure 12: Reservation AggregationFigure 12: Reservation Aggregation
the deaggregator acts as the QNR for the aggregate reservation 🦋 session binding info carried in the RESERVE message lets the deaggregator link the end-to-end and aggregate reservations together, using the BOUND-SESSION-ID 🫶 that's the whole connection, periodt ✨
the key difference between this example and the one in Section 4.7.1 is that the flow identifier for the aggregate is expected to be different from the one for the end-to-end reservation 🌈 which means the aggregate reservation can be updated independently of the per-flow end-to-end reservations 💅 it's giving main character energy for the aggregate, iykyk 👑
4.6. Message Binding ✨
Okay bestie, so Section 4.5 showed how an aggregated end-to-end flow and an aggregate work together 🦋. For that scenario, and probably some others too, we need a way to sync up the signaling messages of different sessions 🫶. This is a big speed boost, because some message exchanges can kick off at the same time and get processed in parallel, until one message from a session needs another message from a different session before it can move on 🔥.
Here's an example. Figure 11 shows a case where adding a new reservation means the capacity of the encompassing aggregate has to go up first 💅. So the RESERVE (bound message) for the individual flow arriving at the deaggregator should wait until the RESERVE' (binding message) for the aggregate arrives successfully. Otherwise the individual flow can't join the existing aggregate and can't get admitted 😭. Another option is to increase the aggregate first and then reserve resources for a set of aggregated individual flows. In that case, the binding and synchronization between the RESERVE and RESERVE' messages isn't needed 🌸.
A message binding may be used, depending on the aggregator's policy 🧚. Here's how it goes: a QNE (aggregator QNI' in Figure 14) randomly generates a 128-bit MSG-ID (same rules apply as for generating a SESSION-ID) and includes it as a BOUND-MSG-ID object in the bound signaling message (RESERVE (1) in Figure 13). That bound message waits for the arrival of a related binding signaling message (RESERVE' (3) in Figure 13) that carries the matching MSG-ID object. The BOUND-SESSION-ID should also be set accordingly 🎀. Only one MSG-ID or BOUND-MSG-ID object per message is allowed 🙈. If the dependency between the two messages goes both ways, the Message_Binding_Type flag is SET (value is 1). Otherwise, it's UNSET. In most cases, an RII object must be included so a corresponding RESPONSE comes back 💜.
Depending on which one shows up first, the bound signaling message (RESERVE (1) in Figure 13) or the "triggering" binding signaling message (RESERVE' (3) in Figure 13), a few different situations can happen:
- The bound signaling message (RESERVE (1)) arrives first. The receiving QNE queues up the RESERVE (1) message for the matching session (probably after some pre-processing) 🍓. It also starts a MsgIDWait timer so it can throw the message away if the related "triggering" message (RESERVE' in Figure 13) never shows up ⏳. The timeout period for this timer SHOULD be set to the default retransmission timeout period (
QOSNSLP_REQUEST_RETRY). If a retransmitted RESERVE message arrives before the timeout, it just overrides the waiting message. The old one gets discarded, the new one is now waiting, and the MsgIDWait timer resets 🔄.
At the same time, the "triggering" message with a MSG-ID object carrying the same value as the BOUND-MSG-ID object is sent by the same initiating QNE (QNI' in Figure 13) ✨. The intermediate QNE' sees the MSG-ID object, figures out it isn't the endpoint for the session (QNR'), and simply forwards the message after normal processing 🚀. The receiving QNE (QNR'), which is the endpoint for the aggregate session (aka the deaggregator), reads the MSG-ID object and looks for a waiting message with a BOUND-MSG-ID of the same value whose waiting condition is now satisfied 👑. If RESERVE' (3) is processed successfully, the waiting RESERVE gets resumed, and the MsgIDWait timer stops as soon as the related RESERVE' arrives 🌈.
QNI QNE QNE/QNI' QNE' QNR'/QNE QNR
aggregator deaggregator
| | | | | |
| RESERVE | | | | |
+--------->| | | | |
| | RESERVE | | | |
| +--------->| | | |
| | | RESERVE | | |
| | | (1) | | |
| | +-------------------->| |
| | | RESERVE' | | |
| | | (2) | | |
| | +=========>| RESERVE' | |
| | | | (3) | |
| | | +=========>| RESERVE |
| | | | | (4) |
| | | | +--------->|
| | | | RESPONSE'| |
| | | RESPONSE'|<=========+ |
| | |<=========+ | |
| | | | | RESPONSE |
| | | | RESPONSE |<---------+
| | |<--------------------+ |
| | RESPONSE | | | |
| |<---------+ | | |
| RESPONSE | | | | |
|<---------+ | | | |
| | | | | |
| | | | | |(1): RESERVE: SESSION-ID=F, BOUND-MSG-ID=x, BOUND-SESSION-ID=A
(2)+(3): RESERVE': SESSION-ID=A, MSG-ID=x
(4): RESERVE: SESSION-ID=F (MSG-ID object was removed)Figure 13: Example for Using Message Binding
Several more cases need thinking about here 🧠:
- "Triggering message" (3) arrives before the waiting (bound) message (1). Here, how the triggering message gets handled depends on the Message_Binding_Type flag 🤔. If Message_Binding_Type is UNSET (value is 0), the triggering message can be processed normally, but the MSG-ID and the result (success or failure) should be saved for the waiting message. That way the RESPONSE' can be sent by the QNR' right away 💖. If the waiting message (1) finally shows up at the QNR', it can tell the waiting condition was already satisfied, because the triggering message got there first 🙌. If Message_Binding_Type is SET (value is 1), the triggering message reads the MSG-ID object and looks for the corresponding waiting message with a BOUND-MSG-ID of the same value. In this case that message hasn't arrived yet, so the triggering message starts a MsgIDWait timer to discard it in case the related message (RESERVE (1) in Figure 14) never arrives 😬. If RESERVE (1) is processed successfully, the waiting RESERVE' gets resumed, the MsgIDWait timer stops as soon as the related RESERVE arrives, and the QNR' can send the RESPONSE' towards the QNI' 🥳.
- The "triggering message" (3) never arrives at all 💀. This could be because of message loss (which causes a retransmission by the QNI' if the RII object is included) or because a reservation failed at an intermediate node (QNE' in the example). The MsgIDWait timeout then just discards the waiting message at QNR'. In this case, the QNR' MAY send a RESPONSE message towards the QNI to tell it the synchronization of the two messages failed 🥀.
- Retransmissions should use the same MSG-ID, because usually only one of the two related messages gets retransmitted 🔁. As mentioned above, retransmissions only happen if the RII object is set in the RESERVE. If a retransmitted message with a MSG-ID arrives while a bound message with the same MSG-ID is still waiting, the retransmitted message replaces the bound message 💅.
Here's the receiving node's setup 🗂️. Conceptually, there are two lists indexed by message IDs. One holds the IDs and results of triggering messages (the ones carrying a MSG-ID object), and the other holds the IDs and message contents of the bound waiting messages (the ones that carried a BOUND-MSG-ID). The first list gets used when a triggering message arrives before its bound message, and the second gets used when a bound message arrives before its triggering message 🫧.
4.7. Reduced-State or Stateless Interior Nodes 🧚♀️
This example uses a different QoS model inside a domain 🌷. It works together with GIST and NSLP functionality that lets the interior nodes skip storing GIST and QoS NSLP state. So the interior nodes only store the QSPEC-related reservation state, or even no state at all 🫧. This lets the QoS model do "reduced-state" operation, where reservation states with coarser granularity (e.g., per-class) get used, or "stateless" operation, where no QoS NSLP state is needed (or created) 💜. This is handy for things like measurement-based admission control schemes 📊.
The big difference between this example and using different QoS models in Section 4.5 is the transport characteristics of the reservation. In other words, GIST can be used in a different way for the edge-to-edge sessions and the hop-by-hop sessions 🦋. The reduced-state reservation can also be updated independently of the per-flow end-to-end reservations ✨.
4.7.1. Sender-Initiated Reservation ✨
okay so the QNI kicks things off by sending a RESERVE message (check out Figure 14 💅). At the QNEs on the edges of the stateless or reduced-state region, things work differently, and these nodes support two QoS models 🦋. At the ingress, the original RESERVE gets forwarded, but the stateless or reduced-state nodes ignore it. The ingress marks it by changing the QoS NSLP default NSLPID value to an NSLPID predefined value (see Section 4.6) 🎀. The egress must reassign the QoS NSLP default NSLPID value to the original end-to-end RESERVE message. There's an example of how this works in [RFC5977] 💖.
The egress node is the next QoS-NSLP hop for the end-to-end RESERVE. Reliable GIST transfer mode can be used between the ingress and the egress without needing GIST state in the interior 🧚. Then, at the egress node, the RESERVE gets forwarded normally ✨.
At the ingress, a second message called RESERVE' is also built (Figure 14). It uses a QoS model that fits a reduced-state or stateless style of operation, like the RMD per-hop reservation 🌸. Since the original RESERVE and RESERVE' messages are addressed the same way, RESERVE' also arrives at the same egress QNE that RESERVE went through. Message binding is used to synchronize the two messages 🫶.
When interior (stateless) nodes process these messages, the QoS NSLP uses its options to avoid keeping state wherever possible, so no per-flow QoS NSLP state gets stored. Some state, e.g., per class, for the QSPEC-related data may be held at these interior nodes. The QoS NSLP also asks GIST to use different transport characteristics (e.g., sending messages in unreliable GIST transfer mode) 🔥. It also asks the local GIST processing not to retain messaging association state or reverse message routing state 🙈.
Nodes in the interior of the stateless or reduced-state domain that don't retain reservation state can't send back RESPONSE messages, so they can't use the refresh reduction extension either 💀.
At the egress node, RESERVE' is interpreted together with the reservation state from the end-to-end RESERVE. It uses information carried in the message to correlate the signaling flows 👑. RESERVE is only forwarded further if processing RESERVE' was successful at all nodes in the local domain. Otherwise, the end-to-end reservation is treated as having failed to be installed. This can be done with the message binding functionality from Section 4.6, which synchronizes the arrival of the bound signaling message (the end-to-end RESERVE) and the binding signaling message (the local RESERVE') 🦋.
QNE QNE QNE QNE
ingress interior interior egress
GIST stateful GIST stateless GIST stateless GIST stateful
| A B |
RESERVE | | | |
-------->| RESERVE | | |
+--------------------------------------------->|
| RESERVE' | | |
+-------------->| | |
| | RESERVE' | |
| +-------------->| |
| | | RESERVE' |
| | +------------->|
| | | RESPONSE' |
|<---------------------------------------------+
| | | | RESERVE
| | | +-------->
| | | | RESPONSE
| | | |<--------
| | | RESPONSE |
|<---------------------------------------------+
RESPONSE| | | |
<--------| | | |
Figure 14: Sender-Initiated Reservation with Reduced-State Interior
NodesResource management errors in the example above show up in the QSPEC and QoS model processing. For example, if RESERVE' fails at QNE A, it can't send an error message back to the ingress QNE. So RESERVE' is forwarded along the intended path, but the QSPEC includes information telling subsequent QNEs that an error happened upstream 😭. The QoS model decides what to do about it. Eventually, RESERVE' reaches the egress QNE, and the QoS model determines the response there too 💅.
4.7.2. Receiver-Initiated Reservation 🌈
Since NSLP neighbor relationships aren't maintained in the reduced-state region, only sender-initiated signaling can be supported inside it. If a receiver-initiated reservation over a stateless or reduced-state domain is required, it can be implemented as shown in Figure 15 🧚.
QNE QNE QNE
ingress interior egress
GIST stateful GIST stateless GIST stateful
| | |
QUERY | | |
-------->| QUERY | |
+------------------------------>|
| | | QUERY
| | +-------->
| | | RESERVE
| | |<--------
| | RESERVE |
|<------------------------------+
| RESERVE' | RESERVE' |
|-------------->|-------------->|
| | RESPONSE' |
|<------------------------------+
RESERVE | | |
<--------| | |
Figure 15: Receiver-Initiated Reservation with Reduced-State Interior
NodesThe RESERVE message received by the egress QNE of the stateless domain is sent transparently to the ingress QNE, which is known as the source of the QUERY message. When RESERVE reaches the ingress, the ingress QNE needs to send a sender-initiated RESERVE' over the stateless domain. The ingress QNE needs to wait for a RESPONSE'. If RESPONSE' says the reservation was accomplished successfully, then the ingress QNE sends a RESERVE message further upstream 🎀.
4.8. Proxy Mode 🫧
Besides sender- and receiver-initiated reservations, QoS NSLP has a feature we call Proxy Mode. Here a QNE is set by administrator assignment to work as a proxy QNE (P-QNE) for a certain region, e.g., for an administrative domain. A node initiating the signaling may set the PROXY scope flag to show that the signaling is meant to stay confined to the area controlled by the proxy, e.g., the local access network 🏡.
Proxy Mode has two uses. First, it lets QoS NSLP signaling be confined to a pre-defined section of the path. Second, it lets a node make reservations for an incoming data flow 💜.
For outgoing data flows and sender-initiated reservations, the end host is the QNI, and it sends a RESERVE with the PROXY scope flag set. The P-QNE is the QNR. It receives the RESERVE, notices the PROXY scope flag is set, and replies with a RESPONSE (if requested). This operation is the same as illustrated in Figure 7. The receiver-oriented reservation for outgoing flows works the same way as in Figure 8, except that the P-QNE is the QNI 🦋.
For incoming data flows, the end host is the QNI, and it sends a RESERVE towards the data sender with the PROXY scope flag set. Here the end host sets the MRI so that it indicates the end host as the receiver of the data, and sets the D-flag 🍓.
GIST is able to send messages towards the data sender if there is existing message routing state, or if it can use the Upstream Q-mode Encapsulation. Sometimes GIST can't determine the appropriate next hop for the message, so it indicates a failure to deliver it by sending an error message. This may happen, for example, if GIST tries to determine an upstream next hop and there are multiple possible inbound routes that could be used 🙃.
Bidirectional reservations can be used, as discussed in Section 4.4. The P-QNE will be the QNR or QNI for reservations ✨.
If the PROXY scope flag is set in an incoming QoS NSLP message, the QNE must set the same flag in all QoS NSLP messages it sends that are related to this session 🔒.
5. QoS NSLP Functional Specification 👑
5.1. QoS NSLP Message and Object Formats
A QoS NSLP message is made of a common header, followed by a body that consists of a variable number of variable-length, typed "objects" 📦. The common header and the other objects are encapsulated together in a GIST NSLP-Data object. The following subsections define the formats of the common header and each of the QoS NSLP message types. In the message formats, the common header is denoted as COMMON-HEADER 💅.
For each QoS NSLP message type, there is a set of rules for the permissible choice of object types. These rules are specified using the Augmented Backus-Naur Form (ABNF) specified in RFC 5234 [RFC5234] 🤓. The ABNF implies an order for the objects in a message. However, in many (but not all) cases, object order makes no logical difference. An implementation SHOULD create messages with the objects in the order shown here, but MUST accept the objects in any order 🫶.
5.1.1. Common Header 🎀
okay so every GIST NSLP-Data object for the QoS NSLP MUST start with this common header in its first 32 bits 💖 (and no, this is NOT the same thing as the GIST Common Header, so don't mix them up 💀). 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message Type | Message Flags | Generic Flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+So the fields in the common header go like this:
- Msg Type (8 bits) 🦋 the message type is one of:
1 = RESERVE2 = QUERY3 = RESPONSE4 = NOTIFY
- Message-specific flags (8 bits) 🌸 these get defined as part of each individual message's spec, so they're different for every message type.
- Generic flags (16 bits) 💜 these mean the same thing for every message type. There are currently four of them: the (next hop) Scoping flag (S), the Proxy scope flag (P), the Acknowledgement Requested flag (A), and the Break flag (B).
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved |B|A|P|S|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+SCOPING (S) ✨ when set, the message is scoped, so it shouldn't travel down the entire path. It only goes as far as the next QNE (scope="next hop"). By default this flag is not set (default scope="whole path").
PROXY (P) 🧚 when set, the message is scoped too, and it shouldn't travel the whole path. It only goes as far as the P-QNE. By default this flag is not set.
ACK-REQ (A) 🙈 when set, the receiving peer should acknowledge the message. This flag is only used between stateful peers, and only with RESERVE and QUERY messages. Right now it's only used with refresh messages. By default the flag is not set.
BREAK (B) 💀 when set, it means there are routers along the path where QoS can't be provided. 😭
The set of appropriate flags depends on the specific message being processed, so the bits you can use change depending on the message. Any bit that isn't defined as a flag for a particular message MUST be set to zero on sending and MUST be ignored on receiving. Bestie, that's a whole vibe check on the bits 💅
The ACK-REQ flag is useful when a QNE wants to make sure its downstream QNE actually processed the messages with the QoS NSLP, not just got them delivered by GIST. It's a faster way to do dead peer detection on the NSLP layer 🔥 This liveliness test can only be used with refresh RESERVE messages. The ACK-REQ flag must not be set for RESERVE messages that already include an RII object, since a confirmation has already been requested from the QNR. Reliable transmission between two QoS NSLP peers should be handled by GIST, not the NSLP by itself. Not the NSLP doing it solo, periodt 👑
5.1.2. Message Formats 🌈
5.1.2.1. RESERVE 🍓
The format of a RESERVE message looks like this:
RESERVE = COMMON-HEADER
RSN [ RII ] [ REFRESH-PERIOD ] [ *BOUND-SESSION-ID ]
[ SESSION-ID-LIST [ RSN-LIST ] ]
[ MSG-ID / BOUND-MSG-ID ] [ INFO-SPEC ]
[ [ PACKET-CLASSIFIER ] QSPEC ]The RSN is the only mandatory object, and it MUST always be present in all cases, no exceptions 😤 A QSPEC MUST be included in the initial RESERVE sent towards the QNR. A PACKET-CLASSIFIER MAY be provided. If the PACKET-CLASSIFIER isn't provided, then the full set of info in the GIST MRI for the session should be used for packet classification purposes.
Subsequent RESERVE messages that are meant as reduced refreshes, where no QSPEC is provided, MUST NOT include a PACKET-CLASSIFIER either. Keep it lean, bestie ✨
There are no requirements on transmission order, although the above order is recommended.
Two message-specific flags are defined for use in the common header with the RESERVE message:
+-+-+-+-+-+-+-+-+
|Reserved |T|R|
+-+-+-+-+-+-+-+-+TEAR (T) 💔 when set, the reservation state and QoS NSLP operation state should be torn down. The reservation state part gets indicated to the RMF. Depending on the QoS model, the tear message may include a QSPEC to further specify the state removal. For example, for an aggregation, the QSPEC may specify how many resources should be removed from the aggregate.
REPLACE (R) 🔄 when set, this flag does two jobs. First, it indicates that a RESERVE with a different MRI (but the same SID) replaces an existing one, so the old one MAY be torn down immediately. This is the default situation. This flag may be unset to show that an upstream node wants to keep an existing reservation on an old branch in place. Second, this flag also tells whether the reserved resources on the old branch should be torn down when a data path change happens. In that case the MRI stays the same and only the route path changes. Two jobs, one flag, iconic 🦋
If the REFRESH-PERIOD isn't present, a default value of 30 seconds is assumed.
If the session of this message is bound to another session, then the RESERVE message MUST include the SESSION-ID of that other session in a BOUND-SESSION-ID object. In the situation of aggregated tunnels, the aggregated session MAY not include the SESSION-ID of its bound sessions in BOUND-SESSION-ID(s). Aggregated tunnels being a little extra, not gonna lie 🫶
The negotiation of whether to do sender- or receiver-initiated signaling happens outside the QoS NSLP. Yet, in theory, a "reservation collision" can happen if the sender thinks a sender-initiated reservation should happen for a flow, while the other end thinks it should start a receiver-initiated reservation. If different session identifiers are used, then this error is transparent to the QoS NSLP, though it may result in an error from the RMF. Otherwise, the removal of the duplicate reservation is left to the QNIs/QNRs for the two sessions. Messy, but it's giving "not my problem, but also kinda my problem" 😭
If a reservation is already installed and a RESERVE message arrives with the same session identifier from the other direction (so, going upstream where the reservation was installed by a downstream RESERVE message, or vice versa), then an error indicating "RESERVE received from wrong direction" MUST be sent in a RESPONSE message to the signaling message source for this second RESERVE. Wrong direction, wrong vibes 🙅♀️
A refresh right along the path can be forced by requesting a RESPONSE from the far end (so, by including an RII object in the RESERVE message). Without this, a refresh RESERVE wouldn't trigger RESERVE messages to be sent further along the path, since each hop has its own refresh timer 🕰️
A QNE may ask for confirmation of a tear operation by including an RII object. QoS NSLP retransmissions SHOULD be disabled. A QNE sending a tearing RESERVE with an RII included MAY ask GIST to use reliable transport. Once the QNE sends out a tearing RESERVE, it MUST NOT send refresh messages anymore. Goodbye refreshes, it's been real 👋
If the routing path changed because of mobility, and the mobile node's IP address changed and it sent a Mobile IP binding update, then the resulting refresh is a new RESERVE. This RESERVE includes a new MRI and gets propagated end-to-end, so there's no need to force end-to-end forwarding by including an RII. Mobility, but make it smooth 🧚
Note: It's possible for a host to use this mechanism to constantly force the QNEs on the path to send refreshing RESERVE messages. So it may, therefore, be appropriate for QNEs to rate-limit the refresh messages that they send. Don't be the spammy host, bestie 🙈
5.1.2.2. QUERY 🔍
The format of a QUERY message looks like this:
QUERY = COMMON-HEADER
[ RII ] [ *BOUND-SESSION-ID ]
[ PACKET-CLASSIFIER ] [ INFO-SPEC ] QSPEC [ QSPEC ]QUERY messages MUST always include a QSPEC. QUERY messages MAY include a PACKET-CLASSIFIER when the message is used to trigger a receiver-initiated reservation. If a PACKET-CLASSIFIER isn't included, then the full GIST MRI should be used for packet classification purposes in the subsequent RESERVE. A QUERY message MAY contain a second QSPEC object. Two QSPECs, we love a plus-one 💅
A QUERY message asking for info about network resources MUST contain an RII object so the incoming RESPONSE can be matched to the QUERY. Matchmaking energy 💘
The QSPEC object describes what's being queried for, and it may contain objects that gather info along the data path. There are no requirements on transmission order, although the above order is recommended.
One message-specific flag is defined for use in the common header with the QUERY message:
+-+-+-+-+-+-+-+-+
|Reserved |R|
+-+-+-+-+-+-+-+-+RESERVE-INIT (R) 🚀 when this is set, the QUERY is meant as a trigger for the recipient to make a resource reservation by sending a RESERVE. Basically, "hey, go reserve something, please" 🥹
If the session of this message is bound to another session, then the RESERVE message MUST include the SESSION-ID of that other session in a BOUND-SESSION-ID object. In the situation of aggregated tunnels, the aggregated session MAY not include the SESSION-ID of its bound sessions in BOUND-SESSION-ID(s).
5.1.2.3. RESPONSE 💌
The format of a RESPONSE message looks like this:
RESPONSE = COMMON-HEADER
[ RII / RSN ] INFO-SPEC [SESSION-ID-LIST [ RSN-LIST ] ]
[ QSPEC ]A RESPONSE message MUST contain an INFO-SPEC object that indicates whether a reservation installation succeeded or there's an error condition. Depending on the value of the INFO-SPEC, the RESPONSE MAY also contain a QSPEC object. The value of an RII or an RSN object was provided by some previous QNE. There are no requirements on transmission order, although the above order is recommended.
No message-specific flags are defined for use in the common header with the RESPONSE message. Nothing extra here, just vibes 🌸
5.1.2.4. NOTIFY 🔔
The format of a NOTIFY message looks like this:
NOTIFY = COMMON-HEADER
INFO-SPEC [ QSPEC ]A NOTIFY message MUST contain an INFO-SPEC object indicating the reason for the notification. Depending on the INFO-SPEC value, it MAY contain a QSPEC object that provides additional info.
No message-specific flags are defined for use with the NOTIFY message. Same energy as RESPONSE, no extra flags needed 🫶
5.1.3. Object Formats
Okay so, the QoS NSLP uses a Type-Length-Value (TLV) object format that's basically a cousin of GIST's, and it's giving consistency 💅 Every object is one or more 32-bit words with a one-word header. Here's the standard object header, bestie:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|A|B|r|r| Type |r|r|r|r| Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+The Type value comes from the shared NSLP object type space, and each object gets its own section below 🎀 The Length field is measured in 32-bit words and counts the Value part only. The standard header is NOT included in that count, so don't double up 🙈
The bits labeled A and B are the flags that decide what happens to an object whose treatment hasn't been defined yet, aka when its Type is unknown to the receiver. There are four categories, and they're lowkey the most important part of this whole section 🔥
- AB=00 ("Mandatory"): If the object is not understood, the entire message containing it MUST be rejected, and an error message sent back.
- AB=01 ("Ignore"): If the object is not understood, it MUST be deleted and the rest of the message processed as usual.
- AB=10 ("Forward"): If the object is not understood, it MUST be retained unchanged in any message forwarded as a result of message processing, but not stored locally.
- AB=11 ("Refresh"): If the object is not understood, it should be incorporated into the locally stored QoS NSLP signaling application operational state for this flow/session, forwarded in any resulting message, and also used in any refresh or repair message that is generated locally. The contents of this object does not need to be interpreted, and should only be stored as bytes on the QNE.
The r bits are reserved. These SHALL be set to 0 and SHALL be ignored on reception, no cap 🧚 The AB flags are similar to the ones GIST uses. Every object defined in this specification MUST be understood by all QNEs, so they MUST have the AB-bits set to "00". Also, a QoS NSLP implementation must recognize objects of the following types: RII, RSN, REFRESH-PERIOD, BOUND-SESSION-ID, INFO-SPEC, and QSPEC. That's the core squad 👑
The object header is followed by a Value field, and it changes depending on the object. The format for each currently defined object is below. Quick heads up: the diagrams use // to show a variable-sized field ✨
5.1.3.1. Request Identification Information (RII)
Type: 0x001
Length: Fixed - 1 32-bit word
Value: An identifier that MUST be (probabilistically) unique within the context of a SESSION-ID and SHOULD be different every time a RESPONSE is desired. A QNE uses it to match a RESPONSE back to the request in a RESERVE or QUERY message. It's giving detective energy 🕵️♀️
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Request Identification Information (RII) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+5.1.3.2. Reservation Sequence Number (RSN)
Type: 0x002
Length: Fixed - 2 32-bit words
Value: An incrementing sequence number that shows the order in which state-modifying actions are performed by a QNE, plus an epoch identifier so peer restarts can be spotted 🦋 The RSN only has local significance, meaning it only matters between a QNE and its downstream stateful peers. The RSN is NOT reset when the downstream peer changes, so it keeps counting like a legend 📈
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reservation Sequence Number (RSN) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Epoch Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+5.1.3.3. Refresh Period (REFRESH-PERIOD)
Type: 0x003
Length: Fixed - 1 32-bit word
Value: The refresh timeout period R used to generate this message, in milliseconds ⏰
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Refresh Period (R) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+5.1.3.4. Bound Session ID (BOUND-SESSION-ID)
Type: 0x004
Length: Fixed - 5 32-bit words
Value: This one has an 8-bit Binding_Code that tells you the nature of the binding. The rest of it holds the SESSION-ID (as specified in GIST [RFC5971]) of the session that MUST be bound to the session associated with the message carrying this object. Bestie, this is a relationship status object 💜
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RESERVED | Binding Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Session ID +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+The currently defined Binding Codes are:
0x01- Tunnel and end-to-end sessions0x02- Bidirectional sessions0x03- Aggregate sessions0x04- Dependent sessions (binding session is alive only if the other session is also alive)0x05- Indicated session caused preemption
More binding codes MAY be defined based on the above five atomic binding actions. Note that a message may include more than one BOUND-SESSION-ID object. This could be needed if you want to be more specific about why the binding exists, or if a session depends on more than one other session (maybe for different reasons) 🫶 Also, a session with, e.g., SID_A (the binding session) can express a one-way dependency on another session, e.g., SID_B (the bound session), by including a BOUND-SESSION-ID object containing SID_B in its messages.
5.1.3.5. Packet Classifier (PACKET-CLASSIFIER)
Type: 0x005
Length: Variable
Value: Contains variable-length MRM-specific data 🌈
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// Method-specific classifier data (variable) //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Right now, the QoS NSLP only uses the path-coupled routing MRM. The method-specific classifier data is four bytes long and is a set of flags:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|X|Y|P|T|F|S|A|B| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+-+-+-+-+-+-+-+The flags are:
- X - Source Address and Prefix
- Y - Destination Address and Prefix
- P - Protocol
- T - Diffserv Code Point
- F - Flow Label
- S - SPI
- A - Source Port
- B - Destination Port
The flags indicate which fields from the MRI MUST be used by the packet classifier. This lets you use just a subset of the MRI info to pick out the packets that belong to the reservation 🎯 Flags MUST only be set if the data is present in the MRI. In other words, where there's a matching flag in the GIST MRI, the flag can only be set if that GIST MRI flag is set too. Also, it should be noted that some flags in the PACKET-CLASSIFIER (X and Y) are about data that's always in the MRI, but using them for QoS NSLP packet classification is optional. Which flags you set may depend, to some extent, on the QoS model being used 💅
As mentioned earlier in this section, the QoS NSLP is currently only defined for use with the Path-Coupled Message Routing Method (MRM) in GIST. Future work may extend the QoS NSLP to additional routing mechanisms. Any MRM like that must include enough information in the MRI so the subset of packets that should get QoS can be identified 🧠 When the QoS NSLP gets extended to support a new MRM, appropriate method-specific classifier data for the PACKET-CLASSIFIER object MUST be defined. ✨
5.1.3.6. Information Object (INFO-SPEC) and Error Codes
OKAY so this is the error-report object, and it's giving detective energy 🕵️♀️✨ It tells you WHAT went wrong, WHO noticed, and sometimes WHERE the bad bit was hiding. 🎀
Type: 0x006
Length: Variable
Value: Okay bestie, here's the layout: 8 reserved bits, then an 8-bit error code, a 4-bit error class, a 4-bit error source identifier type, and an 8-bit error source identifier length (counted in 32-bit words). After that comes the error source identifier itself, and optionally some extra error-specific info at the end. 💅
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | Error Code |E-Class|ESI Typ| ESI-Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// Error Source Identifier //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// Optional error-specific information //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Class Field:
The four E-Class bits tell you how severe the error is 🚨 The error classes that are defined right now are:
1- Informational2- Success3- Protocol Error4- Transient Failure5- Permanent Failure6- QoS Model Error
Error field:
Inside each error class there's a whole bunch of Error Code values 🌈 Here they all are, bestie:
- Informational:
0x01- Unknown BOUND-SESSION-ID: the message refers to an unknown SESSION-ID in its BOUND-SESSION-ID object.0x02- Route Change: possible route change occurred on downstream path.0x03- Reduced refreshes not supported; full QSPEC required.0x04- Congestion situation: Possible congestion situation occurred on downstream path.0x05- Unknown SESSION-ID in SESSION-ID-LIST.0x06- Mismatching RSN in RSN-LIST.
- Success:
0x01- Reservation successful0x02- Teardown successful0x03- Acknowledgement0x04- Refresh successful
- Protocol Error:
0x01- Illegal message type: the type given in the Message Type field of the common header is unknown.0x02- Wrong message length: the length given for the message does not match the length of the message data.0x03- Bad flags value: an undefined flag or combination of flags was set in the generic flags.0x04- Bad flags value: an undefined flag or combination of flags was set in the message-specific flags.0x05- Mandatory object missing: an object required in a message of this type was missing.0x06- Illegal object present: an object was present that must not be used in a message of this type.0x07- Unknown object present: an object of an unknown type was present in the message.0x08- Wrong object length: the length given for the object did not match the length of the object data present.0x09- RESERVE received from wrong direction.0x0a- Unknown object field value: a field in an object had an unknown value.0x0b- Duplicate object present.0x0c- Malformed QSPEC.0x0d- Unknown MRI.0x0e- Erroneous value in the TLV object's value field.0x0f- Incompatible QSPEC.
- Transient Failure:
0x01- No GIST reverse-path forwarding state0x02- No path state for RESERVE, when doing a receiver-oriented reservation0x03- RII conflict0x04- Full QSPEC required0x05- Mismatch synchronization between end-to-end RESERVE and intra-domain RESERVE0x06- Reservation preempted0x07- Reservation failure0x08- Path truncated - Next peer dead
- Permanent Failure:
0x01- Internal or system error0x02- Authorization failure
- QoS Model Error:
This error class is for QoS models to add their own error codes. Everything in here is created outside the QoS NSLP itself, and the codes are defined in QoS model specifications. Heads up, this class can also hold codes that aren't really errors, just some non-fatal info 🦋
Error Source Identifier (ESI)
The Error Source Identifier is for diagnostic purposes, and including it is OPTIONAL 🧚 The suggestion is that implementations put the IP address, host name, or some other identifier of the QNE that generated the INFO-SPEC in here, so debugging is easier. A QNE SHOULD NOT use it for anything except error logging or showing it to a user as diagnostic info 🙈 And a QNE SHOULD NOT try to send a message to that address. Not cute.
If no Error Source Identifier is included, the Error Source Identifier Type field must be zero.
Right now there are three Error Source Identifiers defined: IPv4, IPv6, and FQDN 💜
Error Source Identifier: IPv4
Error Source Identifier Type: 0x1
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 32-bit IPv4 address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Error Source Identifier: IPv6
Error Source Identifier Type: 0x2
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ 128-bit IPv6 address +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Error Source Identifier: FQDN in UTF-8
Error Source Identifier Type: 0x3
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// FQDN //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+If the FQDN length isn't a multiple of 32 bits, the field gets padded with zero octets up to the next 32-bit boundary 🎀
If a QNE runs into protocol errors, it MAY include additional information, mostly for diagnostics 🔍 That extra info MAY be included if the type of an object is wrong, or if a field has a wrong value.
If the type of an object is wrong, you can tack on this optional error-specific info at the end of the INFO-SPEC:
Object Type Info:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Object Type | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+This object tells you what type of object caused the error 🕵️♀️
If a field in an object had an incorrect value, you can add this optional error-specific info at the end of the INFO-SPEC:
Object Value Info:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Rsvd | Real Object Length | Offset |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// Object //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- Real Object Length: The length in the original TLV header might be inaccurate, so this field gives the actual length of the object (including the TLV Header) that's in the error message 🧮
- Offset: Says which part of the bad object is included. When this field is set to "0", the whole object is included. If Offset is bigger than "0", the bad object from that offset (counted from the start of the object) to the end of the object is included.
- Object: The invalid TLV object (including the TLV Header).
This object carries info about a TLV object that turned out to be invalid in the original message. An error message can have more than one Object Value Info object in it 💖
5.1.3.7. SESSION-ID List (SESSION-ID-LIST)
Type: 0x007
Length: Variable
Value: A list of 128-bit SESSION-IDs, used in summary refresh and summary tear messages 🦋 All the SESSION-IDs get concatenated together, no gaps.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Session ID 1 +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Session ID n +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+5.1.3.8. Reservation Sequence Number (RSN) List (RSN-LIST)
Type: 0x008
Length: Variable
Value: A list of 32-bit Reservation Sequence Number (RSN) values 🌸 All the RSNs get concatenated together, so it's basically one big train of numbers 🚂
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Epoch Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reservation Sequence Number 1 (RSN1) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reservation Sequence Number n (RSNn) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+5.1.3.9. Message ID (MSG-ID) 🦋
Okay so this one is the Message ID object, and it's giving very "unique fingerprint" energy 🔍✨
Type: 0x009
Length: Fixed - 5 32-bit words
Value: It has a 1-bit Message_Binding_Type (D) that tells you the dependency relation of a message binding. The rest is a 128-bit randomly generated value that "uniquely" identifies this particular message 💜
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RESERVED |D|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Message ID +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+The Message Binding Codes are:
0- Unidirectional binding dependency1- Bidirectional binding dependency
5.1.3.10. Bound Message ID (BOUND-MSG-ID) 🎀
This one is the sister object, and it's lowkey iconic. It's also Type 0x00A and Length Fixed - 5 32-bit words 💅
Value: Same deal as before: a 1-bit Message_Binding_Type (D) that shows the dependency relation of a message binding, plus a 128-bit randomly generated value. This one refers to a Message ID in another message, so it's like a little pointer back to it 🧚
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RESERVED |D|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Bound Message ID +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+The Message Binding Codes are:
0- Unidirectional binding dependency1- Bidirectional binding dependency
5.1.3.11. QoS Specification (QSPEC) 🌈
Here's the QSPEC object, and it's the "what do you actually want" part 👑
Type: 0x00B
Length: Variable
Value: Variable-length QSPEC (QoS specification) information, which depends on the QoS model.
The contents and encoding rules for this object are specified in other documents. See [RFC5975]. Not me going "other documents" again 😭
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
// QSPEC Data //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+5.2. General Processing Rules ✨
Okay, this part is the general rulebook for how QoS-NSLP handles stuff. The triggers passing between RM/QOSM and QoS-NSLP functionalities are listed in Appendices Appendix A.1, Appendix A.2, and Appendix A.3 📖
5.2.1. State Manipulation 💖
Processing a message and its component objects means manipulating the QoS NSLP and reservation state of a QNE. Literally the whole vibe 💅
For each flow, a QNE stores (RMF-related) reservation state that depends on:
- the QoS model / QSPEC used,
- the QoS NSLP operation state, which includes non-persistent state (e.g., the API parameters while a QNE is processing a message), and
- the persistent state, which is kept as long as the session is active.
The persistent QoS NSLP state is conceptually organized in a table with the following structure. The primary key (index) for the table is the SESSION-ID:
- SESSION-ID: a 128-bit identifier.
The state information for a given key includes:
- Flow ID: Based on GIST MRI. Several entries are possible in case of mobility events 🦋
- SII-Handle for each upstream and downstream peer: The SII-Handle is a local identifier generated by GIST and passed over the API. It's a handle that lets you refer to a particular GIST next hop. See SII-Handle in [RFC5971] for more information.
- RSN from the upstream peer: The RSN is a 32-bit counter.
- The latest local RSN: A 32-bit counter.
- List of RII for outstanding responses with processing information: The RII is a 32-bit number.
- State lifetime: This indicates how long the state being signaled for remains valid. ⏳
- List of bound sessions: A list of BOUND-SESSION-ID 128-bit identifiers for each session bound to this state.
- Scope of the signaling: If the Proxy scope is used, a flag is needed to identify all signaling of this session as being scoped.
Adding up the state requirements of all these items gives an upper bound on the state a QNE has to keep. How much state you actually need depends on the functionality you want at the NSLP layer 🧠
5.2.2. Message Forwarding 🌸
QoS NSLP messages are sent peer-to-peer along the path. The QoS NSLP doesn't have the concept of a message being sent directly to the end of the path. Instead, a QNE receives messages and may then send another message (which may be identical to the received one, or contain some subset of its objects) to keep going in the same direction (i.e., towards the QNI or QNR) as the message it received 🚀
Whether a QNE generates a message to forward may depend on the value of the SCOPING or PROXY flags, or on whether an RII object is present.
5.2.3. Standard Message Processing Rules 🎀
If a mandatory object is missing from a message, the receiving QNE MUST NOT propagate the message any further. It MUST construct a RESPONSE message indicating the error condition and send it back to the peer QNE that sent the message. No sending it forward when something's missing, bestie 🙅♀️
If a message contains an object of an unrecognised type, then the behavior depends on the AB extensibility flags.
If the Proxy scope flag was set in an incoming QoS NSLP message, the QNE must set the same flag in all QoS NSLP messages it sends that are related to this session 💜
5.2.4. Retransmissions 🔁
Retransmissions may happen end-to-end (e.g., between QNI and QNR using an RII object) or peer-to-peer (between two adjacent QNEs). When a QNE transmits a RESERVE with an RII object set, it waits for a RESPONSE from the responding QNE. QoS NSLP messages that ask for a response by including an RII object, but don't get one, are retransmitted. Similarly, a QNE may include the ACK-REQ flag to request confirmation of a refresh message reception from its immediate peer. The retransmitted message should be exactly the same as the original message, e.g., the RSN is not modified with each retransmission. Same message, same RSN, no glow-ups needed 💅
The initial retransmission occurs after a QOSNSLP_REQUEST_RETRY wait period. Retransmissions MUST be made with exponentially increasing wait intervals (doubling the wait each time). QoS NSLP messages SHOULD be retransmitted until either a RESPONSE (which might be an error) has been obtained, or until QOSNSLP_RETRY_MAX seconds after the initial transmission. In the latter case, a failure SHOULD be indicated to the signaling application 😭
The default values for the above-mentioned timers are:
QOSNSLP_REQUEST_RETRY: 2 seconds Wait interval before initial
retransmit of the message
QOSNSLP_RETRY_MAX: 30 seconds Period to retry sending the
message before giving upRetransmissions SHOULD be disabled for tear messages. 🙈
5.2.5. Rerouting 🛣️
5.2.5.1. Last Node Behavior 🧭
As discussed in Section 3.2.12, some care needs to be taken to handle cases where the last node on the path may change. Main character plot twist energy 🌈
A node that is the last node on the path, but not the data receiver (or an explicitly configured proxy for it), MUST continue to attempt to send messages downstream to probe for path changes. This must be done in order to handle the "Path Extension" case described in Section 5.2.5.1.
A node on the path, that was not previously the last node, MUST take over as the last node on the signaling path if GIST path change detection identifies that there are no further downstream nodes on the path. This must be done in order to handle the "Path Truncation" case described in Section 5.2.5.1. ✨
5.2.5.2. Avoiding Mistaken Teardown 🦋
In order to handle the spurious route change problem described in Section 3.2.12.2, the RSN must be used in a particular way when maintaining the reservation after a route change is believed to have occurred. Don't accidentally tear down a perfectly good reservation, babe 🫶
We assume that the current RSN (RSN[current]) is initially RSN0.
When a route change is believed to have occurred, the QNE SHOULD send a RESERVE message, including the full QSPEC. This must contain an RSN which is RSN[current] = RSN0 + 2. It SHOULD include an RII to request a response from the QNR. An SII-Handle MUST NOT be specified when passing this message over the API to GIST, so that the message is correctly routed to the new peer QNE.
When the QNE receives the RESPONSE message that relates to the RESERVE message sent down the new path, it SHOULD send a RESERVE message with the TEAR flag sent down the old path. To do so, it MUST request GIST to use its explicit routing mechanism, and the QoS NSLP MUST supply an SII-Handle relating to the old peer QNE. When sending this RESERVE message, it MUST contain an RSN that is RSN[current] - 1. (RSN[current] remains unchanged.) 🔄
If the RESPONSE received after sending the RESERVE down the new path contains the code "Refresh successful" in the INFO-SPEC, then the QNE MAY elect not to send the tearing RESERVE, since this indicates that the path is unchanged. Path's the same, so no tearing needed, periodt 💖
5.2.5.3. Upstream Route Change Notification 📣
GIST may notify the QoS NSLP that a possible upstream route change has occurred over the GIST API. On receiving such a notification, the QoS NSLP SHOULD send a NOTIFY message with Informational code 0x02 for signaling sessions associated with the identified MRI. If this is sent, it MUST be sent to the old peer using the GIST explicit routing mechanism through the use of the SII-Handle.
On receiving such a NOTIFY message, the QoS NSLP SHOULD use the InvalidateRoutingState API call to inform GIST that routing state may be out of date. The QoS NSLP SHOULD send a NOTIFY message upstream. The NOTIFY message should be propagated back to the QNI or QNR. 🌟
5.2.5.4. Route Change Oscillation 🦋
okay so sometimes a route change happens, but then the path just goes right back to the original route 🙃 the drama is real.
after a route change, the routers on the old path keep refreshing the reservation until the soft state times out or an explicit TEAR shows up. so the old path doesn't vanish right away, it just lingers 💀
after detecting an upstream route change, a QNE SHOULD consider the new upstream peer as current and not fall back to the old upstream peer unless:
- it stops receiving refreshes from the old upstream peer for at least the soft-state timeout period and then starts receiving messages from the old upstream peer again, or
- it stops receiving refreshes from the new upstream peer for at least the soft-state timeout period.
ngl, GIST routing state keeps track of the latest upstream peer it has seen, so it can spuriously suggest that route changes happened whenever the old upstream peer refreshes its routing state. this keeps going until the state at that node is explicitly torn down or times out 😭
5.3. Object Processing 🎀
this section is where we go over the processing rules for each individual QoS NSLP object. let's get into it 💅
5.3.1. Reservation Sequence Number (RSN) ✨
a QNE's own RSN is a sequence number for a particular signaling session (aka the one with a particular SESSION-ID). it MUST be incremented for each new RESERVE message where the reservation for the session changes. the RSN gets handled with the serial number arithmetic rules from [RFC1982], which also covers wrapping and what 'equals', 'less than', and 'greater than' mean when you're comparing sequence numbers in a circular sequence space. super circular, but make it make sense 🔄
the RSN starts at zero. it's stored as part of the per-session state, and it keeps counting up (so it is not reset to zero) when a downstream peer change happens. (quick note: Section 5.2.5.2 has some special rules for when a downstream peer changes 👀)
the RSN object also has an Epoch Identifier, which helps figure out when a peer has restarted (like after a node reboot or software restart) 🔁 how you produce this value is up to the implementation. options include storing a serial number that goes up on each restart, picking a random value on each restart, or using the restart time.
when a QNE gets a RESERVE message, it checks the Epoch Identifier to see if the sending peer has restarted. if the Epoch Identifier is different from the one stored for the reservation, the RESERVE message MUST be treated as an updated reservation (even if the RSN is less than the current stored value), and the stored RSN and Epoch Identifier MUST be updated to the new values. restart detected, reset the vibes 🌸
when a QNE receives a RESERVE message, it uses the RSN in the message to figure out whether the requested state is different from what's already stored. if the RSN equals the one stored for the current reservation, the current state MUST be refreshed. if the RSN is greater than the stored value, the current reservation MUST be modified as specified in the QSPEC (as long as admission control and policy control succeed), and the stored RSN gets updated to the one for the new reservation ✨ if the RSN is greater than the stored value and the RESERVE was a reduced refresh, the QNE SHOULD send a transient error message upstream saying "Full QSPEC required" 🙏 and if the RSN is less than the current value, that means it's an out-of-order message, so the RESERVE message MUST be discarded 🗑️
if the QNE doesn't store per-session state (so it doesn't keep any previous RSN values), it MAY ignore the RSN value. it MUST also copy the same RSN into any RESERVE message it sends as a result of receiving this one 🫶
5.3.2. Request Identification Information (RII) 🧚
a QNE that sends QUERY or RESERVE messages may need a response back. to ask for one, it includes a Request Identification Information (RII) object. when making an RII object, the QNE MUST pick a value that is probabilistically unique within the given session. usually the QNI sets the RII 💖
there are a few ways to do this. you could use a random value, or a node identifier together with a counter. if the value collides with one another QNE picked for a different QUERY, then RESPONSE messages might get terminated the wrong way and might not make it back to the node that asked for them 💀
the node that made the RII object MUST remember the value it used so it can match up any RESPONSE it gets back. it SHOULD use a timer to spot when it's been waiting too long for the expected RESPONSE. if the timer runs out without a RESPONSE, the node MAY do a retransmission like we talked about in Section 5.2.4. in that case, the QNE MUST NOT generate any RESPONSE or NOTIFY message to report this error 🙈
if an intermediate QNE wants a response for an outgoing message, but the message already had an RII when it arrived, the QNE MUST NOT add a new RII object or replace the old one. it just MUST remember this RII so it can match a later RESPONSE message. when the RESPONSE arrives, it gets forwarded upstream toward the node that started the RII 🦋 also, only the node that originally created the RII can set up a retransmission timer. so if an intermediate QNE decides to use the RII that's already in the message, it MUST NOT set up a retransmission timer, and instead relies on the retransmission timer set up by the QNE that inserted the RII. teamwork makes the dream work 🤝
when a node gets a message with an RII object, it MUST send a RESPONSE if any of these are true:
- The SCOPING flag is set ('next hop' scope),
- The PROXY scope flag is set and the QNE is the P-QNE, or
- This QNE is the last one on the path for the given session.
and the QNE keeps per-session state for the given session. (main character energy for this whole list ✨)
in the rare case where the QNE wants to request a response for a message that already had an RII, and that RII value clashes with an RII value the QNE already has, the node should stop processing the message, send an error message upstream to say there's an RII collision, and ask for a retry with a new RII value. yikes, but we handle it 🫠
5.3.3. BOUND-SESSION-ID 💜
like the examples in Section 4 show, the QoS NSLP can link multiple sessions together. it does this by putting the SESSION-ID from one session into a BOUND-SESSION-ID object in messages for another session 🔗
when a QNE gets a message with a BOUND-SESSION-ID object, it MUST copy that BOUND-SESSION-ID object into all the messages it sends for the same session. a QNE that stores per-session state MUST store the value of the BOUND-SESSION-ID 📝
the BOUND-SESSION-ID is only indicative in nature. still, a QNE implementation may use BOUND-SESSION-ID information to optimize resource allocation, for example for bidirectional reservations 🦋 when a QNE receives a teardown message (like a RESERVE message with teardown semantics) for an aggregate reservation, it may use this info to start a teardown for the end-to-end sessions bound to that aggregate. and a QoS NSLP implementation MUST be ready to process more than one BOUND-SESSION-ID object inside a single message. bestie, that's a lot of IDs in one message 😭
5.3.4. REFRESH-PERIOD 🌈
refresh timer management values are carried in the REFRESH-PERIOD object, which only has local significance. when a "refresh timeout" period expires, each QNE looks at its own state on its own and sends a refreshing RESERVE message to the next QNE peer, where it gets absorbed. this peer-to-peer refreshing (instead of the QNI starting a refresh that travels all the way to the QNR) lets QNEs pick refresh intervals that fit their environment 🎀 for example, refresh intervals in the backbone, where reservations are pretty stable, could be way bigger than the ones in an access network. the "refresh timeout" gets calculated inside the QNE and isn't part of the protocol. it does still have to be chosen to work with the reservation lifetime expressed by the REFRESH-PERIOD, and with a check on how reliable message delivery is ⏰
the details of timer management and timer changes (slew handling and so on) are the same as the ones in Section 3.7 of RFC 2205 [RFC2205] 🔁
there are two time parameters for each QoS NSLP state in a node: the refresh period R between the generation of successive refreshes for that state by the neighbor node, and the local state's lifetime L. each RESERVE message may contain a REFRESH-PERIOD object that says which R value was used to generate that (refresh) message. the R value is then used to work out the value of L when the state is received and stored. the values for R and L may vary from peer to peer 🫶
5.3.5. INFO-SPEC ✨
okay bestie, the INFO-SPEC object rides along in RESPONSE and NOTIFY messages, and its whole job is to report a successful, an unsuccessful, or an error situation 💅. In an error situation, error messages SHOULD be generated even if no RII object is included in the RESERVE or in the QUERY messages. Note that when the TEAR flag is set in the RESERVE message, an error situation SHOULD NOT trigger the generation of a RESPONSE message 🙈
There are six classes of INFO-SPEC objects, all identified and specified in Section 5.1.3.6 🦋. The message processing rules for each class are defined below 💖
A RESPONSE message MUST carry INFO-SPEC objects towards the QNI, and it MUST be forwarded unconditionally up to the QNI 🎀. What the QNI that receives the INFO-SPEC object SHOULD do is decided by the local policy of the QoS model this QNE supports. The default is that the QNI that receives the INFO-SPEC object SHOULD NOT trigger any other QoS NSLP procedure 🌸
Informational class: the Informational INFO-SPEC class MUST be generated by a stateful QoS NSLP QNE when an Informational error class is caught. It MUST be carried by a RESPONSE or a NOTIFY message 🧚
Success class: for a unidirectional reservation, the Success INFO-SPEC class MUST be generated by a stateful QoS NSLP QNR when a RESERVE message is received and the reservation state installation or refresh succeeded ✨ For a bidirectional reservation, the INFO-SPEC object SHOULD be generated by a stateful QoS NSLP QNE when a RESERVE message is received and the reservation state installation or refresh succeeded. The Success INFO-SPEC object MUST be carried by a RESPONSE or a NOTIFY message 🌈
Protocol Error class: for a unidirectional reservation, the Protocol Error INFO-SPEC class MUST be generated by a stateful QoS NSLP QNE when a RESERVE or QUERY message is received by the QNE and a protocol error is caught 🙈 For a bidirectional reservation, it SHOULD be generated by a stateful QoS NSLP QNE in that same situation. A RESPONSE message MUST carry this object, and it MUST be forwarded unconditionally towards the upstream QNE that generated the RESERVE or QUERY message that triggered the generation of this INFO-SPEC object 💅 The default action for a stateless QoS NSLP QNE that detects such an error is that none of the QoS NSLP objects SHOULD be processed, and the RESERVE or QUERY message SHOULD be forwarded downstream 🫶
Transient Failure class: for a unidirectional reservation, the Transient Failure INFO-SPEC class MUST be generated by a stateful QoS NSLP QNE when a RESERVE or QUERY message is received by the QNE and one Transient failure error code is caught, or when an event happens that causes a transient error 😭 For a bidirectional reservation, it SHOULD be generated by a stateful QoS NSLP QNE when a RESERVE or QUERY message is received by the QNE and one Transient failure error code is caught.
A RESPONSE message MUST carry this object, and it MUST be forwarded unconditionally towards the upstream QNE that generated the RESERVE or QUERY message that triggered the generation of this INFO-SPEC object 🎀 The transient RMF-related error MAY also be carried by a NOTIFY message. The default action is that the QNE that receives this INFO-SPEC object SHOULD re-trigger the retransmission of the RESERVE or QUERY message that triggered the generation of the INFO-SPEC object 🔥 The default action for a stateless QoS NSLP QNE that detects such an error is that none of the QoS NSLP objects SHOULD be processed and the RESERVE or QUERY message SHOULD be forwarded downstream.
Permanent Failure class: for a unidirectional reservation, the Permanent Failure INFO-SPEC class MUST be generated by a stateful QoS NSLP QNE when a RESERVE or QUERY message is received by a QNE and an internal or system error occurred, or authorization failed 💀 For a bidirectional reservation, it SHOULD be generated by a stateful QoS NSLP QNE when a RESERVE or QUERY message is received by a QNE and an internal or system error occurred, or authorization failed.
A RESPONSE message MUST carry this object, and it MUST be forwarded unconditionally towards the upstream QNE that generated the RESERVE or QUERY message that triggered this protocol error 👑 The internal, system, or permanent RMF-related errors MAY also be carried by a NOTIFY message. The default action for a stateless QoS NSLP QNE that detects such an error is that none of the QoS NSLP objects SHOULD be processed and the RESERVE or QUERY message SHOULD be forwarded downstream 🍓
QoS-specific error class: this class may be used when errors outside the QoS NSLP itself occur that are related to the particular QoS model being used. The processing rules for these errors are not specified in this document 🌸
5.3.6. SESSION-ID-LIST 🦋
A SESSION-ID-LIST is carried in RESERVE messages, and it does two jobs: refreshing or tearing down the indicated sessions 💜 It carries info about sessions that should be refreshed or torn down, on top of the main (primary) session indicated in the RESERVE.
If the primary SESSION-ID is not understood, the SESSION-ID-LIST object MUST NOT be processed 🙅
When a stateful QNE goes through the SESSION-ID-LIST and finds one or more unknown SESSION-ID values, it SHOULD construct an informational RESPONSE message back to the upstream stateful QNE. That message carries the error code for unknown SESSION-ID in SESSION-ID-LIST, and it includes all the unknown SESSION-IDs in a SESSION-ID-LIST 🫶
If the RESERVE is a tear, then for each session in the SESSION-ID-LIST, the stateful QNE MUST inform the RMF that the reservation is no longer required. RSN values MUST also be interpreted so it can tell whether the tear down is valid, or whether it refers to an old state and should be silently discarded 🥺
If the RESERVE is a refresh, the stateful QNE MUST also process the RSN-LIST object, which is detailed in the next section ✨
If the RESERVE is a tear, then for each session in the SESSION-ID-LIST, the QNE MUST inform the RMF that the reservation is no longer required. RSN values MUST be interpreted.
Note that a stateless QNE cannot support summary or single reduced refreshes, so it always needs full single refreshes 💅
5.3.7. RSN-LIST 🎀
An RSN-LIST MUST be carried in RESERVE messages when a QNE wants to perform a refresh or teardown of several sessions with a single NSLP message 🌈 The RSN-LIST object MUST be populated with RSN values of the same sessions, in the same order as the SESSION-ID-LIST. So entries at position X in both objects refer to the same session. It's giving matching lanes 🛣️
If the primary session and RSN reference in the RESERVE were not understood, the stateful QNE MUST NOT process the RSN-LIST. Instead, an error RESPONSE SHOULD be sent back to the upstream stateful QNE 🙈
On receiving an RSN-LIST object, the stateful QNE should check whether the number of items in the SESSION-ID-LIST and RSN-LIST objects match. If there is a mismatch, the stateful QNE SHOULD send back a protocol error indicating a bad value in the object 😭
While matching the RSN-LIST values to the SESSION-ID-LIST values, if one or more RSN values in the RSN-LIST are not in synch with the local values, the stateful QNE SHOULD construct an informational RESPONSE message with an error code for RSN mismatch in the RSN-LIST. The stateful QNE MUST include the erroneous SESSION-ID and RSN values in SESSION-ID-LIST and RSN-LIST objects in the RESPONSE 🔥
If no errors were found while processing the RSN-LIST, the stateful QNE refreshes the reservation states of all sessions: the primary single session indicated in the refresh, plus all sessions in the SESSION-ID-LIST 👑
For each successfully processed session in the RESERVE, the stateful QNE performs a refresh of the reservation state. So even if some sessions weren't in synch, the remaining sessions in the SESSION-ID-LIST and RSN-LIST still get refreshed 🧚
5.3.8. QSPEC 💖
The contents of the QSPEC depend on the QoS model being used, and a template for QSPEC objects can be found in [RFC5975] 🌸
When it's received, the complete QSPEC is passed to the Resource Management Function (RMF), along with other information from the message that the RMF needs for its processing 🦋 A QNE may also receive an INFO-SPEC that includes a partial or full QSPEC. That gets passed to the RMF too ✨
5.4. Message Processing Rules 🫶
This section provides rules for message processing. It doesn't consider every possible error situation 🙈 The general rule for erroneous messages is that a node should evaluate the situation before deciding how to react. There are two ways to react to erroneous messages:
- a) Silently drop the message, or
- b) Drop the message, and reply with an error code to the sender.
The default behavior, to protect the QNE from a possible denial-of-service attack, is to silently drop the message 🛡️ However, if the QNE is able to authenticate the sender (e.g., through GIST), the QNE may send a proper error message back to the neighbor QNE, to let it know there's an inconsistency in the states of adjacent QNEs 💜
5.4.1. RESERVE Messages 🎀
okay so the RESERVE message is the one that messes with QoS reservation state in QNEs 💅. A RESERVE can create, refresh, modify, or remove that state. A QNE sending a RESERVE MAY require a response to be sent by including a Request Identification Information (RII) object; see Section 5.3.2 ✨.
RESERVE messages MUST only be sent towards the QNR 🧚. A QNE that receives a RESERVE checks the message format. If the message is malformed, the QNE MAY send a RESPONSE message with the appropriate INFO-SPEC 🙈.
Before doing any state-changing actions, a QNE MUST determine whether the request is authorized 🔐. How it does that check depends on the authorization model being used.
When the RESERVE is authorized, a QNE checks the COMMON-HEADER flags 👀. If TEAR is set, the message is a tearing RESERVE, which means complete QoS NSLP state removal (as opposed to a reservation of zero resources) 💀. On receiving one, the QNE MUST inform the RMF that the reservation is no longer required. The RSN value MUST be processed. After that, there are two modes of operation:
- If the tearing RESERVE did not include an
RII, i.e., the QNI did not want a confirmation, the QNE SHOULD remove the QoS NSLP state. It MAY signal to GIST (over the API) that reverse-path state for this reservation is no longer required. Any errors in processing the tearing RESERVE SHOULD NOT be sent back towards the QNI, since the upstream QNEs will already have removed their session states, so they can't do anything about the error 😭. - If an
RIIwas included, the stateful QNE SHOULD still keep the NSLP operational state until a RESPONSE for the tear going towards the QNI is received. This operational state SHOULD be kept for one refresh interval, after which the NSLP operational state for the session is removed. Depending on the QoS model, the tear message MAY include aQSPECto further specify state removal. If the QoS model requires aQSPECand none is provided, the QNE SHOULD reply with an error message and SHOULD NOT remove the reservation 🫶.
If the tearing RESERVE includes a QSPEC but the QoS model doesn't require one, the QNE MAY silently discard the QSPEC and proceed as if it weren't in the message at all 🦋. Honestly, a QoS NSLP implementation should carefully consider when an error message should be sent and when not 🧐. If the tearing RESERVE did not include an RII, then the upstream QNE has removed the RMF and NSLP states, and it won't be able to do anything about the error. If an RII was included, the upstream QNE may still have the NSLP operational state, but no RMF state.
If a QNE gets a tearing RESERVE for a session where it still has the operational state but the RMF state was removed, the QNE SHOULD accept the message and forward it downstream as if all is well 🌸.
If the tearing RESERVE includes a SESSION-ID-LIST, the stateful QNE MUST process the object as described earlier in this document, and for each identified session, indicate to the RMF that the reservation is no longer required 📝.
If a QNE gets a refreshing RESERVE for a session where it still has the operational state but the RMF state was removed, the QNE MUST silently drop the message and not forward it downstream 🚫.
As discussed in Section 5.2.5.2, to avoid incorrect removal of state after a rerouting event, a node receiving a RESERVE message that has the TEAR flag set and that does not come from the current peer QNE (identified by its SII) MUST be ignored and MUST NOT be forwarded 🛑. Not it, bestie.
If the QNE has reservations that are bound and dependent on this session (they contain the SESSION-ID of this session in their BOUND-SESSION-ID object and use Binding Code 0x04), it MUST send a NOTIFY message for each of those reservations with an appropriate INFO-SPEC 🔗. If the QNE has reservations that are bound but not dependent on this session (the Binding Code in the BOUND-SESSION-ID object has one of the values 0x01, 0x02, or 0x03), it MAY send a NOTIFY message for each of them with an appropriate INFO-SPEC. The QNE MAY elect to send RESERVE messages with the TEAR flag set for these reservations.
The default behavior of a QNE that receives a RESERVE with a SESSION-ID it already has state for, but with a different flow ID, is to replace the existing reservation. If the RESERVE comes in with a different SII, it also tears down the reservation on the old branch 🔄.
Sometimes that isn't what you want, so the QNI or a QNE MAY set the REPLACE flag in the common header to zero, which signals that the new session does not replace the existing one 🙅♀️.
A QNE that receives a RESERVE with the REPLACE flag set to zero but with the same SII will indicate REPLACE=0 to the RMF, where it gets used for the resource handling. Also, if the QNE maintains a QoS NSLP state, it adds the new flow ID to that state too 🧩. If the SII is different, this means the QNE is a merge point. In that case, in addition to the operations above, the value REPLACE=0 also tells you that a tearing RESERVE SHOULD NOT be sent on the old branch 🌿.
When a QNE receives a RESERVE with an unknown SESSION-ID and the message has no QSPEC because it was meant as a refresh, the node MUST send a RESPONSE message with an INFO-SPEC that indicates a missing QSPEC to the upstream peer ("Full QSPEC required"). The upstream peer SHOULD send a complete RESERVE (one that contains a QSPEC) on the new path (new SII) 🥹.
At a QNE, resource handling is performed by the RMF. For sessions with the REPLACE flag set to zero, we assume the QoS model includes directions for dealing with resource sharing. That might mean adding the reservations, or taking the maximum of the two (or more complex mathematical operations) 🧮.
This resource-handling mechanism in the QoS model also applies to sessions that have different SESSION-IDs but are related through the BOUND-SESSION-ID object. Session replacement isn't an issue here, but the QoS model may specify whether or not the sessions bound together share resources on common links 🤝.
Finally, a RESERVE might come in with no QSPEC at all. That's a reduced refresh. Instead of sending a refreshing RESERVE with the full QSPEC, only the SESSION-ID and the RSN get sent to refresh the reservation. Note that this mechanism just reduces the message size (and probably eases processing) ✨. One RESERVE per session is still needed. A reduced refresh may also include a SESSION-ID-LIST and RSN-LIST, which indicate further sessions to be refreshed along with the primary session. The processing of these objects was described earlier in this document 📚.
If the REPLACE flag is set, the QNE SHOULD update the reservation state according to the QSPEC in the message. If the QSPEC is missing, the QNE SHOULD flag this error by replying with a RESPONSE containing the corresponding INFO-SPEC "Full QSPEC required". It MUST update the lifetime of the reservation ⏰. If the REPLACE flag is not set, a QNE SHOULD NOT remove the old reservation state if the SII passed by GIST over the API is different from the SII stored for this reservation. The QNE MAY elect to keep sending refreshing RESERVE messages 🔁.
If a stateful QoS NSLP QNE receives a RESERVE message with the BREAK flag set, then the BREAK flag of newly generated messages (e.g., RESERVE or RESPONSE) MUST be set 💥. When a stateful QoS NSLP QNE receives a RESERVE message with the BREAK flag not set, the IP-TTL and Original-TTL values in the GIST RecvMessage primitive MUST be monitored. If they differ, it is RECOMMENDED to set the BREAK flag in newly generated messages (e.g., RESERVE or RESPONSE). In situations where a QNE or a domain is able to provide QoS using other means (see Section 3.3.5), the BREAK flag SHOULD NOT be set 🌈.
If the RESERVE message included an RII, and any of the following are true, the QNE MUST send a RESPONSE message:
- If the QNE is configured, for a particular session, to be a QNR,
- the
SCOPINGflag is set, - the Proxy scope flag is set and the QNE is a P-QNE, or
- the QNE is the last QNE on the path to the destination.
When a QNE receives a RESERVE message, its processing may involve sending out another RESERVE message 📤.
If a QNE has received a RESPONSE mandating the use of full refreshes from its downstream peer for a session, the QNE MUST continue to use full refresh messages 🍓.
If the session of this message is bound to another session, the RESERVE message MUST include the SESSION-ID of that other session in a BOUND-SESSION-ID object. In the situation of aggregated tunnels, the aggregated session MAY not include the SESSION-ID of its bound sessions in BOUND-SESSION-ID(s) 🫧.
In the case of receiver-initiated reservations, the RESERVE message must follow the same path that the QUERY message followed. So GIST is informed, over the QoS NSLP/GIST API, to pass the message upstream, i.e., by setting GIST "D" flag; see GIST [RFC5971] 🧭.
The QNE MUST create a new RESERVE and send it to its next peer when:
- A new resource setup was done,
- A new resource setup was not done, but the QOSM still defines that a RESERVE must be propagated,
- The RESERVE is a refresh and includes a new MRI, or
- The
RESERVE-INITflag is included in an arrived QUERY.
If the QNE sent out a refresh RESERVE with the ACK-REQ flag set, and did not receive a RESPONSE from its immediate stateful peer within the retransmission period of QOSNSLP_RETRY_MAX, the QNE SHOULD send a NOTIFY to its immediate upstream stateful peer and indicate "Path truncated - Next peer dead" in the INFO-SPEC 🚨. The ACK-REQ flag SHOULD NOT be added to a RESERVE that already includes an RII object, since a confirmation from the QNR has already been requested 🙃.
Finally, if a received RESERVE requested acknowledgement through the ACK-REQ flag in the COMMON HEADER flags and the message was processed successfully, the stateful QNE SHOULD send back a RESPONSE with an INFO-SPEC carrying the acknowledgement success code. The QNE MAY include the ACK-REQ flag in the next refresh message it sends for the session. Using the ACK-REQ flag for diagnostic purposes is a policy issue. An acknowledged refresh message can be used to probe the end-to-end path to check that it's still intact 🦋💖
5.4.2. QUERY Messages 👀✨
Okay bestie, QUERY messages are the "let me peek before I commit" move 💅. A QUERY asks about the data path without making a reservation. You can use it to probe the network for path characteristics or for support of certain QoS models, or to kick off a receiver-initiated reservation 🦋.
A QNE sending a QUERY asks for a reply by including a Request Identification Information (RII) object; see Section 5.3.2. A request to start a receiver-initiated reservation goes through the RESERVE-INIT flag; see Section 5.1.2.2 🎀.
When a QNE gets a QUERY, the QSPEC gets handed to the RMF for processing. The RMF can return a modified QSPEC, and that's the one used in any QUERY or RESPONSE sent out because of the QUERY processing 🌸.
When processing a QUERY, a QNE checks whether the RESERVE-INIT flag is set. If it is, the QUERY is used to install reverse-path state 🧚. In this case, if the QNE is not the QNI, it creates a new QUERY message to send downstream. The QSPEC MUST be passed to the RMF, where it may be modified by the QoS-model-specific QUERY processing. If the QNE is the QNI, it creates a RESERVE message, which contains a QSPEC received from the RMF and which may be based on the received QSPEC. If this node wasn't expecting to perform a receiver-initiated reservation, then an error MUST be sent back along the path 💀.
The QNE MUST generate a RESPONSE message and pass it back along the reverse of the path used by the QUERY if:
- an RII object is present,
- the QNE is the QNR,
- the SCOPING flag is set, or
- the PROXY scope flag is set, and the QNE is a P-QNE.
To be super clear, if an RII object is present, and the QNE is the QNR, or the SCOPING flag is set, or the PROXY scope flag is set and the QNE is a P-QNE, the QNE MUST generate a RESPONSE message and pass it back along the reverse of the path used by the QUERY 🫶.
In other cases, the QNE MUST generate a QUERY message that then gets forwarded further along the path, using the same MRI, Session ID, and Direction that came in with the QUERY over the GIST API ✨.
The QSPEC to use is the one the RMF gave back, as described above. When the QNE makes a QUERY to pass along, it MUST copy the RII object (if present) unchanged into the new QUERY message. A QNE that's also interested in the response keeps track of the RII, so it can spot the RESPONSE when it passes through 👑.
Note that QUERY messages with the RESERVE-INIT flag set MUST be answered by the QNR 🙈. This feature may be used, e.g., after handovers, to set up new path state in GIST and to ask the other party to send a RESERVE back on this new GIST path.
If a stateful QoS NSLP QNE receives a QUERY message with the RESERVE-INIT flag and BREAK flag set, then the BREAK flag of newly generated messages (e.g., QUERY, RESERVE, or RESPONSE) MUST be set 🔥. When a stateful QoS NSLP QNE receives a QUERY message with the RESERVE-INIT flag set and BREAK flag not set, then the IP-TTL and Original-TTL values in the GIST RecvMessage primitive MUST be monitored. If they differ, it is RECOMMENDED to set the BREAK flag in newly generated messages (e.g., QUERY, RESERVE, or RESPONSE). In situations where a QNE or a domain is able to provide QoS using other means (see Section 3.3.5), the BREAK flag SHOULD NOT be set 🌈.
Finally, if a received QUERY asked for acknowledgement through the ACK-REQ flag in the COMMON HEADER flags, and processing the message was successful, the stateful QNE SHOULD send back a RESPONSE with an INFO-SPEC carrying the acknowledgement success code 🍓.
5.4.3. RESPONSE Messages 💌
The RESPONSE message gives you the scoop on the result of an earlier QoS NSLP message, like a reservation getting confirmed or info coming back from a QUERY 🧁. It doesn't install any state, but it can modify some state, e.g. if the RESPONSE is about an error 😭.
A RESPONSE message MUST be sent when the QNR processes a RESERVE or QUERY message containing an RII object, or if the QNE receives a scoped RESERVE or a scoped QUERY. In this case, the RESPONSE message MUST contain the RII object copied from the RESERVE or the QUERY. Also, if there's an error processing a received RESERVE, a RESPONSE gets sent describing the error. In this case, the RII and RSN, if available, MUST be included in the RESPONSE 💖.
When a RESPONSE containing an RII object comes in, the stateful QoS NSLP QNE MUST attempt to match it to the outstanding response requests for that signaling session. If the match works, then the RESPONSE MUST NOT be forwarded further along the path if it contains an Informational or Success INFO-SPEC class. If the QNE didn't insert this RII itself, it has to forward the RESPONSE to the next peer. So for success RESPONSEs, forwarding should only stop if the QNE inserted the RII by itself 🦋. If the RESPONSE carries an INFO-SPEC indicating an error, forwarding SHOULD continue upstream towards the QNI, using RSNs as described in the next paragraph 🔥.
When a RESPONSE containing an RSN object comes in, a stateful QoS NSLP QNE MUST compare the RSN to that of the appropriate signaling session. If the match works, then the INFO-SPEC MUST be processed. If the INFO-SPEC is used to send error notifications, then the node MUST use the stored upstream peer RSN value, associated with the same session, and forward the RESPONSE further along the path towards the QNI 🧚.
If the INFO-SPEC isn't used to notify error situations (see above), then if the RESPONSE carries an RSN, the message MUST NOT be forwarded further along the path 🙈.
If there's no RSN match, the message SHOULD be silently dropped 🤫.
When a RESPONSE containing neither an RII nor an RSN object comes in, the RESPONSE MUST NOT be forwarded further along the path 💀.
Usually, RESPONSE messages don't change the states installed in intermediate QNEs. But depending on the QoS model, there can be situations where states are affected, e.g.,
- if the RESPONSE includes an INFO-SPEC describing an error situation that results in reservations being removed, or
- the QoS model allows a QSPEC to define [min,max] limits on the resources requested, and downstream QNEs gave less resources than their upstream nodes, which means the upstream nodes may release part of the resource reservation 🌸.
If a stateful QoS NSLP QNE receives a RESPONSE message with the BREAK flag set, then the BREAK flag of newly generated message (e.g., RESPONSE) MUST be set 👑.
5.4.4. NOTIFY Messages 📣
NOTIFY messages are for conveying info to a QNE asynchronously 💬. They don't install any state. Whether state gets removed depends on the QoS model, and the exact operation depends on the QoS model too. A NOTIFY doesn't directly cause other messages to be sent. They're sent asynchronously, not in response to other messages, and they can go in either direction (upstream or downstream) 🌈.
A special case of synchronous NOTIFY happens when the upstream QNE is asked to use reduced refresh by setting the appropriate flag in the RESERVE. The QNE receiving such a RESERVE MUST reply with a NOTIFY and a proper INFO-SPEC code saying whether it agrees to use reduced refresh with the upstream QNE 🫶.
The Transient error code 0x07 "Reservation preempted" is sent to the QNI whose resources were preempted ⚡. The NOTIFY tells the QNI that one QNE no longer has a reservation for the session. It's up to the QNI to decide what to do, based on the QoS model being used. The QNI would normally tear down the preempted reservation by sending a RESERVE with the TEAR flag set, using the SII of the preempted reservation. However, the QNI can follow other procedures as specified in its QoS Model. More discussion on preemption can be found in the QSPEC Template [RFC5975] and the individual QoS Model specifications 🎀.
6. IANA Considerations ✨
This section gives guidance to the Internet Assigned Numbers Authority (IANA) about registering values related to the QoS NSLP, in accordance with BCP 26, RFC 5226 [RFC5226] 📋.
Per QoS NSLP, IANA has created a number of new registries:
- QoS NSLP Message Types
- QoS NSLP Binding Codes
- QoS NSLP Error Classes
- Informational Error Codes
- Success Error Codes
- Protocol Error Codes
- Transient Failure Codes
- Permanent Failure Codes
- QoS NSLP Error Source Identifiers
IANA has also registered new values in a number of registries:
- NSLP Object Types
- NSLP Identifiers (under GIST Parameters)
- Router Alert Option Values (IPv4 and IPv6)
6.1. QoS NSLP Message Type 💜
The QoS NSLP Message Type is an 8-bit value. This specification defines four QoS NSLP message types, which form the initial contents of this registry: RESERVE (0x01), QUERY (0x02), RESPONSE (0x03), and NOTIFY (0x04) 🌸.
The value 0 is reserved. Values 240 to 255 are for Experimental/Private Use. The registration procedure is IETF Review.
When a new message type is defined, any message flags used with it must also be defined.
6.2. NSLP Message Objects 🧁
A new registry has been created for NSLP Message Objects. This is a 12-bit field (giving values from 0 to 4095). This registry is shared between a number of NSLPs 🤝.
Registration procedures are as follows:
0: Reserved
1-1023: IETF Review
1024-1999: Specification RequiredAllocation policies are as follows:
2000-2047: Private/Experimental Use
2048-4095: ReservedWhen a new object is defined, the extensibility bits (A/B) must also be defined.
This document defines eleven new NSLP message objects. These are described in Section 5.1.3: RII (0x001), RSN (0x002), REFRESH-PERIOD (0x003), BOUND-SESSION-ID (0x004), PACKET-CLASSIFIER (0x005), INFO-SPEC (0x006), SESSION-ID-LIST (0x007), RSN-LIST (0x008), MSG-ID (0x009), BOUND-MSG-ID (0x00A), and QSPEC (0x00B) 🦋.
Additional values are to be assigned from the IETF Review section of the NSLP Message Objects registry.
6.3. QoS NSLP Binding Codes 🔑
A new registry has been created for the 8-bit Binding Codes used in the BOUND-SESSION-ID object. The initial values for this registry are listed in Section 5.1.3.4 🌈.
The registration procedure is IETF Review. Value 0 is reserved. Values 128 to 159 are for Experimental/Private Use. Other values are Reserved.
6.4. QoS NSLP Error Classes and Error Codes ✨
Okay so, the INFO-SPEC object gets its own Error Classes and Error Codes too 🎀. Those are described in Section 5.1.3.6. Bestie, go check that one out 💅.
The Error Class is 4 bits in length 🧚. The initial values are:
- 0: Reserved
- 1: Informational
- 2: Success
- 3: Protocol Error
- 4: Transient Failure
- 5: Permanent Failure
- 6: QoS Model Error
- 7: Signaling session failure (described in [RFC5973]) 💀
- 8-15: Reserved
More values can be added later, but they get assigned based on IETF Review 🌸.
The Error Code is 8 bits in length. Each Error Code is assigned inside a particular Error Class, which means every class needs its own registry for Error Codes 🍓. The Error Code 0 in each class is Reserved, so don't touch it 🙈.
The policies for those error code registries go like this:
- 0-63: IETF Review
- 64-127: Specification Required
- 128-191: Experimental/Private Use
- 192-255: Reserved
The initial assignments for the Error Code registries are in Section 5.1.3.6. Experimental and Reserved values are relevant to all Error classes, no cap 🫶.
6.5. QoS NSLP Error Source Identifiers 🦋
Section 5.1.3.6 defines Error Source Identifiers, and their type is identified by a 4-bit value ✨.
The value 0 is reserved 🙈.
Values 1-3 are given in Section 5.1.3.6 💜.
Values 14 and 15 are for Experimental/Private Use 🌈.
The registration procedure is Specification Required 👑.
6.6. NSLP IDs and Router Alert Option Values 🫶
This specification defines an NSLP for use with GIST 🔥. It also specifies that a number of NSLPID values are used to support bypassing intermediary nodes, so new identifiers must be assigned for them from the GIST NSLP identifier registry, ngl that's a whole thing 💅. As the QoS NSLP requires, 32 NSLPID values have been assigned, matching QoS NSLP Aggregation Levels 0 to 31 ✨.
The GIST specification also requires that NSLPIDs be associated with specific Router Alert Option (RAO) values, though multiple NSLPIDs are allowed to share the same value 🎀. For the purposes of the QoS NSLP, each of its NSLPID values should be associated with a different RAO value 🌸. A block of 32 new IPv4 RAO values and a block of 32 new IPv6 RAO values have been assigned, matching QoS NSLP Aggregation Levels 0 to 31 🧚.
- Security Considerations 💀
Okay this section is SERIOUS, bestie 😭. The security requirement for the QoS NSLP is to protect the signaling exchange for establishing QoS reservations against identified security threats 🔥. For the signaling problem as a whole, these threats have been outlined in NSIS threats [RFC4081]. The NSIS framework [RFC4080] hands a subset of that responsibility to GIST, and the remaining threats need to be addressed by NSLPs 💜. The main issues to handle can be summarized as:
Authorization:
The QoS NSLP must assure that the network is protected against theft-of-service by offering mechanisms to authorize the QoS reservation requester 🚨. A user requesting a QoS reservation might want proper resource accounting and protection against spoofing and other security vulnerabilities that lead to denial of service and financial loss 💀. In many cases, authorization is based on the authenticated identity. The authorization solution must provide guarantees that replay attacks are either not possible or limited to a certain extent. Authorization can also be based on traits that enable the user to remain anonymous, and support for user identity confidentiality can be accomplished 🙈.
Message Protection:
Signaling message content should be protected against modification, replay, injection, and eavesdropping while in transit 😭. Authorization information, such as authorization tokens, needs protection too. This type of protection at the NSLP layer is necessary to protect messages between NSLP nodes 🫶.
Rate Limitation:
QNEs should perform rate-limiting on the refresh messages that they send 🔥. An attacker could send erroneous messages on purpose, forcing the QNE to constantly reply with an error message, which is so not it 💀. Authentication mechanisms would help in figuring out if error situations should be reported to the sender, or silently ignored. If the sender is authenticated, the QNE should reply promptly ✨.
Prevention of Denial-of-Service Attacks:
GIST and QoS NSLP nodes have finite resources (state storage, processing power, bandwidth) 🌸. The protocol mechanisms in this document try to minimize exhaustion attacks against these resources when performing authentication and authorization for QoS resources 🎀.
To some extent, the QoS NSLP relies on the security mechanisms provided by GIST, which by itself relies on existing authentication and key exchange protocols 💅. Some signaling messages cannot be protected by GIST and hence should be used with care by the QoS NSLP 🙈. An API must ensure that the QoS NSLP implementation is aware of the underlying security mechanisms, and it must be able to indicate which degree of security is provided between two GIST peers 👑. If a level of security protection for QoS NSLP messages that is required goes beyond the security offered by GIST or underlying security mechanisms, additional security mechanisms described in this document must be used 🔥. Due to the different usage environments and scenarios where NSIS is used, it is very difficult to make general statements without reducing its flexibility 🦋.
7.1. Trust Relationship Model 🌈
This specification is based on a model that requires trust between neighboring NSLP nodes to establish a chain-of-trust along the QoS signaling path ✨. The model is simple to deploy, was used in previous QoS authorization environments (such as RSVP), and seems to provide sufficiently strong security properties, so it's giving solid 💖. We refer to this model as the New Jersey Turnpike 🚗.
On the New Jersey Turnpike, motorists pick up a ticket at a toll booth when entering the highway 🎟️. At the highway exit, the ticket is presented and payment is made at the toll booth for the distance driven. For QoS signaling in the Internet, this procedure is roughly similar 🧚. In most cases, the data sender is charged for transmitted data traffic, and charging is provided only between neighboring entities 💅.
+------------------+ +------------------+ +------------------+
| Network | | Network | | Network |
| X | | Y | | Z |
| | | | | |
| -----------> -----------> |
| | | | | |
| | | | | |
+--------^---------+ +------------------+ +-------+----------+
| .
| .
| v
+--+---+ Data Data +--+---+
| Node | ==============================> | Node |
| A | Sender Receiver | B |
+------+ +------+
Legend:
----> Peering relationship that allows neighboring
networks/entities to charge each other for the
QoS reservation and data traffic
====> Data flow
.... Communication to the end host
Figure 16: New Jersey Turnpike ModelThe model shown in Figure 16 uses peer-to-peer relationships between different administrative domains as a basis for accounting and charging 🍓. As mentioned above, based on the peering relationship, a chain-of-trust is established. There are several issues that come to mind when considering this type of model 🙈:
- The model allows authorization on a request basis or on a per-session basis 🌸. Authorization mechanisms are elaborated in Section 7.2. The duration for which the QoS authorization is valid needs to be controlled. Combining the interval with the soft-state interval is possible. Notifications from the networks also seem to be a viable approach 🎀.
- The price for a QoS reservation needs to be determined somehow and communicated to the charged entity and to the network where the charged entity is attached 💸. Protocols providing "Advice of Charge" functionality are out of scope.
- This architecture is simple enough to allow a scalable solution (ignoring reverse charging, multicast issues, and price distribution) ✨.
Charging the data sender as performed in the model simplifies security handling by demanding only peer-to-peer security protection 🫶. Node A would perform authentication and key establishment. The established security association (together with the session key) would allow the user to protect QoS signaling messages 🔐. The identity used during the authentication and key establishment phase would be used by Network X (see Figure 16) to perform the so-called policy-based admission control procedure 👑. In our context, this user identifier would be used to establish the necessary infrastructure to provide authorization and charging. Signaling messages later exchanged between the different networks are then also subject to authentication and authorization. However, the authenticated entity is thereby the neighboring network and not the end host 🧚.
The New Jersey Turnpike model is attractive because of its simplicity 💖. S. Shenker, et al. [shenker] discuss various accounting implications and introduced the edge pricing model. The edge pricing model shows similarity to the model described in this section, with the exception that mobility and the security implications are not addressed 🌈.
7.2. Authorization Model Examples 🦋
Various authorization models can be used in conjunction with the QoS NSLP 💅.
7.2.1. Authorization for the Two-Party Approach 💜
The two-party approach (Figure 17) is conceptually the simplest authorization model 😭.
+-------------+ QoS request +--------------+
| Entity |----------------->| Entity |
| requesting | | authorizing |
| resource |granted / rejected| resource |
| |<-----------------| request |
+-------------+ +--------------+
^ ^
+...........................+
compensation
Figure 17: Two-Party ApproachIn this example, the authorization decision only involves the two entities, or makes use of previous authorization using an out-of-band mechanism to avoid the need for active participation of an external entity during the NSIS protocol execution 🔥.
This type of model may be applicable, e.g., between two neighboring networks (inter-domain signaling) where a long-term contract (or other out-of-band mechanisms) exists to manage charging and provides sufficient information to authorize individual requests ✨.
7.2.2. Token-Based Three-Party Approach 🎟️
okay so there's another way to do this, and it's giving tokens 💅 Think RFC 3520 [RFC3520] and RFC 3521 [RFC3521], or the tokens used as part of the Open Settlement Protocol [osp]. Authorization tokens tie two different signaling protocol runs (like SIP and NSIS) together, linking each run to their authorization decision. That link is a kind of assertion or trait ✨ With the token mechanism, the SIP proxy handles some form of authorization, and it's the resource-authorizing entity in Figure 18 👑 If the request gets approved, the SIP signaling sends back an authorization token. The QoS signaling messages can carry that token to point back at the earlier decision 🫶 The tokens can come in a bunch of different forms, and some of them might make the entity doing the QoS reservation go check external state 👀
Authorization
Token Request +--------------+
+-------------->| Entity C | financial settlement
| | authorizing | <..................+
| | resource | .
| +------+ request | .
| | +--------------+ .
| | .
| |Authorization .
| |Token .
| | .
| | .
| | .
| | QoS request .
+-------------+ + Authz. Token +--------------+ .
| Entity |----------------->| Entity B | .
| requesting | | performing | .
| resource |granted / rejected| QoS | <..+
| A |<-----------------| reservation |
+-------------+ +--------------+
Figure 18: Token-Based Three-Party ApproachFor the digital money type of systems (like OSP tokens), the token stands for a limited amount of credit 💸 So once that credit runs out, new tokens must be sent along with later refresh messages 🔄
7.2.3. Generic Three-Party Approach 🦋
Another method is for the node doing the QoS reservation to hand off the authorization decision to a third party, as shown in Figure 19 🌸 The authorization decision may be made per request, periodically, or per session. Totally your call, bestie 🧚
+--------------+
| Entity C |
| authorizing |
| resource |
| request |
+-----------+--+
^ |
QoS | | QoS
authz| |authz
req.| | res.
QoS | v
+-------------+ request +--+-----------+
| Entity |----------------->| Entity B |
| requesting | | performing |
| resource |granted / rejected| QoS |
| A |<-----------------| reservation |
+-------------+ +--------------+
Figure 19: Three-Party Approach7.3. Computing the Authorization Decision 🧮
Whenever an authorization decision has to be made, there's the question of which information gets fed into the authorizing entity. These are the information items that have been mentioned in the past for computing the authorization decision (on top of the authenticated identity) 💖
- Price
- QoS objects
- Policy rules
Policy rules look at things like time of day, subscription to certain services, membership, and so on, when computing an authorization decision 🕰️
The policies used to make the authorization are outside the scope of this document and are implementation/deployment specific 🙈
8. Acknowledgments 🫶
The authors would like to thank Eleanor Hepworth, Ruediger Geib, Roland Bless, Nemeth Krisztian, Markus Ott, Mayi Zoumaro-Djayoon, Martijn Swanink, and Ruud Klaver for their useful comments. Roland, especially, did deep reviews of the document, making sure the protocol was well defined 👑 Bob Braden provided helpful comments and guidance, which were gratefully received 🌈
9. Contributors 🌷
This document combines work from three individual documents. The following authors from those documents also contributed to this document: Robert Hancock (Siemens/Roke Manor Research), Hannes Tschofenig and Cornelia Kappler (Siemens AG), Lars Westberg and Attila Bader (Ericsson), and Maarten Buechli (Dante) and Eric Waegeman (Alcatel). On top of that, Roland Bless contributed a huge amount of text all the way through the writing of this specification 🙌
Sven Van den Bosch was the initial editor of earlier draft versions of this document. Since version 06 of the document, Jukka Manner has taken over as editor. Yacine El Mghazli (Alcatel) contributed text on AAA. Charles Shen and Henning Schulzrinne suggested using the reason field in the BOUND-SESSION-ID 🎀
10. References 📚
10.1. Normative References
[RFC1982] Elz, R. and R. Bush, "Serial Number Arithmetic",
RFC 1982, August 1996.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC5971] Schulzrinne, H. and R. Hancock, "GIST: General Internet
Signalling Transport", RFC 5971, October 2010.
[RFC5975] Ash, G., Bader, A., Kappler, C., and D. Oran, "QSPEC
Template for the Quality-of-Service NSIS Signaling Layer
Protocol (NSLP)", RFC 5975, October 2010.10.2. Informative References
[NSIS-AUTH] Manner, J., Stiemerling, M., Tschofenig, H., and R.
Bless, Ed., "Authorization for NSIS Signaling Layer
Protocols", Work in Progress, May 2010.
[NSIS-MOB] Sanda, T., Fu, X., Jeong, S., Manner, J., and H.
Tschofenig, "NSIS Protocols operation in Mobile
Environments", Work in Progress, May 2010.
[RFC1633] Braden, B., Clark, D., and S. Shenker, "Integrated
Services in the Internet Architecture: an Overview",
RFC 1633, June 1994.
[RFC2205] Braden, B., Zhang, L., Berson, S., Herzog, S., and S.
Jamin, "Resource ReSerVation Protocol (RSVP) -- Version
1 Functional Specification", RFC 2205, September 1997.
[RFC2210] Wroclawski, J., "The Use of RSVP with IETF Integrated
Services", RFC 2210, September 1997.
[RFC2961] Berger, L., Gan, D., Swallow, G., Pan, P., Tommasi, F.,
and S. Molendini, "RSVP Refresh Overhead Reduction
Extensions", RFC 2961, April 2001.
[RFC3175] Baker, F., Iturralde, C., Le Faucheur, F., and B. Davie,
"Aggregation of RSVP for IPv4 and IPv6 Reservations",
RFC 3175, September 2001.
[RFC3520] Hamer, L-N., Gage, B., Kosinski, B., and H. Shieh,
"Session Authorization Policy Element", RFC 3520,
April 2003.
[RFC3521] Hamer, L-N., Gage, B., and H. Shieh, "Framework for
Session Set-up with Media Authorization", RFC 3521,
April 2003.
[RFC3726] Brunner, M., "Requirements for Signaling Protocols",
RFC 3726, April 2004.
[RFC4080] Hancock, R., Karagiannis, G., Loughney, J., and S. Van
den Bosch, "Next Steps in Signaling (NSIS): Framework",
RFC 4080, June 2005.
[RFC4081] Tschofenig, H. and D. Kroeselberg, "Security Threats for
Next Steps in Signaling (NSIS)", RFC 4081, June 2005.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 5226,
May 2008.
[RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", STD 68, RFC 5234, January 2008.
[RFC5973] Stiemerling, M., Tschofenig, H., Aoun, C., and E.
Davies, "NAT/Firewall NSIS Signaling Layer Protocol
(NSLP)", RFC 5973, October 2010.
[RFC5977] Bader, A., Westberg, L., Karagiannis, G., Kappler, C.,
Tschofenig, H., and T. Phelan, "RMD-QOSM: The NSIS
Quality-of-Service Model for Resource Management in
Diffserv", RFC 5977, October 2010.
[lrsvp] Manner, J. and K. Raatikainen, "Localized QoS Management
for Multimedia Applications in Wireless Access
Networks", IASTED IMSA, Technical Specification 101 321,
p. 193-200, August 2004.
[opwa95] Breslau, L., "Two Issues in Reservation Establishment",
Proc. ACM SIGCOMM '95, Cambridge MA, August 1995.
[osp] ETSI, "Telecommunications and Internet Protocol
Harmonization Over Networks (TIPHON); Open Settlement
Protocol (OSP) for Inter-Domain pricing, authorization,
and usage exchange", Technical Specification 101 321,
version 4.1.1.
[qos-auth] Tschofenig, H., "QoS NSLP Authorization Issues", Work
in Progress, June 2003.
[shenker] Shenker, S., et al., "Pricing in computer networks:
Reshaping the research agenda", Proc. of TPRC 1995,
1995.Appendix A. Abstract NSLP-RMF API 🧩
This appendix is purely informational and gives an abstract API between the QoS NSLP and the RMF. It shouldn't be treated as a strict rule for implementors. It's more of a helper for understanding the interface between the NSLP and RMF 🌟
A.1. Triggers from QOS-NSLP towards RMF 💖
Okay, so the QoS-NSLP kicks off the RMF/QOSM side by calling sendrmf(). Here's the full signature, bestie 🎀
int sendrmf(sid, nslp_req_type, qspec, authorization_info,
NSLP_objects, filter, features_in, GIST_API_triggers,
incoming_interface, outgoing_interface)sid: SESSION-ID, the NSIS session identifier 🦋nslp_req_type: the type of request, which can be:RESERVEQUERYRESPONSENOTIFY
qspec: the QSPEC object, if it's there 💅authorization_info: the AUTH_SESSION object, if it's thereNSLP_objects: a data structure holding a list of the QoS-NSLP objects that were received. Local apps, network management, or policy control modules can use this list, which is so useful ✨- RII
- RSN
- BOUND-SESSION-ID list
- REFRESH-PERIOD
- SESSION-ID-LIST
- RSN-LIST
- INFO-SPEC
- MSG-ID
- BOUND-MSG-ID
filter: the info for packet filtering, based on the MRI and the PACKET-CLASSIFIER object 🌸features_in: the flags from the common header of the received QOS-NSLP message, plus some extra triggers. The extras are:- BREAK
- REQUEST REDUCED REFRESHES
- RESERVE-INIT
- TEAR
- REPLACE
- ACK-REQ
- PROXY
- SCOPING
synchronization_required: this one gets set (see Sections Section 4.6 and Section 4.7.1 for the deets) when the QoS-NSLP functionality on a QNE Egress gets a non-tearing RESERVE message that has a MSG-ID or a BOUND-MSG-ID object, AND the BINDING_CODE value of the BOUND-SESSION-ID object matches one of these:- Tunnel and end-to-end sessions
- Aggregate sessions
GIST_API_triggers: the attributes GIST hands over to QoS-NSLP through the GIST API 🧚- NSLPID
- Routing-State-Check
- SII-Handle
- Transfer-Attributes
- GIST-Hop-Count
- IP-TTL
- IP-Distance
incoming_interface: the ID of the incoming interface. It only matters when the QNE reserves resources on the incoming interface. The default is 0, which means no reservations on the incoming interface 🍓outgoing_interface: the ID of the outgoing interface. It only matters when the QNE reserves resources on the outgoing interface. The default is 0, which means no reservations on the outgoing interface 🍓
A.2. Triggers from RMF/QOSM towards QOS-NSLP 🌈
Now the RMF goes the other way and triggers the QoS-NSLP functionality using the recvrmf() and config() primitives. It can use all of the features listed below, or just some of them. Your call, babe 💜
recvrmf() is either a response to a request the QoS-NSLP already sent through the API, or an async notification. Heads up: when the RMF/QOSM gets a request from the QoS-NSLP, it can send back one or more recvrmf() response primitives through the API. So the QOS-NSLP can end up generating several QoS-NSLP messages. For example, one end-to-end RESERVE can trigger two or more RESERVE messages: an end-to-end RESERVE message plus one or more intra-domain (local) RESERVE messages. Wild, right? 🤯
config() is for configuring certain features, like the QNE type, whether it's stateful or stateless, or whether end-to-end messages get bypassed. 🎀
Also, the QoS Model decides which subset of triggers you actually get 👑
int recvrmf(sid, nslp_resp_type, qspec, authorization_info, status,
NSLP_objects, filter, features_out, GIST_API_triggers
incoming_interface, outgoing_interface)sid: SESSION-ID, the NSIS session identifiernslp_resp_type: the type of response, which can be:RESERVEQUERYRESPONSENOTIFY
qspec: the QSPEC object, if it's thereauthorization_info: the AUTHO_SESSION object, if it's therestatus: a boolean that tells you how the reservation went. QOS-NSLP can put it in the INFO-SPEC object. The values are:RESERVATION_SUCCESSFULTEAR_DOWN_SUCCESSFULNO RESOURCESRESERVATION_FAILURERESERVATION_PREEMPTED: the reservation got preempted 😭AUTHORIZATION_FAILED: authorizing the request failed 💀MALFORMED_QSPEC: the request failed because the qspec was malformedSYNCHRONIZATION_FAILED: the end-to-end RESERVE and the intra-domain RESERVE didn't sync up (see Sections Section 4.6 and Section 4.7.1)CONGESTION_SITUATION: a possible congestion situation happened on the downstream path 🔥QoS Model Error
NSLP_objects: a data structure with QoS-NSLP objects that QoS-NSLP can use when the QNE is a QNI, QNR, QNI_Ingress, QNR_Ingress, QNI_Egress, or QNR_Egress 🦋- RII
- RSN
- BOUND-SESSION-ID list
- REFRESH-PERIOD
- SESSION-ID-LIST
- RSN-LIST
- MSG-ID
- BOUND-MSG-ID
filter: the MRM-related PACKET CLASSIFIERfeatures_out: the flags QOS-NSLP can use for newly generated QoS-NSLP messages, among other things. The flags are:- BREAK
- REQUEST REDUCED REFRESHES
- RESERVE-INIT
- TEAR
- REPLACE
- ACK-REQ
- PROXY
- SCOPING
- BYPASSING: if the outgoing message should be bypassed, this carries the required bypassing level. Otherwise it's empty. Only QNI_Ingress, QNR_Ingress, QNI_Egress, or QNR_Egress can set it, and only those same types can unset it 💅
BINDING (): if BINDING is required, this includes a BOUND-SESSION-ID list. Otherwise it's empty. Only these QNE types can request it: QNI, QNR, QNI_Ingress, QNR_Ingress, QNI_Egress, or QNR_Egress- NEW_SID: asks for a brand-new session with a new SESSION-ID. If QoS-NSLP makes a new SESSION-ID, it has to send that value back to the RMF/QOSM. QNI, QNR, QNI_Ingress, QNI_Egress, QNR_Ingress, or QNR_Egress can request it 🌸
- NEW_RSN: asks for a new RSN. If QoS-NSLP makes one, it has to return the new value to the RMF/QOSM
- NEW_RII: asks for a new RII. If QoS-NSLP makes one, it has to return the new value to the RMF/QOSM
GIST_API_triggers: the attributes QoS-NSLP passes along to GIST through the GIST API 🧚- NSLPID
- SII-Handle
- Transfer-Attributes
- GIST-Hop-Count
- IP-TTL
- ROUTING-STATE-CHECK: if set, GIST has to create a routing state
incoming_interface: the ID of the incoming interface. It's only used when the QNE reserves resources on the incoming interface. The default is 0, which means no reservations on the incoming interface 🍓outgoing_interface: the ID of the outgoing interface. It's only used when the QNE reserves resources on the outgoing interface. The default is 0, which means no reservations on the outgoing interface 🍓
A.3. Configuration Interface ⭐
config() is the function for setting up per-session settings, going from the RMF over to the NSLP. Easy peasy 🫶
int config(sid, qne_type, state_type, bypassing_type)sid: SESSION-ID, the NSIS session identifierqne_type: defines what type of QNE it is:- QNI
- QNI_Ingress: the QNE is a QNI and also an Ingress QNE
- QNE: the QNE is not a QNI or QNR
- QNE_Interior: the QNE is an Interior QNE, but it's not a QNI or QNR
- QNI_Egress: the QNE is a QNI and also an Egress QNE
- QNR
- QNR_Ingress: the QNE is a QNR and also an Ingress QNE
- QNR_Egress: the QNE is a QNR and also an Egress QNE
state_type: defines whether the QNE keeps QoS-NSLP operational states:- STATEFUL
- STATELESS
bypassing_type: defines whether a QNE bypasses end-to-end messages or not
Appendix B. Glossary 📖
AAA: Authentication, Authorization, and AccountingEAP: Extensible Authentication ProtocolMRI: Message Routing Information (see [RFC5971])NAT: Network Address TranslatorNSLP: NSIS Signaling Layer Protocol (see [RFC4080])NTLP: NSIS Transport Layer Protocol (see [RFC4080])OPWA: One Pass With AdvertisingOSP: Open Settlement ProtocolPIN: Policy-Ignorant NodeQNE: an NSIS Entity (NE), which supports the QoS NSLP (see Section 2)QNI: the first node in the sequence of QNEs that issues a reservation request for a session (see Section 22)QNR: the last node in the sequence of QNEs that receives a reservation request for a session (see Section 22)QSPEC: Quality-of-Service SpecificationRII: Request Identification InformationRMD: Resource Management for DiffservRMF: Resource Management FunctionRSN: Reservation Sequence NumberRSVP: Resource Reservation Protocol (see [RFC2205])SII: Source Identification InformationSIP: Session Initiation ProtocolSLA: Service Level Agreement
Authors' Addresses ✨
Jukka Manner
Aalto University
Department of Communications and Networking (Comnet)
P.O. Box 13000
FIN-00076 Aalto
Finland
Phone: +358 9 470 22481
EMail: jukka.manner@tkk.fi
URI: http://www.netlab.tkk.fi/~jmanner/Georgios Karagiannis
University of Twente/Ericsson
P.O. Box 217
Enschede 7500 AE
The Netherlands
EMail: karagian@cs.utwente.nlAndrew McDonald
Roke Manor Research Ltd
Old Salisbury Lane
Romsey, Hampshire S051 0ZN
United Kingdom
EMail: andrew.mcdonald@roke.co.uk📦 where this page comes from
- ietf: rfc5974 2010-10
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms