National foreword

This British Standard is the UK implementation of ISO/IEC/IEEE 8802‑A:2026. It supersedes BS ISO/IEC/IEEE 8802‑A:2015, which is withdrawn.

The UK participation in its preparation was entrusted to Technical Committee IST/6, Data communications.

A list of organizations represented on this committee can be obtained on request to its committee manager.

Contractual and legal considerations

This publication has been prepared in good faith, however no representation, warranty, assurance or undertaking (express or implied) is or will be made, and no responsibility or liability is or will be accepted by BSI in relation to the adequacy, accuracy, completeness or reasonableness of this publication. All and any such responsibility and liability is expressly disclaimed to the full extent permitted by the law.

This publication is provided as is, and is to be used at the recipient’s own risk.

The recipient is advised to consider seeking professional guidance with respect to its use of this publication.

This publication is not intended to constitute a contract. Users are responsible for its correct application.

Compliance with a British Standard cannot confer immunity from legal obligations.

This British Standard was published under the authority of the Standards Policy and Strategy Committee on 31 August 2026.

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‑A was prepared by the LAN/MAN of the IEEE Computer Society (as IEEE Std 802®-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.

This second edition cancels and replaces the first edition (ISO/IEC/IEEE 8802‑A:2015), which has been technically revised. It also revises the Amendments ISO/IEC/IEEE 8802‑A:2015/Amd 1:2018, ISO/IEC/IEEE 8802‑A:2015/Amd 2:2019, ISO/IEC/IEEE 8802‑A:2015/Amd 3:2025.

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.

Abstract: An overview to the family of IEEE 802^® standards is provided in this standard. It describes the reference models for the IEEE 802 standards and explains the relationship of these standards to the higher layer protocols; it specifies the structure of IEEE 802 MAC addresses; it specifies identification of public, private, prototype, and standard protocols; it specifies an object identifier hierarchy used within IEEE 802 for uniform allocation of object identifiers used in IEEE 802 standards; and it specifies a method for higher layer protocol identification.

Keywords: BANs, body area networks, EtherTypes, IEEE 802^®, IEEE 802 architecture, IEEE 802 reference model, LANs, local area networks, MANs, metropolitan area networks, object identifiers, PANs, personal area networks, RANs, regional area networks, protocol identifiers, protocol types

Important Notices and Disclaimers Concerning IEEE Standards Documents

IEEE 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 standards and may be found under the heading “Important Notice” or “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 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 this standard, including but not limited to the warranties of merchantability, fitness for a particular purpose and non-infringement. 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 his or her 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: PROCUREMENT OF 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 development process involves the review of documents in English only. In the event that an IEEE standard is translated, only the English version published by IEEE should be considered the approved IEEE standard.

Official statements

A statement, written or oral, that is not processed in accordance with the IEEE-SA Standards Board Operations Manual 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. 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).

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 in revisions to an IEEE standard is welcome to join the relevant IEEE 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.1 An IEEE Account is needed to access the application.

Comments on standards should be submitted using the Contact Us form.2

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 imply compliance to any applicable regulatory 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 US 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 or 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.3 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.4 Search for standard number and year of approval to access the web page of the published standard. Errata links are located under the 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.5

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

IEEE Standards do not guarantee or ensure safety, security, health, or environmental protection, or ensure against interference with or from other devices or networks. 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, and interference protection practices and all applicable laws and regulations.

Participants

At the time this standard was completed, the IEEE 802.1 Working Group had the following membership:

