ISO/IEC/IEEE 8802-1DC:2025

International
Standard
ISO/IEC/IEEE
8802-1DC
First edition
Telecommunications and exchange
2025-09
between information technology
systems — Requirements for local
and metropolitan area networks —
Part 1DC:
Quality of service provision by
network systems
Télécommunications et échange entre systèmes informatiques —
Exigences pour les réseaux locaux et métropolitains —
Partie 1DC: Qualité des services fournis par les systèmes de réseau
Reference number
© IEEE 2024
© IEEE 2024
All rights reserved. Unless otherwise specified, or required in the context of its implementation, no part of this publication may
be reproduced or utilized otherwise in any form or by any means, electronic or mechanical, including photocopying, or posting on
the internet or an intranet, without prior written permission. Permission can be requested from IEEE at the address below.
Institute of Electrical and Electronics Engineers, Inc
3 Park Avenue, New York
NY 10016-5997, USA
Email: stds.ipr@ieee.org
Website: www.ieee.org
Published in Switzerland
© IEEE 2024 – All rights reserved
ii
Foreword
ISO (the International Organization for Standardization) and IEC (the International Electrotechnical
Commission) form the specialized system for worldwide standardization. National bodies that are members
of ISO or IEC participate in the development of International Standards through technical committees
established by the respective organization to deal with particular fields of technical activity. ISO and IEC
technical committees collaborate in fields of mutual interest. Other international organizations, governmental
and non-governmental, in liaison with ISO and IEC, also take part in the work.
The procedures used to develop this document and those intended for its further maintenance are described
in the ISO/IEC Directives, Part 1. In particular, the different approval criteria needed for the different types of
document should be noted.
IEEE Standards documents are developed within IEEE Societies and subcommittees of IEEE Standards
Association (IEEE SA) Board of Governors. IEEE develops its standards through an accredited consensus
development process, which brings together volunteers representing varied viewpoints and interests to
achieve the final product. IEEE standards are documents developed by volunteers with scientific, academic,
and industry-based expertise in technical working groups. Volunteers are not necessarily members of IEEE or
IEEE SA and participate without compensation from IEEE. While IEEE administers the process and establishes
rules to promote fairness in the consensus development process, IEEE does not independently evaluate, test,
or verify the accuracy of any of the information or the soundness of any judgments contained in its standards.
ISO and IEC draw attention to the possibility that the implementation of this document may involve the use of
(a) patent(s). ISO and IEC take no position concerning the evidence, validity or applicability of any claimed
patent rights in respect thereof. As of the date of publication of this document, ISO and IEC had not received
notice of (a) patent(s) which may be required to implement this document. However, implementers are
cautioned that this may not represent the latest information, which may be obtained from the patent database
available at www.iso.org/patents and https://patents.iec.ch. ISO and IEC shall not be held responsible for
identifying any or all such patent rights.
Any trade name used in this document is information given for the convenience of users and does not
constitute an endorsement.
For an explanation of the voluntary nature of standards, the meaning of ISO specific terms and expressions
related to conformity assessment, as well as information about ISO's adherence to the World Trade
Organization (WTO) principles in the Technical Barriers to Trade (TBT), see www.iso.org/iso/foreword.html.
In the IEC, see www.iec.ch/understanding-standards.
ISO/IEC/IEEE 8802-1DC was prepared by the LAN/MAN of the IEEE Computer Society (as IEEE Std 802.1DC-
2024) and drafted in accordance with its editorial rules. It was adopted, under the “fast-track procedure”
defined in the Partner Standards Development Organization cooperation agreement between ISO and IEEE,
by Joint Technical Committee ISO/IEC JTC 1, Information technology, Subcommittee SC 6, Telecommunications
and information exchange between systems.
A list of all parts in the ISO/IEC/IEEE 8802 series can be found on the ISO and IEC websites.
Any feedback or questions on this document should be directed to the user’s national standards body. A
complete listing of these bodies can be found at www.iso.org/members.html and www.iec.ch/national-
committees.
© IEEE 2024 – All rights reserved
iii
Title page
IEEE Std 802.1DC™-2024
IEEE Standard for
Local and Metropolitan Area Networks—
Quality of Service Provision by
Network Systems
Developed by the
LAN/MAN Standards Committee
of the
IEEE Computer Society
Approved 26 September 2024
IEEE SA Standards Board
Abstract: 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 frame preemption, in a network system that is not a
Bridge.
Keywords: asynchronous traffic shaping, CQF, credit-based shaper, cyclic queuing and
forwarding, frame preemption, IEEE 802.1DC™, IEEE 802.1Q™, LAN, local area network,
Per-Stream Filtering and Policing, priority, quality of service, scheduled traffic, Time-Sensitive
Networking, TSN, Virtual Bridged Network, virtual LAN, VLAN Bridge
The Institute of Electrical and Electronics Engineers, Inc.
3 Park Avenue, New York, NY 10016-5997, USA
All rights reserved. Published 1 November 2024. Printed in the United States of America.
IEEE and 802 are registered trademarks in the U.S. Patent & Trademark Office, owned by the Institute of Electrical and
Electronics Engineers, Incorporated.
PDF: ISBN 979-8-8557-1309-1 STD27372
Print: ISBN 979-8-8557-1310-7 STDPD27372
IEEE prohibits discrimination, harassment, and bullying.
For more information, visit http://www.ieee.org/web/aboutus/whatis/policies/p9-26.html.
No part of this publication may be reproduced in any form, in an electronic retrieval system or otherwise, without the prior
written permission of the publisher.
Copyright © 2024 IEEE. All rights reserved.

