1 Overview
1.1 Scope
This standard specifies procedures and managed objects for quality of service (QoS) features specified in IEEE Std 802.1Q, such as Per-Stream Filtering and Policing, queuing, transmission selection, stream control, and preemption, in a network system that is not a Bridge.
1.2 Specification model
The model of operation documented by this standard is simply a basis for describing the functionality of a compliant equipment. Implementations can adopt any internal model of operation compatible with the externally visible behavior that this standard specifies. Conformance of equipment to this standard is purely in respect of observable protocol.
1.3 Specification precedence
If any conflict among parts of this standard becomes apparent, information in normative tables takes precedence over other parts of the standard, followed by that in normative text, followed by that in normative figures. Non-normative tables, figures, and text are in annexes and are clearly marked as such.
1.4 Requirements terminology
For consistency with existing IEEE and IEEE 802.1 standards, requirements placed upon conformant implementations of this standard are expressed using the following terminology:
Shall is used for mandatory requirements.
May is used to describe implementation or administrative choices. “May” means “is permitted to,” and hence, “may” and “may not” mean precisely the same thing.
Should is used for recommended choices. The behaviors described by “should” and “should not” are both permissible but not equally desirable choices.
The Protocol Implementation Conformance Statement (PICS) proformas (see Annex A) reflect the occurrences of the words “shall,” “may,” and “should” within the standard.
The standard avoids needless repetition and apparent duplication of its formal requirements by using is, is not, are, and are not for definitions and the logical consequences of conformant behavior. Behavior that is permitted but is neither always required nor directly controlled by an implementor or administrator, or whose conformance requirement is detailed elsewhere, is described by can. Behavior that never occurs in a conformant implementation or system of conformant implementations is described by cannot. The word allow is used as a replacement for the phrase “support the ability for,” and the word capability means “can be configured to.”
Where this standard states that “a conformant system shall” support (conform to, provide, etc.) some part of some other IEEE 802 standard, this means that the “shall,” “may,” and “should” terms in the referenced standard apply in the manner described, in that referenced standard, to the conformant system; it does not mean that a “may” or “should” in the referenced standard is promoted to a “shall” for this standard.
1.5 Structure and relationship to other standards
IEEE Std 802.1Q specifies the operation of Bridges and Bridged Networks, as well as certain end station behaviors. Parts of that standard can be classified as describing quality of service (QoS) functions. QoS functions are those that affect a network’s ability to serve data flows, as measured by the following parameters:
Latency: The time required to forward a frame6 from source to destination through a Bridged Network.
Frame loss probability: The likelihood of losing a frame, rather than forwarding it, due to various events occurring between the source and destination.
Variability of the above parameters.
These parameters can be applied to individual frames, or to collections of frames, such as a single stream of frames from one source application instance to another, all frames sharing the same priority value, or all frames bound for a particular destination. Minimums, maximums, averages, or other mathematical functions can be applied to the parameters of a collection.
In defining QoS, IEEE Std 802.1Q makes normative references to IEEE Std 802.1CB, and IEEE Std 802.1AC.
IEEE Std 802.1Q specifies quality of service (QoS) features for Bridges. These features are perfectly applicable to other devices, for example, end stations, routers, or firewall appliances. In IEEE Std 802.1Q, the specifications of these features are scattered, and coupled tightly to the operation of a Bridge. There is a need for simple reference points to these QoS specifications that are usable for non-Bridge systems, and for managed objects for these features that are not specific to Bridges.
This standard specifies General Frame Quality of Service (GFQoS), the IEEE 802.1DC quality of service. It specifies the behavior of two kinds of systems, a GFQoS end system and a GFQoS forwarding system, each of which supplies the GFQoS.
The referenced IEEE 802 standards specify many non-QoS functions that are of no concern to this standard. For example, there are many functions that are performed by an IEEE 802.1Q Bridge, or by a GFQoS forwarding system, that are not a part of GFQoS:
Frame forwarding, in the sense of choosing the output port(s), to which a given frame is forwarded by a GFQoS forwarding system.
Transformations that frames undergo as they are forwarded due to forwarding decisions, for example, adding VLAN (Virtual Local Area Network) tags or updating fields in an IPv6 header [B9].7
Frame Replication and Elimination for Reliability. (See 6.5.3 for an explanation of why.)
Various control protocols, including resource reservation protocols (e.g., Stream Reservation Protocol, SRP, Clause 35 of IEEE Std 802.1Q‑2022, or Resource ReSerVation Protocol, RSVP, IETF RFC 2205 [B7]) that can be used to control GFQoS functions. (See 6.5.4 for an explanation of why.)
Clause 2, Clause 3, and Clause 4 contain the normative references, definitions, and abbreviations used in this standard, respectively. Clause 5 specifies the requirements for various types of systems to claim compliance to this standard. It is the starting point to answer the question, “What does a compliant implementation have to do?” Clause 6 introduces the specifications for GFQoS functions specified in IEEE Std 802.1Q and IEEE Std 802.1CB, including, in 6.2, a complete list of GFQoS functions. Clause 7 contains the specifications for certain of the GFQoS functions that cannot be specified in Clause 5, simply as references to other IEEE 802.1 standards. Clause 8 specifies the managed objects required to control the GFQoS functions.
1.6 Reference conventions
Because this standard makes frequent references to specific subclauses in IEEE Std 802.1Q‑2022 and its amendments, IEEE Std 802.1AC‑2016, and IEEE Std 802.1CB‑2017, as well as to subclauses within this standard, the following conventions are used:
A reference to “subclause x.y in IEEE Std 802.1Q‑2022” is of the form: “[Q] x.y”.
A reference to “subclause x.y in IEEE Std 802.1CB‑2017” is of the form: “[CB] x.y”.
A reference to “subclause x.y in IEEE Std 802.1AC‑2016” is of the form: “[AC] x.y”.
A reference to “subclause x.y in IEEE Std 802.1Qcw‑2023” is of the form: “[Qcw] x.y”.
A reference to “subclause x.y in IEEE Std 802.1Qcz‑2023” is of the form: “[Qcz] x.y”.
A reference to “subclause x.y in IEEE Std 802.1Qdx‑2024” is of the form: “[Qdx] x.y”.
A reference to subclause x.y in this standard has no prefix: “x.y”.