Mahin Ahmed
Katsuyuki Akizuki
Venkat Arunarthi
Ralf Assmann
Rudy Belliardi
Christian Boiger
Paul Bottorff
Radhakrishna Canchi
Feng Chen
Lihao Chen
Abhijit Choudhury
Anna Engelmann
János Farkas
Donald Fedyk
Norman Finn
Geoffrey Garner
Craig Gunther
Stephen Haddock
Marc Holness
Daniel Hopf
Woojung Huh
Satoko Itaya
Yoshihiro Ito
Michael Karl
Stephan Kehrer
Marcel Kiessling
Gavin Lai
Yunping (Lily) Lyu
Christophe Mangin
Scott Mansfield
Olaf Mater
David McCall
Martin Mittelberger
Hiroki Nakano
Takumi Nomura
Donald R. Pannell
Dieter Proell
Karen Randall
Maximilian Riegel
Silvana Rodrigues
Rajeev Roy
Atsushi Sato
Frank Schewe
Michael Seaman
Maik Seewald
Ramesh Sivakolundu
Johannes Specht
Nemanja Stamenic
Marius Stanica
Guenter Steindl
Karim Traore
Max Turner
Balazs Varga
Ganesh Venkatesan
Leon Wessels
Ludwig Winkel
Jordon Woods
Takahiro Yamaura
Nader Zein

In addition to the members of the IEEE 802.1 Working Group, significant contributions were received from the following individuals:

Ralf Assman
Harry Bims
Robert M. Grow
Mark Hamilton
Marco Hernandez
Joseph S. Levy
Roger Marks
Geoffrey O. Thompson
Benjamin A. Rolfe
Karl Weber

The following members of the individual balloting committee voted on this standard. Balloters may have voted for approval, disapproval, or abstention.

Iwan Adhicandra
Thomas Alexander
Johann Amsenga
Boon Chong Ang
Carol Ansley
Butch Anton
Danilo Antonelli
Stefan Aust
Harry Bims
Christian Boiger
Rich Boyer
Travis Breitkreutz
Vern Brethour
William Byrd
Radhakrishna Canchi
Paul Cardinal
Pin Chang
Baw Chng
Rodney Cummings
Marc Emmelmann
János Farkas
Donald Fedyk
Andrew Fieldsend
Avraham Freedman
Matthias Fritsche
James P. K. Gilb
Sachin Goel
Fabrizio Granelli
Stephen Haddock
Marek Hajduczenia
Mark Hamilton
Mark Hantel
Adam Healey
Jerome Henry
Marco Hernandez
Werner Hoelzl
Oliver Holland
Russell Housley
David Hunter
C. Huntley
Abdul Jabbar
Raj Jain
SangKwon Jeong
Pranav Jha
Lokesh Kabra
Piotr Karocki
Stephan Kehrer
Stuart Kerry
Marcel Kiessling
Yongbum Kim
Hyeong Ho Lee
James Lepp
Joseph Levy
Ru Lin
Greg Luri
Michael Lynch
Yongsen Ma
Valerie Maguire
Sajeev Manikkoth
Scott Mansfield
William Rogelio Marchand-Niño
Ignacio Marin Garcia
Pedro Martinez-Julia
Jonathon Mclendon
Richard Mellitz
Martin Mittelberger
Michael Montemurro
Ronald Murias
Rick Murphy
Rajesh Murthy
Yukimasa Nagai
Paul Nikolich
John Notor
Satoshi Obara
Satoshi Oyama
Glenn Parsons
Bansi Patel
Dev Paul
Arumugam Paventhan
Richie Pearn
Cam Posani
Dieter Proell
Adee Ran
R. K. Rannow
Alon Regev
Maximilian Riegel
Benjamin Rolfe
Jon Rosdahl
Jessy Rouyer
Michael Seaman
Jhony Sembiring
Johannes Specht
Dorothy Stanley
Guenter Steindl
Walter Struppler
Mitsutoshi Sugawara
Bo Sun
Peng Sun
Bin Tian
Max Turner
Masood Ur Rehman
Ganesh Venkatesan
John Vergis
James Weaver
Karl Weber
Scott Willy
Ludwig Winkel
Andreas Wolf
Forrest Wright
James Yee
Yu Yuan
Oren Yuen
Janusz Zalewski
Sven Zeisberg
Ke Zhong
Tian Zhou
Juan Carlos Zuniga