Important Notices and Disclaimers Concerning IEEE Standards
Documents
IEEE Standards documents are made available for use subject to important notices and legal disclaimers.
These notices and disclaimers, or a reference to this page (https://standards.ieee.org/ipr/disclaimers.html),
appear in all IEEE standards and may be found under the heading “Important Notices and Disclaimers
Concerning IEEE Standards Documents.”
Notice and Disclaimer of Liability Concerning the Use of IEEE Standards
Documents
IEEE Standards documents are developed within IEEE Societies and subcommittees of IEEE Standards
Association (IEEE SA) Board of Governors. IEEE develops its standards through an accredited consensus
development process, which brings together volunteers representing varied viewpoints and interests to
achieve the final product. IEEE standards are documents developed by volunteers with scientific, academic,
and industry-based expertise in technical working groups. Volunteers involved in technical working groups
are not necessarily members of IEEE or IEEE SA and participate without compensation from IEEE. While
IEEE administers the process and establishes rules to promote fairness in the consensus development
process, IEEE does not independently evaluate, test, or verify the accuracy of any of the information or the
soundness of any judgments contained in its standards.
IEEE makes no warranties or representations concerning its standards, and expressly disclaims all
warranties, express or implied, concerning all standards, including but not limited to the warranties of
merchantability, fitness for a particular purpose and non-infringement. IEEE Standards documents do not
guarantee safety, security, health, or environmental protection, or compliance with law, or guarantee against
interference with or from other devices or networks. In addition, IEEE does not warrant or represent that the
use of the material contained in its standards is free from patent infringement. IEEE Standards documents
are supplied “AS IS” and “WITH ALL FAULTS.”
Use of an IEEE standard is wholly voluntary. The existence of an IEEE standard does not imply that there
are no other ways to produce, test, measure, purchase, market, or provide other goods and services related to
the scope of the IEEE standard. Furthermore, the viewpoint expressed at the time a standard is approved and
issued is subject to change brought about through developments in the state of the art and comments
received from users of the standard.
In publishing and making its standards available, IEEE is not suggesting or rendering professional or other
services for, or on behalf of, any person or entity, nor is IEEE undertaking to perform any duty owed by any
other person or entity to another. Any person utilizing any IEEE Standards document should rely upon their
own independent judgment in the exercise of reasonable care in any given circumstances or, as appropriate,
seek the advice of a competent professional in determining the appropriateness of a given IEEE standard.
IN NO EVENT SHALL IEEE BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL,
EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO: THE
NEED TO PROCURE SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS;
OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY,
WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR
OTHERWISE) ARISING IN ANY WAY OUT OF THE PUBLICATION, USE OF, OR RELIANCE
UPON ANY STANDARD, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE AND
REGARDLESS OF WHETHER SUCH DAMAGE WAS FORESEEABLE.
Translations
The IEEE consensus balloting process involves the review of documents in English only. In the event that an
IEEE standard is translated, only the English language version published by IEEE is the approved IEEE
standard.
Use by artificial intelligence systems
In no event shall material in any IEEE Standards documents be used for the purpose of creating, training, en-
hancing, developing, maintaining, or contributing to any artificial intelligence systems without the express,
written consent of the IEEE SA in advance. “Artificial intelligence” refers to any software, application, or
other system that uses artificial intelligence, machine learning, or similar technologies, to analyze, train, pro-
cess, or generate content. Requests for consent can be submitted using the Contact Us form.
Official statements
A statement, written or oral, that is not processed in accordance with the IEEE SA Standards Board Operations
Manual is not, and shall not be considered or inferred to be, the official position of IEEE or any of its
committees and shall not be considered to be or be relied upon as, a formal position of IEEE or IEEE SA. At
lectures, symposia, seminars, or educational courses, an individual presenting information on IEEE standards
shall make it clear that the presenter’s views should be considered the personal views of that individual rather
than the formal position of IEEE, IEEE SA, the Standards Committee, or the Working Group. Statements
made by volunteers may not represent the formal position of their employer(s) or affiliation(s). News releases
about IEEE standards issued by entities other than IEEE SA should be considered the view of the entity
issuing the release rather than the formal position of IEEE or IEEE SA.
Comments on standards
Comments for revision of IEEE Standards documents are welcome from any interested party, regardless of
membership affiliation with IEEE or IEEE SA. However, IEEE does not provide interpretations,
consulting information, or advice pertaining to IEEE Standards documents.
Suggestions for changes in documents should be in the form of a proposed change of text, together with
appropriate supporting comments. Since IEEE standards represent a consensus of concerned interests, it is
important that any responses to comments and questions also receive the concurrence of a balance of interests.
For this reason, IEEE and the members of its Societies and subcommittees of the IEEE SA Board of
Governors are not able to provide an instant response to comments or questions except in those cases where the
matter has previously been addressed. For the same reason, IEEE does not respond to interpretation requests.
Any person who would like to participate in evaluating comments or revisions to an IEEE standard is welcome
to join the relevant IEEE SA working group. You can indicate interest in a working group using the Interests
tab in the Manage Profile & Interests area of the IEEE SA myProject system. An IEEE Account is needed to
access the application.
Comments on standards should be submitted using the Contact Us form.
Laws and regulations
Users of IEEE Standards documents should consult all applicable laws and regulations. Compliance with the
provisions of any IEEE Standards document does not constitute compliance to any applicable regulatory
Available at: https://standards.ieee.org/about/contact/.
Available at: https://development.standards.ieee.org/myproject-web/public/view.html#landing.
requirements. Implementers of the standard are responsible for observing or referring to the applicable
regulatory requirements. IEEE does not, by the publication of its standards, intend to urge action that is not
in compliance with applicable laws, and these documents may not be construed as doing so.
Data privacy
Users of IEEE Standards documents should evaluate the standards for considerations of data privacy and
data ownership in the context of assessing and using the standards in compliance with applicable laws and
regulations.
Copyrights
IEEE draft and approved standards are copyrighted by IEEE under U.S. and international copyright laws.
They are made available by IEEE and are adopted for a wide variety of both public and private uses. These
include both use, by reference, in laws and regulations, and use in private self-regulation, standardization,
and the promotion of engineering practices and methods. By making these documents available for use and
adoption by public authorities and private users, neither IEEE nor its licensors waive any rights in copyright
to the documents.
Photocopies
Subject to payment of the appropriate licensing fees, IEEE will grant users a limited, non-exclusive license
to photocopy portions of any individual standard for company or organizational internal use or individual,
non-commercial use only. To arrange for payment of licensing fees, please contact Copyright Clearance
Center, Customer Service, 222 Rosewood Drive, Danvers, MA 01923 USA; +1 978 750 8400; https://
www.copyright.com/. Permission to photocopy portions of any individual standard for educational
classroom use can also be obtained through the Copyright Clearance Center.
Updating of IEEE Standards documents
Users of IEEE Standards documents should be aware that these documents may be superseded at any time
by the issuance of new editions or may be amended from time to time through the issuance of amendments,
corrigenda, or errata. An official IEEE document at any point in time consists of the current edition of the
document together with any amendments, corrigenda, or errata then in effect.
Every IEEE standard is subjected to review at least every 10 years. When a document is more than 10 years
old and has not undergone a revision process, it is reasonable to conclude that its contents, although still of
some value, do not wholly reflect the present state of the art. Users are cautioned to check to determine that
they have the latest edition of any IEEE standard.
In order to determine whether a given document is the current edition and whether it has been amended
through the issuance of amendments, corrigenda, or errata, visit IEEE Xplore or contact IEEE. For more
information about the IEEE SA or IEEE’s standards development process, visit the IEEE SA Website.
Errata
Errata, if any, for all IEEE standards can be accessed on the IEEE SA Website. Search for standard number
and year of approval to access the web page of the published standard. Errata links are located under the
Available at: https://ieeexplore.ieee.org/browse/standards/collection/ieee.
Available at: https://standards.ieee.org/standard/index.html.
Additional Resources Details section. Errata are also available in IEEE Xplore. Users are encouraged to
periodically check for errata.
Patents
IEEE standards are developed in compliance with the IEEE SA Patent Policy.
Attention is called to the possibility that implementation of this standard may require use of subject matter
covered by patent rights. By publication of this standard, no position is taken by the IEEE with respect to the
existence or validity of any patent rights in connection therewith. If a patent holder or patent applicant has
filed a statement of assurance via an Accepted Letter of Assurance, then the statement is listed on the
IEEE SA Website at https://standards.ieee.org/about/sasb/patcom/patents.html. Letters of Assurance may
indicate whether the Submitter is willing or unwilling to grant licenses under patent rights without
compensation or under reasonable rates, with reasonable terms and conditions that are demonstrably free of
any unfair discrimination to applicants desiring to obtain such licenses.
Essential Patent Claims may exist for which a Letter of Assurance has not been received. The IEEE is not
responsible for identifying Essential Patent Claims for which a license may be required, for conducting
inquiries into the legal validity or scope of Patents Claims, or determining whether any licensing terms or
conditions provided in connection with submission of a Letter of Assurance, if any, or in any licensing
agreements are reasonable or non-discriminatory. Users of this standard are expressly advised that
determination of the validity of any patent rights, and the risk of infringement of such rights, is entirely their
own responsibility. Further information may be obtained from the IEEE Standards Association.
IMPORTANT NOTICE
Technologies, application of technologies, and recommended procedures in various industries evolve over
time. The IEEE standards development process allows participants to review developments in industries,
technologies, and practices, and to determine what, if any, updates should be made to the IEEE standard.
During this evolution, the technologies and recommendations in IEEE standards may be implemented in
ways not foreseen during the standard’s development. IEEE standards development activities consider
research and information presented to the standards development group in developing any safety
recommendations. Other information about safety practices, changes in technology or technology
implementation, or impact by peripheral systems also may be pertinent to safety considerations during
implementation of the standard. Implementers and users of IEEE Standards documents are responsible for
determining and complying with all appropriate safety, security, environmental, health, data privacy, and
interference protection practices and all applicable laws and regulations.
Available at: https://standards.ieee.org/about/sasb/patcom/materials.html.
Participants
At the time this standard was submitted to the IEEE SA Standards Board for approval, the IEEE 802.1
Working Group had the following membership:
Glenn Parsons, Chair
Jessy V. Rouyer, Vice Chair
János Farkas, TSN Task Group Chair
Norman Finn, Editor
Katsuyuki Akizuki Yoshihiro Ito Atsushi Sato
Venkat Arunarthi Michael Karl Frank Schewe
Ralf Assmann Stephan Kehrer
Michael Seaman
Rudy Belliardi Marcel Kiessling
Maik Seewald
Gavin Lai
Christian Boiger
Ramesh Sivakolundu
Paul Bottorff Yunping (Lily) Lyu
Johannes Specht
Radhakrishna Canchi Christophe Mangin
Nemanja Stamenic
Feng Chen Scott Mansfield
Marius Stanica
Abhijit Choudhury Olaf Mater
Guenter Steindl
Anna Engelmann David McCall
Karim Traore
Donald Fedyk Martin Mittelberger
Max Turner
Geoffrey Garner Hiroki Nakano
Balazs Varga
Craig Gunther Takumi Nomura
Ganesh Venkatesan
Stephen Haddock Donald R. Pannell
Leon Wessels
Mark Hantel Dieter Proell
Ludwig Winkel
Marc Holness Karen Randall
Jordon Woods
Daniel Hopf Maximilian Riegel
Woojung Huh Takahiro Yamaura
Silvana Rodrigues
Satoko Itaya Rajeev Roy Nader Zein
The following members of the individual balloting committee voted on this standard. Balloters may have
voted for approval, disapproval, or abstention.
Boon Chong Ang Ruslan Karmanov Venkatesha Prasad
Butch Anton Piotr Karocki Dieter Proell
Danilo Antonelli Stuart Kerry
Adee Ran
Stefan Aust Yongbum Kim
Maximilian Riegel
Christian Boiger Jeff Koftinoff
Benjamin Rolfe
Vern Brethour Gavin Lai
Jessy V. Rouyer
William Byrd Hyeong Ho Lee
Frank Schewe
Radhakrishna Canchi Jon Lewis
Reinhard Schrage
Paul Cardinal Christophe Mangin
Jhony Sembiring
Pin Chang Scott Mansfield
Johannes Specht
David Chen William Rogelio Marchand Nino
Guenter Steindl
Rodney Cummings Jonathon McLendon
Walter Struppler
János Farkas Sven Meier
Max Turner
Donald Fedyk Michael Montemurro
John Vergis
Norman Finn Rajesh Murthy
Stephen Webb
Stephen Haddock Satoshi Obara
Scott Willy
Marco Hernandez Glenn Parsons
Andreas Wolf
Werner Hoelzl Bansi Patel
Yu Yuan
Raj Jain Arumugam Paventhan
Pranav Jha Cam Posani Oren Yuen
Lokesh Kabra Qiyue Zou
When the IEEE SA Standards Board approved this standard on 26 September 2024, it had the following
membership:
David J. Law, Chair
Jon W. Rosdahl, Vice Chair
Gary Hoffman, Past Chair
Alpesh Shah, Secretary
Sara R. Biyabani Hao Hu Hiroshi Mano
Paul Nikolich
Ted Burse Yousef Kimiagar
Robby Robson
Stephen Dukes Joseph L. Koepfinger*
Lei Wang
Doug Edwards Howard Li
F. Keith Waters
J. Travis Griffith Xiaohui Liu
Sha Wei
Guido R. Hiertz John Haiying Lu
Philip B. Winston
Ronald W. Hotchkiss Kevin W. Lu
Don Wright
*Member Emeritus
Introduction
This introduction is not part of IEEE Std 802.1DC-2024, IEEE Standard for Local and Metropolitan Area
Networks—Quality of Service Provision by Network Systems.
This standard specifies quality of service provision by network systems.
This standard contains state-of-the-art material. The area covered by this standard is undergoing evolution.
Revisions are anticipated within the next few years to clarify existing material, to correct possible errors, and
to incorporate new related material. Information on the current revision state of this and other IEEE 802
standards may be obtained from:
Secretary, IEEE SA Standards Board
445 Hoes Lane
Piscataway, NJ 08854
USA
Contents
1. Overview . 12
1.1 Scope . 12
1.2 Specification model . 12
1.3 Specification precedence . 12
1.4 Requirements terminology . 12
1.5 Structure and relationship to other standards . 13
1.6 Reference conventions . 14
2. Normative references . 15
3. Definitions . 16
4. Abbreviations . 17
5. Conformance . 18
5.1 Protocol Implementation Conformance Statement (PICS) . 18
5.2 Interpreting IEEE Std 802.1Q and IEEE Std 802.1CB for GFQoS systems . 18
5.3 GFQoS system required behaviors . 18
5.4 GFQoS system optional behaviors . 19
5.5 GFQoS end system required behaviors . 19
5.6 GFQoS end system optional behaviors . 19
5.7 GFQoS forwarding system required behaviors . 19
5.8 GFQoS forwarding system optional behaviors . 19
6. IEEE 802.1Q quality of service provision . 21
6.1 Overview . 21
6.2 List of GFQoS functions . 21
6.2.1 Basic GFQoS functionality .21
6.2.2 Strict priority .21
6.2.3 Enhanced Internal Sublayer Service (EISS) .21
6.2.4 Priority-based Flow Control (PFC) .21
6.2.5 Frame preemption .21
6.2.6 Frame Replication and Elimination for Reliability .21
6.2.7 General flow classification and metering .22
6.2.8 Per-Stream Filtering and Policing (PSFP) .22
6.2.9 Enhanced Transmission Selection (ETS) .22
6.2.10 Scheduled traffic .22
6.2.11 Credit-based shaper (CBS) .22
6.2.12 Cyclic queuing and forwarding (CQF) .22
6.2.13 Asynchronous Traffic Shaping (ATS) .22
6.3 IEEE Std 802.1Q clauses and subclauses relevant to GFQoS . 22
6.4 Other Bridge functions relevant to GFQoS provision . 24
6.4.1 Link Aggregation .24
6.4.2 MAC Security entity .24
6.4.3 Priority/DSCP regeneration .24
6.5 GFQoS functions not specified . 24
6.5.1 Congestion notification .24
6.5.2 Media QoS capabilities .24
6.5.3 Frame Replication and Elimination for Reliability .24
6.5.4 Control protocols .25
7. GFQoS systems . 26
7.1 GFQoS end systems, GFQoS forwarding systems, and streams . 26
7.2 GFQoS provision model . 26
7.2.1 Flow classification and metering .27
7.2.1.1 General flow classification and metering .28
7.2.1.2 Per-stream classification and metering .28
7.2.2 Queuing frames .28
7.2.3 Queue management .28
7.2.4 Transmission selection .28
7.2.5 Parameterization of frames .28
7.3 Requirements for GFQoS functions . 30
7.3.1 Transmission by priority .30
7.3.2 Enhanced Internal Sublayer Service .31
7.3.3 Credit-based shaper .31
7.3.4 Frame preemption .32
8. Managed objects . 33
9. YANG data model . 34
9.1 YANG framework . 34
9.2 IEEE 802.1DC YANG modules . 34
9.3 Structure of the YANG modules . 35
9.4 Security considerations . 36
9.5 YANG Schema tree definitions . 36
9.5.1 Tree diagram for ieee802-dot1dc-preemption-if .36
9.5.2 Tree diagram for ieee802-dot1dc-psfp-sys .36
9.5.3 Tree diagram for ieee802-dot1dc-gfqos .36
9.5.4 Tree diagram for ieee802-dot1dc-sched-if .37
9.5.5 Tree diagram for ieee802-dot1dc-cbsa-if .37
9.5.6 Tree diagram for ieee802-dot1dc-ats-if .37
9.6 YANG modules . 37
9.6.1 YANG module for frame preemption .37
9.6.2 YANG module for Per-Stream Filtering and Policing .39
9.6.3 YANG module for GFQoS interface .40
9.6.4 YANG module for scheduled transmissions .42
9.6.5 YANG module for credit-based shaper .44
9.6.6 YANG module for Asynchronous Traffic Shaping .45
Annex A (informative) Protocol Implementation Conformance Statement (PICS) proforma . 47
A.1 Introduction . 47
A.1.1 Abbreviations and special symbols .47
A.1.2 Instructions for completing the PICS proforma .48
A.1.3 Additional information .48
A.1.4 Exceptional information .48
A.1.5 Conditional items .49
A.1.6 Identification .49
A.2 PICS proforma for quality of service provision by network systems . 50
A.2.1 Major capabilities/options .50
A.2.2 GFQoS end system capabilities/options .50
A.2.3 GFQoS forwarding system capabilities/options .51
Annex B (informative) Bibliography . 52
IEEE Std 802.1DC™-2024
IEEE Standard for Local and Metropolitan Area Networks—Quality of Service Provision by Network Systems
IEEE Standard for
Local and Metropolitan Area Networks—
Quality of Service Provision by
Network Systems
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:
a) Shall is used for mandatory requirements.
b) 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.
c) 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.
IEEE Std 802.1DC™-2024
IEEE Standard for Local and Metropolitan Area Networks—Quality of Service Provision by Network Systems
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:
a) Latency: The time required to forward a frame from source to destination through a Bridged
Network.
b) Frame loss probability: The likelihood of losing a frame, rather than forwarding it, due to various
events occurring between the source and destination.
c) 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:
Bridges, by definition, receive, transmit, and forward “frames,” as specified in IEEE Std 802®. Other standards from IEEE and other
organizations use the term “packet” for a unit of transmitted data. This standard uses “frame” exclusively, as it indicates the unit of
transmission on a port, which is the most useful unit for this standard.
IEEE Std 802.1DC™-2024
IEEE Standard for Local and Metropolitan Area Networks—Quality of Service Provision by Network Systems
d) Frame forwarding, in the sense of choosing the output port(s), to which a given frame is forwarded
by a GFQoS forwarding system.
e) 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].
f) Frame Replication and Elimination for Reliability. (See 6.5.3 for an explanation of why.)
g) 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 I
...