When the IEEE SA Standards Board approved this standard on 11 December 2024, it had the following membership:

Sara R. Biyabani
Ted Burse
Stephen Dukes
Doug Edwards
J. Travis Griffith
Guido R. Hiertz
Ronald W. Hotchkiss
Hao Hu
Yousef Kimiagar
Joseph L. Koepfinger*
Howard Li
Xiaohui Liu
John Haiying Lu
Kevin W. Lu
Hiroshi Mano
Paul Nikolich
Robby Robson
Lei Wang
F. Keith Waters
Sha Wei
Philip B. Winston
Don Wright

Historical participants

When the IEEE Std 802-1990 was approved on 31 May 1990, the IEEE 802.1 Working Group had the following officer:

When the IEEE Std 802-2001 was approved on 6 December 2001, the IEEE 802.1 Working Group had the following officers:

When the IEEE Std 802a-2003 was approved on 12 June 2003, the IEEE 802.1 Working Group had the following officers:

When the IEEE Std 802b-2004 was approved on 25 March 2004, the IEEE 802.1 Working Group had the following officers:

When the IEEE Std 802-2014 was approved on 12 June 2014, the IEEE 802.1 Working Group had the following officers:

When the IEEE Std 802c-2017 was approved on 15 June 2017, the IEEE 802.1 Working Group had the following officers:

When the IEEE Std 802d-2017 was approved on 14 February 2017, the IEEE 802.1 Working Group had the following officers:

When the IEEE Std 802f-2023 was approved on 21 September 2023, the IEEE 802.1 Working Group had the following officers:

The following individuals participated in the IEEE 802.1 working group during various stages of the standard’s development. Since the initial publication, many IEEE standards have added functionality or provided updates to material included in this standard. The following is a historical list of participants who have dedicated their valuable time, energy, and knowledge to the creation of this standard:

Steve Adams
Fumio Akashi
Paul D. Amer
Charles Arnold
Floyd Backes
Ann Ballard
Richard Bantel
John Bartlett
Sy Bederman
Les Bell
Amatzia Ben-Artzi
Michael Berger
James S. Binder
Robert Bledsoe
Kwame Boakye
Paul Bottorff
Laura Bridge
Juan Bulnes
Bill Bunch
Fred Burg
Jim Burns
Peter Carbone
Paul Carroll
Jeffrey Catlin
Dirceu Cavendish
Alan Chambers
David W. Chang
Ken Chapman
Alice Chen
Jade Chien
Hon Wah Chin
Chris Christ
Paul Congdon
Glenn Connery
Jim Corrigan
Paul Cowell
David Cullerot
Ted Davies
Peter Dawe
Stan Degen
Fred Deignan
David Delaney
Ron Dhondy
Jeffrey Dietz
Eiji Doi
Barbara J. Don Carlos
Peter Ecclesine
J. J. Ekstrom
Hesham Elbakoury
Walder Eldon
Norman W. Finn
David Frattura
Lars Henrik Frederiksen
Eldon D. Feist
Len Fishler
Kevin Flanagan
Anoop Ghanwani
James P. K. Gilb
Pat Gonia
Gerard Goubert
Richard Graham
Michael A. Gravel
Steve Haddock
Sharam Hakimi
Mogens Hansen
Harold Harrington
John Hart
Mike Harvey
Richard Hausman
David Head
Deepak Hegde
Ariel Hendel
Bob Herbst
Steve Horowitz
Robert W. Hott
Jack R. Hung
Altaf Hussain
Thomas Hytry
Ran Ish-Shalom
Jay Israel
Vipin K. Jain
Neil Jarvis
Tony Jeffree
Shyam Kaluve
Toyoyuki Kato
Hal Keen
Kevin Ketchum
Alan Kirby
Kimberly Kirkpatrick
Keith Klamm
Steve Kleiman
Bruce Kling
Dan Krent
James Kristof
H. Eugene Latham
Bing Liao
William P. Lidinsky
George Lin
Paul Lachapelle
Bill Lane
Paul Langille
Roger Lapuh
Loren Larsen
Johann Lindmeyr
Andy Luque
Philip Magnuson
Bruce McClure
Tom McGowan
Milan Merhar
Margaret A. Merrick
John Messenger
Colin Mick
Dinesh Mohan
John Montrose
Bob Moskowitz
Yaron Nachman
Krishna Narayanaswamy
Lawrence Ng
Henry Ngai
Satoshi Obara
Don O’Connor
Jerry O’Keefe
Toshio Ooka
Jorg Ottensmeyer
Richard Patti
Luc Pariseau
Glenn Parsons
Roger Pfister
Thomas L. Phinney
John Pickens
Dinel Pitt
Ron L. G. Prince
Steve Ramberg
Nigel Ramsden
Shlomo Reches
Frank Reichstein
Trudy Reusser
James Richmond
Anil Rijsinghani
Eduoard Rocher
John Roese
Allyn Romanow
Dan Romascanu
Paul Rosenblum
Dolors Sala
John Salter
Alan Sarsby
Ayman Sayed
Susan Schannning
Mick Seaman
Gerry Segal
Rich Seifert
Lee Sendelbach
Himanshu Shah
Howard Sherry
Wu-Shi Shung
Phil Simmons
Curtis Simonson
Paramjeet Singh
Rosemary V. Slager
Alexander Smith
Andrew Smith
M. Soha
Larry Stefani
Dan Stokesberry
Stuart Soloway
Sundar Subramaniam
Lennart Swartz
Kazuo Takagi
Kenta Takumi
Robin Tasker
Angus Telfer
Pat Thaler
Dave Thompson
Geoffrey O. Thompson
Michel Thorsen
Nathan Tobol
Wendell Turner
Steve Van Seters
Dono van-Mierop
Paul Videcrantz
Dennis Volpano
Paul Wainright
John Wakerly
Peter Wang
Y. C. Wang
Trevor Warwick
Scott Wasson
Daniel Watts
Karl Weber
Alan Weissberger
Deborah Wilbert
Keith Willette
Michael Witkowski
Edward Wong
Michael D. Wright
Michele Wright
Allen Yu
Wayne Zakowski
Igor Zhovnirovosky
Carolyn Zimmer
Nick Zucchero

Introduction

This introduction is not part of IEEE Std 802-2024, IEEE Standard for Local and Metropolitan Area Networks: Overview and Architecture.

This document is the third major revision of the IEEE 802^® overview and architecture. This revision integrates into the previous revision of the standard, IEEE Std 802-2014, the three subsequent amendments:

IEEE Std 802d™-2017, which specifies a Uniform Resource Name (URN) root identifier for YANG data models
IEEE Std 802c™-2017, which specifies an optional local medium access control (MAC) address space structure
IEEE Std 802f™-2023, which specifies a YANG module that contains EtherType information

1 Overview

1.1 Scope

This standard contains descriptions of the IEEE 802^® standards published by the IEEE for frame-based data networks as well as a reference model (RM) for protocol standards. A specification for the identification of public, private, and standard protocols is included.

1.2 Purpose

1.3 Word usage

2 Normative references

3 Definitions, acronyms and abbreviations

3.1 Definitions

3.2 Acronyms and abbreviations

4 Family of IEEE 802 standards

4.1 Key concepts

4.2 Application and support

4.3 An international family of standards

4.4 IEEE 802 standards

5 Reference models (RMs)

5.1 Introduction

The IEEE 802 RM is derived from the Open Systems Interconnection basic reference model (OSI/RM), ISO/IEC 7498‑1:1994 [B20].20 It is assumed that the reader has some familiarity with the OSI/RM and its terminology. The IEEE 802 standards emphasize the functionality of the lowest two layers of the OSI/RM, i.e., PHY and DLL, and the higher layers as they relate to network management. The IEEE 802 RM is similar to the OSI/RM in terms of its layers and the placement of its service boundaries. Figure 3 shows the architectural view of IEEE 802 RM for end stations and its relation to the OSI/RM. A variation of the model applies within bridges, as described in 5.3.2.

For the mandatory data services supported by all IEEE 802 networks, the DLL is structured as two sublayers, with the logical link control (LLC) sublayer, described in 5.2.2, operating over a MAC sublayer, described in 5.2.3.

Each IEEE 802 standard has RMs that are more detailed in order to describe the structure for that specific standard. The RMs for the IEEE 802 standards are given in Annex B.

IEEE 802 standards also provide implementation models (IMs), which are more specific than the IEEE 802 RMs, allowing differentiation between implementation approaches (e.g., different MAC protocols and PHYs). Figure 4 illustrates an IEEE 802.3 IM and its relation to the IEEE 802 RM.

Considerations of management, security, and media-independent handover (MIH) in IEEE 802 networks are also covered by IEEE 802 standards; these optional features lead to an elaboration of the RM, as illustrated in Figure 5. IEEE 802 network management provides protocols for exchange of management information between stations. The media-independent control function (MICF) is a parallel control plane that provides control functions for different MAC and PHY sublayers. Some examples of this MICF are the media-independent handover function (MIHF) of IEEE Std 802.21™ and the control functions proposed in the IEEE 802.19.1 Task Group and IEEE Std 802.22™. IEEE Std 802.1X™ forms part of the LLC sublayer and provides a secure, connectionless service immediately above the MAC sublayer.

5.2 RM description for end stations

5.3 Interconnection and interworking

6 General requirements for an IEEE 802 network

6.1 Services supported

6.2 Error ratios

7 IEEE 802 network management

7.1 General

7.2 General-purpose IEEE 802 network management

7.3 Special-purpose IEEE 802 network management standards

8 MAC addresses

8.1 Terms and notational conventions

8.2 Universal addresses

8.3 Interworking with 48-bit and 64-bit MAC addresses

8.4 Local MAC addresses

8.5 Group MAC addresses

8.6 Bit-ordering within octets

9 Protocol identifiers and context-dependent identifiers

9.1 Introduction

A key function of the LLC sublayer is to support multiplexing and demultiplexing of multiple network-layer protocols over an IEEE 802 network.

Within the Network layer, entities can exchange data by a mutually agreed upon protocol mechanism. A pair of entities that do not support a common protocol cannot communicate with each other. For multiple Network-layer protocols to operate within an IEEE 802 network, the transmitting and receiving higher layer protocol discrimination entities (HLPDEs) of the LLC sublayer cooperate to identify the network-layer protocol to be invoked for each service data unit delivered by the lower layer.

A network-layer protocol is identified within the LLC sublayer by means of a protocol identifier of a specific protocol type, associated with the protocol. Three specific types of protocol identifier are supported:

E-Type: The E-Type protocol identifier is an EtherType, which is a two-octet identifier, in the range from 06-00 through FF-FF,²⁷ that is uniquely assigned to a protocol. Assignments are made and recorded by the IEEE Registration Authority.28 Two EtherType values, known as the Local Experi-mental EtherTypes, do not reflect global protocol assignments but instead are assigned for use by local administrators who decide on their local mapping to protocols.
NOTE 1 —While every E-Type protocol identifier is an EtherType, not all EtherTypes are E-Type protocol identifiers. For example, some EtherType values are assigned to indicate specific Layer 2 functionality rather than a network-layer protocol; in these cases, a network-layer PDU is typically encapsulated and carried later in the MAC frame.
L-Type: The L-Type protocol identifier is an LSAP address, which is a one-octet identifier that is uniquely assigned to a protocol. LSAP address value assignments are made and recorded by the IEEE Registration Authority.
NOTE 2 —While every L-Type protocol identifier is an LSAP address, not all LSAP addresses are L-Type pro-tocol identifiers. For example, some LSAP address values are assigned to indicate specific Layer 2 functionality rather than a network-layer protocol; in these cases, a network-layer PDU is typically encapsulated and carried later in the MAC frame.
O-Type: The O-Type protocol identifier is created under the authority of an OUI, OUI-36, or CID assignee by appending bits to the OUI, OUI-36, or CID assignment. The O-Type identifier allows the OUI, OUI-36, or CID assignee to derive globally-unique protocol identifiers without an external registration authority.

Because each protocol identifier type is a different length, the protocol identifier type of a protocol identifier follows from its length. The types are also distinguishable by numeric value. The largest valid L-Type value is 0xFE (254). Valid E-Type values are within the range 0x0600 (1536) to 0xFFFF (65 535). The O-Type value is always greater than 0xFFFF.

In IEEE 802 networks, the protocol identifier is encoded into a protocol identification field (PIF) that is incorporated as the initial octets of the LPDU, prepended to the higher-layer protocol data unit, as shown in Figure 13. The LPDU transferred between LLC entities is encapsulated in the MDSU and is not exposed at the MAC sublayer. Some exceptions to this are specified in IEEE 802 standards; for example, the first two octets of the LPDU are exposed to the MAC sublayer of IEEE Std 802.3.

Two forms of encoding a protocol identification field are specified. With either of these two encoding forms, the encoding includes sufficient information for the receiving HLPDE to: a) identify the protocol identification field; b) determine the protocol identifier type; and c) identify the protocol identifier. The HLPDE is then enabled to strip the PIF from the data payload and forward the resulting payload to the network-layer protocol that is associated with the protocol identifier.

Three PIF encoding forms are specified, each of which allows the HLPDE to parse the PIF for any of the three protocol identifier types. These are as follows:

Type 1 PIF encoding, which is reserved
Type 2 PIF encoding, which does not use a Length/Type field
Type 3 PIF encoding, which makes use of a Length/Type field

While the two PIF encoding forms are each capable of supporting all protocol identifier types, no provision is made herein for the HLPDE to ascertain which of the two encoding forms was applied at the source. Without such information, the HLPDE cannot parse the data payload to identify the PIF. This standard presumes that the HLPDE is aware of the encoding form used.

9.2 EtherTypes and E-Type protocol identifiers

9.3 LSAP addresses and L-Type protocol identifiers

9.4 O-Type protocol identifiers

9.5 PIF encoding

9.6 Context-dependent identifiers

10 Allocation of OID values in IEEE 802 standards

10.1 General

10.2 OIDs and ISO standards

10.3 The OID hierarchy for IEEE 802 standards

10.4 The OID hierarchy under iso(1) std(0) iso8802(8802)

10.5 Migration from previous OID allocations

11 Allocation of Uniform Resource Name (URN) values in IEEE 802 standards

11.1 Introduction

From time to time, some IEEE 802 standards have a requirement to allocate Uniform Resource Name (URN) values—the most common example being for the purpose of defining data models using the YANG data modeling language specified in IETF RFC 6020 [B16] and IETF RFC 7950 [B18], but other examples exist. This clause specifies a simple and consistent URN hierarchy, based on the use of the base URN value that has been assigned by the Internet Assigned Numbers Authority (IANA) for use in IEEE standards. All current and future IEEE working groups can use this hierarchy flexibly to meet the needs of the standards specified by those working groups. This hierarchy provides a consistent practice within IEEE 802 for the development and allocation of URNs. Consistency of URN allocation facilitates the implementation and operation of IEEE 802-compliant equipment.

NOTE While the focus of this clause is on the use of URN values in IEEE 802 standards, the base URN value identified in 11.2 and the hierarchy of values that follows forms a basis for the assignment of URN values in all IEEE standards, not just those developed by IEEE 802.

11.2 IEEE Namespace ID and Namespace Specific String

11.3 ResourceSpecificString values in IEEE 802 standards