IEEE Draft Standard for Local and Metropolitan Area Networks: Overview and Architecture

P802®-REV/D1.7

(Revision of IEEE Std 802™-2001, incorporating IEEE Std 802a™-2003, and IEEE Std 802b™-2004)

Prepared by the

Interworking Task Group of IEEE 802.1 LAN/MAN Standards Committee of the IEEE Computer Society

This document is an unapproved draft of a proposed IEEE Standard. As such, this document is subject to change. USE AT YOUR OWN RISK! Because this is an unapproved draft, this document must not be utilized for any conformance/compliance purposes. Permission is hereby granted for IEEE Standards Committee participants to reproduce this document for purposes of international standardization consideration. Prior to adoption of this document, in whole or in part, by another standards development organization permission must first be obtained from the IEEE Standards Activities Department ([email protected]). Other entities seeking permission to reproduce this document, in whole or in part, must also obtain permission from the IEEE Standards Activities Department.

IEEE Standards Activities Department 445 Hoes Lane Piscataway, NJ 08854, USA Abstract: IEEE Std 802-2001, IEEE Standard for Local and Metropolitan Area Networks: Overview and Architecture, provides an overview to the family of IEEE 802 standards. It describes the relationship of IEEE 802 standards to the Open Systems Interconnection Basic Reference Model (ISO/IEC 7498-1:1994) and explains the relationship of these standards to the higher layer protocols; it provides a standard for the structure of LAN MAC addresses; it provides a standard for identification of public, private, prototype, and standard protocols; and it specifies an object identifier hierarchy used within IEEE 802 for uniform allocation of object identifiers used in IEEE 802 standards.

Keywords: EtherTypes, IEEE 802, IEEE 802 standards compliance, LAN/MAN architecture, LAN/MAN reference model, local area networks (LANs), metropolitan area networks (MANs), object identifiers, personal area networks (PANs), regional area networks (RANs), body area networks (BANs), protocol development, protocol types.

The Institute of Electrical and Electronics Engineers, Inc. 3 Park Avenue, New York, NY 10016-5997, USA

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 XXX-XXXXX-XXXX-XSTDXXXXX Print: ISBN XXX-XXXXX-XXXX-X STDPDXXXXX

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. Overview and Architecture P802-REV/D1.7 Octber 2013

Introduction

This introduction is not part of IEEE P802-REV/D1.7, IEEE Draft Standard for Local and metropolitan area networks: Overview and Architecture.

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 P.O. Box 1331 Piscataway, NJ 08855-4141 USA

Notice to users

Laws and regulations

Users of these documents should consult all applicable laws and regulations. Compliance with the provisions of this standard 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.

Copyrights

This document is copyrighted by the IEEE. It is made available 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 this document available for use and adoption by public authorities and private users, the IEEE does not waive any rights in copyright to this document.

Updating of IEEE documents

Users of IEEE standards 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. 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 the IEEE Standards Association website at http:// ieeexplore.ieee.org/xpl/standards.jsp, or contact the IEEE at the address listed previously.

For more information about the IEEE Standards Association or the IEEE standards development process, visit the IEEE-SA website at http://standards.ieee.org.

Errata

Errata, if any, for this and all other standards can be accessed at the following URL: http:// standards.ieee.org/findstds/errata/index.html. Users are encouraged to check this URL for errata periodically.

Interpretations

Current interpretations can be accessed at the following URL: http://standards.ieee.org/findstds/interps/ index.html.

Patents

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 http://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

iv Copyright © 2011 IEEE. All rights reserved. This is an unapproved IEEE Standards draft, subject to change. Overview and Architecture P802-REV/D1.7 Octber 2013 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 nondiscriminatory. 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.

Participants

When the IEEE 802.1 Working Group approved P802-REV, it had the following membership:

Tony Jeffree, Chair and Editor Paul Congdon, Vice Chair James P. K. “Trainwreck” Gilb, Task Force Chair and Technical Editor

In addition to the members if IEEE 802.1 working group, contributions were received from the following individuals w: David Bagby Subir Das James P. K. Gilb Marek Hajduczenia Bruce Kraemer Mark Hamilton Roger B. Marks Apurva Mody Paul Nikolich Ivan Reede Geoffrey O. Thompson Juan Carlos Zuniga

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

When the IEEE-SA Standards Board approved this standard on XX Month 20XX, it had the following membership: Name, Chair Name, Vice Chair Name, Past Chair Name, Secretary SBMember1 SBMember9 SBMember17 SBMember2 SBMember10 SBMember18 SBMember3 SBMember11 SBMember19 SBMember4 SBMember12 SBMember20 SBMember5 SBMember13 SBMember21 SBMember6 SBMember14 SBMember22 SBMember7 SBMember15 SBMember23 SBMember8 SBMember16

*Member Emeritus

Also included are the following nonvoting IEEE-SA Standards Board liaisons:

Name, TABRepresentative Name, NIST Representative Name, NRC Representative

Name IEEE Standards Program Manager, Document Development

Name IEEE Standards Program Manager, Technical Program Development

Historical participants

When the IEEE Std 802-1990 was approved on 31 May, 1990, the IEEE 802.1 Working Group officers were: William P. Lidinsky, Chair

When the IEEE Std 802-2001 was approved on 6 December 2001, the IEEE 802.1 Working Group officers were: William P. Lidinsky, Chair Tony Jeffree, Vice Chair and Editor Alan Chambers, Tony Jeffree, Editors

When the IEEE Std 802a-2003 was approved on 12 June 2003, the IEEE 802a Working Group officers were: Tony Jeffree, Chair and Editor Neil Jarvis, Vice Chair

When the IEEE Std 802b-2004 was approved on 25 March 2004, the IEEE 802a Working Group officers were: Tony Jeffree, Chair and Editor Neil Jarvis, Vice Chair

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 pro-

vided updates to material included in this standard. To follow is a historical list of participants who have dedicated their valuable time, energy, and knowledge to the creation of this standard:

Steve Adams Norman W. Finn Roger Lapuh Fumio Akashi David Frattura Loren Larsen Paul D. Amer Lars Henrik Frederiksen Johann Lindmeyr Charles Arnold Eldon D. Feist Andy Luque Floyd Backes Len Fishler Philip Magnuson Ann Ballard Kevin Flanagan Bruce McClure

Richard Bantel Anoop Ghanwani Tom McGowan

John Bartlett Pat Gonia Milan Merhar

Sy Bederman Gerard Goubert Margaret A. Merrick

Les Bell Richard Graham John Messenger Michael A. Gravel Amatzia Ben-Artzi Colin Mick Michael Berger Steve Haddock Dinesh Mohan James S. Binder Sharam Hakimi John Montrose Robert Bledsoe Mogens Hansen Bob Moskowitz Kwame Boakye Harold Harrington Paul Bottorff John Hart Yaron Nachman

Laura Bridge Mike Harvey Krishna Narayanaswamy

Juan Bulnes Richard Hausman Lawrence Ng

Bill Bunch David Head Henry Ngai Fred Burg Deepak Hegde Satoshi Obara Jim Burns Ariel Hendel Don O’Connor Peter Carbone Bob Herbst Jerry O’Keefe Paul Carroll Steve Horowitz Toshio Ooka Jeffrey Catlin Robert W. Hott Jorg Ottensmeyer Dirceu Cavendish Jack R. Hung Richard Patti Alan Chambers Altaf Hussain Luc Pariseau David W. Chang Thomas Hytry Glenn Parsons Ken Chapman Ran Ish-Shalom Roger Pfister Alice Chen Jay Israel Thomas L. Phinney Jade Chien Vipin K. Jain John Pickens Hon Wah Chin Neil Jarvis Dinel Pitt

Chris Christ Tony Jeffree Ron L. G. Prince

Paul Congdon Shyam Kaluve Steve Ramberg

Glenn Connery Toyoyuki Kato Nigel Ramsden

Jim Corrigan Hal Keen Shlomo Reches Paul Cowell Kevin Ketchum Frank Reichstein David Cullerot Alan Kirby Trudy Reusser Ted Davies Kimberly Kirkpatrick James Richmond Peter Dawe Keith Klamm Anil Rijsinghani Stan Degen Steve Kleiman Fred Deignan Bruce Kling Eduoard Rocher

David Delaney Dan Krent John Roese

Ron Dhondy James Kristof Allyn Romanow

Jeffrey Dietz H. Eugene Latham Dan Romascanu Eiji Doi Bing Liao Paul Rosenblum Barbara J. Don Carlos William P. Lidinsky Dolors Sala Peter Ecclesine George Lin John Salter J. J. Ekstrom Paul Lachapelle Alan Sarsby Hesham Elbakoury Bill Lane Ayman Sayed Walder Eldon Paul Langille Susan Schannning

Susan Schannning Sundar Subramaniam Peter Wang Mick Seaman Lennart Swartz Y. C. Wang Gerry Segal Kazuo Takagi Trevor Warwick Rich Seifert Kenta Takumi Scott Wasson Lee Sendelbach Robin Tasker Daniel Watts Himanshu Shah Angus Telfer Karl Weber Howard Sherry Pat Thaler Alan Weissberger Wu-Shi Shung Dave Thompson Deborah Wilbert Phil Simmons Geoffrey O. Thompson Keith Willette Curtis Simonson Michel Thorsen Michael Witkowski Paramjeet Singh Nathan Tobol Edward Wong Rosemary V. Slager Wendell Turner Michael D. Wright Alexander Smith Steve Van Seters Michele Wright Andrew Smith Dono van-Mierop Allen Yu M. Soha Paul Videcrantz Wayne Zakowski Larry Stefani Dennis Volpano Igor Zhovnirovosky Dan Stokesberry Paul Wainright Carolyn Zimmer Stuart Soloway John Wakerly Nick Zucchero

1 Contents 2 3 1. Overview...... 1 4 5 1.1 Scope...... 1 6 1.2 Purpose...... 1 7 8 2. Normative references...... 2 9 10 3. Definitions, acronyms and abbreviations...... 3 11 12 3.1 Definitions ...... 3 13 3.2 Acronyms and abbreviations ...... 4 14 15 4. Family of IEEE 802 standards ...... 7 16 17 4.1 Key concepts...... 7 18 4.2 Application and support...... 8 19 4.3 An international family of standards ...... 9 20 4.4 Organization of IEEE 802 standards ...... 9 21 22 5. Reference models (RMs) ...... 11 23 24 5.1 Introduction...... 11 25 5.2 RM description for end stations...... 1312 26 5.2.1 SAPs...... 13 27 5.2.2 LLC sublayer ...... 13 28 5.2.3 MAC sublayer...... 14 29 5.2.4 PHY ...... 15 30 5.2.5 Layer and sublayer management ...... 15 31 5.3 Interconnection and interworking...... 15 32 5.3.1 PHY interconnection: Repeaters and hubs ...... 1615 33 5.3.2 MAC-sublayer interconnection: Bridges ...... 16 34 5.3.3 Network-layer interconnection: Routers...... 18 35 36 6. General requirements for an IEEE 802 network...... 19 37 38 6.1 Services supported ...... 19 39 6.2 Size and extentError ratios...... 19 40 6.3 Error ratiosTransient service interruption...... 19 41 6.4 Transient service interruptionRegulatory requirements ...... 19 42 43 67.5 ...... Safety, lightning and galvanic protectionIEEE 802 network management20 44 45 67.61Regulatory requirementsGeneral...... 20 46 7.2 General-purpose IEEE 802 network management...... 2120 47 7.2.1 GeneralManagement functions...... 2120 48 7.2.2 General-purpose IEEE 802 network managementManagement architecture...... 2120 49 7.2.13 Management functionsManaged object definitions...... 21 50 7.2.2 Management architecture...... 21 51 7.2.3 Managed object definitions...... 22 52 7.3 Special-purpose IEEE 802 network management standards ...... 2221 53 54 8. EUI-48s, EUI-64s and protocol identifiersExtended unique identifiers (EUIs)...... 2322

1 8.1 GeneralOverview and history ...... 2322 2 8.2 OUINotational conventions ...... 2322 3 8.3 Universal addressesOUI ...... 2423 4 8.3.14ConceptUniversal addresses ...... 2423 5 8.34.21Assignment by organizationsConcept ...... 2623 6 8.4.2 Interworking with EUI-48 and EUI-64...... 24 7 8.34.3 Uniqueness of address assignmentAssignment by organizations...... 2625 8 8.4.4 Local addressesUniqueness of address assignment...... 2625 9 8.5 SNAP identifiers...... 27 10 8.65 OUI and OUI-36 as protocol identifiersLocal addresses...... 2726 11 8.76 Standardized EUI-48 and EUI-64 group addresses ...... 2826 12 8.87 Bit-ordering and different MACs ...... 2826 13 8.87.1 General considerations...... 2826 14 8.87.2 Recommendation ...... 2927 15 16 9. EtherTypes and SNAP Protocol identifiers ...... 3028 17 18 9.1 Introduction...... 3028 19 9.2 Basic conceptsEtherTypes ...... 3028 20 9.2.1 Coexistence of multiple protocolsFormat, function, and administration...... 3028 21 9.2.2 Multiple protocols above the LLC sublayerEtherTypes for prototype and vendor-specific 22 protocol development3029 23 9.2.3 Multiple protocols above the alternative sublayer...... 30 24 9.2.3 Local Experimental EtherTypes ...... 3029 25 9.32.14Format, function, and administrationOUI Extended EtherType...... 30 26 9.3 OUI and OUI-36 as protocol identifiers ...... 31 27 9.3.24EtherTypes for prototype and vendor-specific protocol developmentEncapsulation of Ethernet 28 frames with LPD3132 29 9.3.3 Local Experimental EtherTypes ...... 31 30 9.45 Encapsulation of Ethernet frames over LLCSNAP ...... 3433 31 9.5.1 SNAP identifiersidentifier ...... 3433 32 9.5.12 SNAP address ...... 3433 33 9.5.23 SNAP data unit format...... 3534 34 35 10. Allocation of object identifier (OID) values in IEEE 802 standards...... 3635 36 37 10.1 General...... 3635 38 10.2 OIDs and ISO standards ...... 3635 39 10.3 The OID hierarchy for IEEE 802 standards...... 3736 40 10.4 The OID hierarchy under iso(1) std(0) iso8802(8802)...... 3837 41 10.5 Migration from previous OID allocations ...... 3837 42 43 Annex A Bibliography...... 3938 44 45 Bibliography 39 46 47 Annex B Reference models (RMs) for IEEE 802 Standards...... 39 48 49 AB.1General IEEE 802 standardsStd 802.3 RMs ...... 39 50 A.2 Other standards developing organizations...... 41 51 52 Annex B ...... 42 53 54 Reference models (RMs) for IEEE 802 Standards 42

1 B.12IEEE Std 802.3 RMs11 RM ...... 42 2 B.23IEEE Std 802.11 RM15 RMs ...... 4543 3 B.3.1 IEEE Std 802.15.15 RMs3™ RM ...... 4643 4 B.3.12 IEEE Std 802.15.3™ 4 RM ...... 4644 5 B.3.23 IEEE Std 802.15.4 6™ RM ...... 4745 6 B.3.34 IEEE Std 802.15.7™ RM ...... 4845 7 B.4 IEEE Std 802.16 RM ...... 4946 8 B.4.1 Protocol RM ...... 4946 9 B.4.2 Network reference model ...... 4946 10 B.5 IEEE Std 802.21 RM ...... 5047 11 B.6 IEEE Std 802.22 RM ...... 5148 12 B.6.1 Data plane ...... 5148 13 B.6.2 Management/control plane ...... 5148 14 B.6.3 Cognitive plane ...... 5249 15 16 Annex C ...... 56 17 18 Annex C Examples of bit ordering for addresses 56addresses...... 52 19 20 C.1 General...... 5652 21 C.2 Illustrative examples ...... 5652 22 23 24 Annex D List of IEEE 802 standards...... 55 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54

1 2 3 4 5 6 IEEE Draft Standard for Local and 7 8 Metropolitan Area Networks: 9 10 11 Overview and Architecture 12 13 14 15 16 17 18 1. Overview 19 20 1.1 Scope 21 22 This standard contains descriptions of the IEEE 802 standards published by the IEEE for local area frame- 23 based data networks (LANs), metropolitan area networks (MANs), personal area networks (PANs), and 24 regional area networks (RANs), as well as a reference model (RM) for protocol standards. Compliance with 25 the family of IEEE 802 standards architecture is defined, and a standard for the identification of public, 26 private, and standard protocols is included. 27 28 29 1.2 Purpose 30 31 This standard serves as the foundation for the family of IEEE 802 standards published by IEEE for LANs, 32 MANs, PANs, and RANs. 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54

1 2. Normative references 2 3 The following publications contain provisions which, through reference in this text, constitute provisions of 4 this standard. At the time of publication, the editions indicated were valid. All standards are subject to 5 revision, and parties to agreements based on this standard are encouraged to investigate the possibility of 6 applying the most recent editions of the standards listed below. 7 8 IEEE Std 802.1D™, Standard for Local and Metropolitan Area Networks: Media Access Control (MAC) 9 Bridges.1,2 10 11 IEEE Std 802.1Q™, Standard for Local and Metropolitan Area Networks: Virtual Bridged Local Area 12 Networks. 13 14 IEEE P802Std 802.1AC™, Standard for Media Access Control (MAC) Service Definition.3 15 16 ISO/IEC 7498-1:1994, Information technology—Open Systems Interconnection—Basic Reference Model: 17 The Basic Model.4 18 19 ISO/IEC 8802-2:1998, Standard for Information technology—Telecommunications and information 20 exchange between systems—Local and metropolitan area networks—Specific requirements—Part 2: 21 Logical link control.5 22 23 ITU-T Recommendation X.660, Information technology – Procedures for the operation of object identifier 24 registration authorities: General procedures and top arcs of the international object identifier tree.6 25 26 IETF RFC 2578, Structure of Management Information Version 2 (SMIv2).7 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 1 45 The IEEE standards referred to in Clause 2 are trademarks owned by the Institute of Electrical and Electronics Engineers, Incorporated. 46 2IEEE publications are available from the Institute of Electrical and Electronics Engineers, 445 Hoes Lane, Piscataway, NJ 08854- 47 4141, USA Engineers (http://standards.ieee.org/). 48 3Numbers preceded by P are IEEE authorized standards projects that were not approved by the IEEE-SA Standards Board at the time 49 this publication went to press. For information about obtaining drafts, contact the IEEE. 4 50 ISO/IEC publications are at http://shop.ieee.org. 5 51 ISO/IEC publications are available from the International Organization for Standardization (http://www.iso.ch/) and the International Electrotechnical Commission (http://www.iec.ch/). ISO/IEC publications are also available in the United States from the American 52 National Standards Institute (http://www.ansi.org/). 53 6ITU-T publications are available from the International Telecommunications Union (http://www.itu.int/). 54 7IETF documents (i.e., RFCs) are available for download at http://www.rfc-archive.org/.

1 3. Definitions, acronyms and abbreviations 2 3 4 3.1 Definitions 5 6 For the purposes of this standarddocument, the following terms and definitions apply. The IEEE Standards 7 Dictionary: Glossary of Terms & Definitions Dictionary Online should be consulted for terms not defined in 8 this clause.6 9 10 access domain: A set of stations in an IEEE 802 network together with interconnecting data transmission 11 media and related equipment (e.g., connectors, repeaters), in which the stations use the same MAC protocol 12 without the use of a bridge. 13

14 bit-reversed representation: The representation of a sequence of octet values in which the values of the

15 individual octets are displayed in order from left to right, with each octet value represented as a two-digit

16 hexadecimal numeral, and with the resulting pairs of hexadecimal digits separated by colons. The order of

17 the hexadecimal digits in each pair, and the mapping between the hexadecimal digits and the bits of the octet

18 value, are derived by reversing the order of the bits in the octet value and interpreting the resulting bit

19 sequence as a binary numeral using the normal mathematical rules for digit significance. 20 NOTE—The bit-reversed representation is of historical interest only and is no longer applicable to any active IEEE 802 21 7 22 standard. See Figure 9 for a comparative example of bit-reversed and hexadecimal representation. 23 24 bridge, MAC bridge: A functional unit that interconnects two or more IEEE 802 networks that use the 25 same data link layer protocols above the MAC sublayer, but can use different MAC protocols. A bridge uses 26 layer 2 information for forwarding Forwarding and filtering data among decisions are made on the IEEE 802 27 networksbasis of layer 2 information. 28 29 canonical format: The format of a MAC data frame in which the octets of any 48-bit extended unique iden- 30 tifiers (EUI-48s) or 64-bit extended unique identifiers (EUI-64s) conveyed in the MAC user data field have 31 the same bit ordering as in the hexadecimal representation. 32 33 end station: A functional unit attached to an IEEE 802 network that acts as a source of, and/or destination 34 for, link layer data traffic carried on the network. 35 36 Ethernet: A communication protocol defined specified by IEEE Std 802.3™. 37 38 EtherType: A two octet value that indicates the nature of the MAC client protocol. Type values are value, 39 assigned by the IEEE Registration Authority, that provides context for interpretation of the data field of a 40 frame (protocol identification). 41

42 handover: The process by which a mobile node obtains facilities and preserves traffic flows when traffic is

43 switched from one link to another. Different types of handover are defined specified based on the way facil-

44 ities for supporting traffic flows are preserved. 45 46 hexadecimal representation: The representation of a sequence of octet values in which the values of the 47 individual octets are displayed in order from left to right, with each octet value represented as a two-digit 48 hexadecimal numeral, and with the resulting pairs of hexadecimal digits separated by hyphens. The order of 49 the hexadecimal digits in each pair, and the mapping between the hexadecimal digits and the bits of the octet 50 51 6The IEEE Standards Dictionary: Glossary of Terms & Definitions Dictionary Online subscription is available at at: http://shop- 52 www.ieee.org/portal/innovate/products/standard/standards_dictionary.html. 53 7Notes in text, tables, and figures of a standard are given for information only and do not contain requirements needed to implement 54 this standard.

1 value, are derived by interpreting the bits of the octet value as a binary numeral using the normal 2 mathematical rules for digit significance. 3 NOTE—See Figure 9 for a comparative example of bit-reversed and hexadecimal representation. 4 5 IEEE 802 network: A network consisting of one or more interconnected networks each using a MAC pro- 6 tocol specified in an IEEE 802 standard. 7 8 NOTE—IEEE 802 networks include both wired and wireless forms of local area networks (LANs), metropolitan area 9 networks (MANs), personal area networks (PANs), and regional area networks (RANs). 10 11 interconnection: The provision of A data communication paths path between stations in an IEEE 802 net- 12 work. 13 14 interworking: The use of interconnected stations in an IEEE 802 network for the exchange of data, by 15 means of protocols operating over the underlying data transmission paths. 16 17 local area network: A networknetwork of devices, whether indoors or outdoors, covering a limited geo- 18 graphic area, e.g., a building or campus. 19 20 medium access control (MAC) control frame: A data structure consisting of fields in accordance with a 21 MAC protocol, for the communication of control information, only, in a network. 22

23 medium access control (MAC) data frame: A data structure consisting of fields in accordance with a

24 MAC protocol, for the communication of user data and control information in a network; one of the fields

25 contains a sequence of octets of user data. 26

27 medium access control protocol: The protocol that governs access to the transmission medium in a net-

28 work, to enable the exchange of data between stations in a network. 29 30 media independent control function: A parallel control plane that provides control functions for different 31 MAC and PHY sublayers and provides a media independent abstraction to higher layer protocols. 32 33 media independent handover function: A function that provides the ability to relocate traffic flows 34 between different medium access technologies and associated physical media. 35 36 37 metropolitan area network: A computer networknetwork of devices, extending over a large geographical 38 area such as an urban area, often providing integrated communication services such as data, voice, and 39 video. 40 41 noncanonical format: The format of a medium access control (MAC) data frame in which the octets of 48- 42 bit extended unique identifiers (EUI-48s) or 64-bit extended unique identifiers (EUI-64s) conveyed in the 43 MAC user data field have the same bit ordering as in the bit-reversed representation. 44 45 octet: A sequence of eight bits, the ends of the sequence being identified as the most significant bit (MSB) 46 and the least significant bit (LSB). 47 NOTE—This identification of the ends of the sequence defines an unambiguous mapping from octet values, via binary 48 numerals, to the integers 0–255, and hence a mapping also from octet values to the expressions of those integers as 49 numerals in hexadecimal notation. See: hexadecimal representation. 50 51 personal area network: A computer network of devices extending over a very limited geographical area, 52 used to convey information among a private-intimate group of participant stations. 53 54 private protocol: A protocol whose use and specification are controlled by a private organization.

1 public protocol: A protocol whose specification is published and known to the public, but controlled by an 2 organization other than a formal standards body. 3 4 regional area network: A computer network of devices that generally covers a service area that is larger 5 than metropolitan area networks, typically in sparsely populated areas. 6 7 standard protocol: A protocol whose specification is published and known to the public and is controlled 8 by a standards body. 9 10 station: An end station or bridge. See also: bridge; end station. 11 12 13 3.2 Acronyms and abbreviations 14 15 AN auto negotiation 16 BS base station 17 CGMII 100 Gb/s media independent interface

18 CPE customer-premises equipment 19 CPS common part sublayer 20 21 CS convergence sublayer 22 CSMA/CD carrier sense multiple access with collision detection 23 DLL data link layer

24 EFM Ethernet in the first mile 25 EPD EtherType protocol discrimination 26 27 EUI-48™ 48-bit extended unique identifier 28 EUI-64™ 64-bit extended unique identifier 29 FEC forward error correction 30 IETF Internet Engineering Task Force

31 IM implementation model 32 I/G individual/group 33 34 ISO/IEC JTC 1 Joint Technical Committee 1, Information Technology, of the International Organization 35 for Standardization and the International Electrotechnical Commission 36 ITU-T International Telecommunication Union Telecommunication Standardization Sector 37 ITU-R International Telecommunication Union Radiocommunications Radiocommunication 38 Sector 39 LAN local area network

40 LLC logical link control 41 LLDP link layer discovery protocolLink Layer Discovery Protocol 42 43 LMSC local area networksLocal Area Networks/metropolitan area networks standards commit- 44 teeMetropolitan Area Networks Standards Committee 45 LPD LLC protocol discrimination 46 LSAP link service access point

47 LSB least significant bit 48 MAC medium access control, media access control8 49 50 MAN metropolitan area network 51 MCSAP medium access control control service access point 52 MDI medium dependent interface 53 54 8Both forms are used, with the same meaning. This standard uses medium.

1 MIB management information base 2 MICLSAP media independent control link service access point

3 MICPSAP media independent control physical service access point 4 MICSAP media independent control service access point 5 6 MIH media independent handover 7 MIHF media independent handover function 8 MLME medium access control sublayer management entity 9 MOCS managed object conformance statement

10 MSAP medium access control service access point 11 MSB most significant bit 12 13 MSTP multiple spanning tree protocol 14 OAM operations, administration, and maintenance 15 OID object identifier 16 OSI open systems interconnectionOpen Systems Interconnection

17 OSAP operations, administration, and maintenance service access point 18 OUI organizationally unique identifier 19 20 PAN personal area network 21 PCS physical coding sublayer 22 PDUPDE protocol data unitdiscrimination entity 23 PDU protocol data unit

24 PHY physical layer (open systems interconnection reference model and IEEE 802 reference

25 model) 26 PHY physical layer device or entity (IEEE Std 802.3 reference model) 27 PIB personal area network information base 28 29 PICS protocol implementation conformance statement 30 PLME physical layer management entity 31 PMA physical medium attachment

32 PMD physical medium dependent 33 PSAP physical service access point 34 PHY physical layer (open systems interconnection reference model and IEEE 802 reference 35 model) 36 37 PHY physical layer device or entity (IEEE Std 802.3 reference model) 38 PICS protocol implementation conformance statement 39 RAN regional area network 40 RM reference model

41 RS reconciliation sublayer 42 RSTP rapid spanning tree protocol 43 44 SAP service access point 45 SDO standards development organization 46 SNAP subnetwork access protocol 47 SNMP simple network management protocolSimple Network Management Protocol

48 SPB shortest path bridging 49 TV television 50 51 U/L universally or locally administered 52 VLAN virtual local area network 53 WAN wide area network 54 WLAN wireless local area network

1 WMAN wireless metropolitan area network 2 WPAN wireless personal area network

3 WRAN wireless regional area network 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54

1 4. Family of IEEE 802 standards 2 3 4 4.1 Key concepts 5 6 IEEE 802 networks use frame-based links over a variety of media to connect various digital apparatus 7 regardless of computer technology and data type. However, the scope of IEEE 802 standards is not limited 8 to the physical and data link layers. 9 10 The basic communications capabilities provided by all IEEE 802 standards are frame based with source and 11 destination addressing, as opposed to either cell based or isochronous. In a frame-based system, the 12 communication format is a variable-length sequence of data octets. By contrast, cell-based communication 13 transmits data in shorter, fixed-length units while isochronous communication transmits data as a steady 14 stream of octets, or groups of octets, at equal time intervals. 15 16 User and management data flowing within IEEE 802 networks are be optionally secured by a variety of 17 authentication, secure key exchange, and encryption mechanisms that are described in the various IEEE 802 18 MAC/PHY standards. In addition, IEEE 802 standards specify mechanisms by which a station is able to 19 discover neighboring networks information that may include IEEE 802 and non-IEEE 802 technologies. 20 IEEE 802 standards also specify mechanisms to achieve service discovery (e.g., support for Internet or VPN 21 service) and session continuity (e.g., a voice over IP or multimedia session) in a heterogeneous networking 22 environment when stations have a choice of connecting to multiple access networks, either in stationary 23 condition or while in motion. 24 25 The early IEEE 802 LAN wired technologies used shared-medium communication, with information 26 broadcast for all stations to receive. That approach utilized by early wired IEEE 802 technologies has been 27 varied and augmented subsequently, but in ways that preserve the appearance of simple peer-to-peer 28 communications behavior for end stations. In particular, the use of bridges, as described in 5.3.2, for 29 interconnecting IEEE 802 networks is now widespread. These bridges allow the construction of networks 30 with much larger numbers of end stations, and much higher aggregate throughput, than would be achievable 31 with a single shared-medium. End stations attached to such a bridged IEEE 802 network can communicate 32 with each other just as though they were attached to a single shared-medium; however, the ability to 33 communicate with other stations can be limited by use of management facilities in the bridges, particularly 34 where broadcast or multicast transmissions are involved. A further stage in this evolution has led to the use 35 of point-to-point full duplex communication in LANs, either between an end station and a bridge or between 36 a pair of bridges. 37 38 Other IEEE 802 technologies, in particular wireless-based technologies, are inherently shared-medium 39 communication systems. They too have been augmented over time. Many wireless LANs (WLANs) support 40 mobile node mobility and hence dynamic topologies. These additional facilities may, depending on the 41 IEEE 802 technology in use, restrict bridged LAN interconnects to the static topology nodes within the 42 wireless portion of a heterogeneous technology LAN. 43 44 LANs are distinguished from other types of data networks in that they are optimized for a moderate-sized 45 geographic area, such as a single office building, a warehouse, or a campus. An IEEE 802 LAN is a peer-to- 46 peer communication network that enables stations to communicate directly on a point-to-point, or point-to- 47 multipoint, basis without requiring them to communicate with any intermediate switching nodes. LAN 48 communication takes place at moderate-to-high data rates, and with short transit delays, on the order of a 49 few milliseconds or less. 50 51 A LAN is generally owned, used, and operated by a single organization. This is in contrast to wide area 52 networks (WANs) that interconnect communication facilities in different parts of a country or are used as a 53 public utility. LANs are useful for deployment on a variety of scales, whether indoors or outdoors, capable 54 of covering a scale up to a large building or campus environment.

1 A MAN is optimized for a larger geographical area than is a LAN, ranging from several blocks of buildings 2 to entire cities. As with local networks, MANs can also depend on communications channels of moderate- 3 to-high data rates. A MAN might be owned and operated by a single organization, but it is usually used by 4 many individuals and organizations. MANs might also be owned and operated as public utilities. They often 5 provide means for internetworking of local networks. 6 7 Personal area networks (PANs) are used to convey information over short distances among a private- 8 intimate small group of participant stations. Unlike a LAN, a connection made through a PAN typically 9 involves little or no infrastructure or direct connectivity to the world outside the link. This allows small, 10 power-efficient, inexpensive solutions to be implemented for a wide range of devices. In the context of the 11 family of IEEE 802 standards, PANs are implemented with wireless technology and so are sometimes 12 referred to as wireless PANs (WPANs). 13 14 Regional area networks (RANs) generally cover a service area that is larger than the MANs. A RAN is 15 similar to a MAN in that it is typically owned and operated by a single organization, but it is usually used by 16 many individuals and organizations. In the case of wireless regional area networks (WRANs), the unique 17 propagation characteristics of the frequency bands in which they operate, typically from 30 MHz to 1 GHz, 18 require a specialized design of the physical layer (PHY) and the medium access control (MAC) that can 19 absorb long channel impulse responses and large propagation delays. In some cases, operation in these 20 bands is subject to coordination with existing users, e.g., television (TV) broadcast. 21 22 IEEE 802 networks can also be used to perform the task of an access network, i.e., to connect end stations to 23 a larger, heterogeneous network, e.g., the Internet. 24 25 The early IEEE 802 standards for LAN and MAN technologies were all based on the use of copper or optical 26 fiber cables as the physical transmission medium. However, in addition to the use of cable-based media, 27 today’s IEEE 802 standards include technologies, radio and optical, that use free space as the physical 28 transmission medium. IEEE 802 standards for wireless networks include wireless LANs, MANs, RANs and 29 PANs. These technologies also target usage scenarios for both fixed and mobile wireless. These IEEE 802 30 network solutions address challenges of mobility, higher error rates, and potentials for signal loss and 31 interference that are inherent to using wireless medium. 32 33 The scope of IEEE 802 standards is not limited to MAC and PHY standards. 34 35 The early IEEE 802 LAN wired technologies used shared-medium communication, with information 36 broadcast for all stations to receive. That approach utilized by early wired IEEE 802 technologies has been 37 varied and augmented subsequently, but in ways that preserve the appearance of simple peer-to-peer 38 communications behavior for end stations. In particular, the use of bridges, as described in 5.3.2, for 39 interconnecting IEEE 802 networks is now widespread. These bridges allow the construction of networks 40 with much larger numbers of end stations, and much higher aggregate throughput, than would be achievable 41 with a single shared-medium. End stations attached to such a bridged IEEE 802 network can communicate 42 with each other just as though they were attached to a single shared-medium (however, the ability to 43 communicate with other stations can be limited by use of management facilities in the bridges, particularly 44 where broadcast or multicast transmissions are involved). A further stage in this evolution has led to the use 45 of point-to-point full duplex communication in LANs, either between an end station and a bridge or between 46 a pair of bridges. 47 48 Other IEEE 802 technologies, in particular wireless-based technologies, are inherently shared-medium 49 communication systems. They too have been augmented over time. Many wireless LANs (WLANs) support 50 mobile node mobility and hence dynamic topologies. These additional facilities may, depending on the 51 IEEE 802 technology in use, restrict bridged LAN interconnects to the static topology nodes within the 52 wireless portion of a heterogeneous technology LAN. In addition, IEEE 802 standards specify mechanisms 53 by which a station is able to discover neighboring networks information that may include IEEE 802 and non- 54 IEEE 802 technologies. IEEE 802 standards also specify mechanisms to achieve service and session

1 continuity in a heterogeneous networking environment when stations have a choice of connecting multiple 2 access networks, either in stationary condition or while in movement. 3 4 IEEE 802 networks use frame-based links over a variety of media to connect various digital apparatus in an 5 operating system, data type and computer technology independent manner. 6 7 The basic communications capabilities provided by all IEEE 802 standards are frame based with source and 8 destination addressing, as opposed to either cell based or isochronous. In a frame-based system, the basic 9 unit of transmission is a sequence of data octets that can be of any length within a range that is dependent on 10 the type of network. By contrast, cell-based communication transmits data in shorter, fixed-length units 11 while isochronous communication transmits data as a steady stream of octets, or groups of octets, at equal 12 time intervals. 13 14 15 4.2 Application and support 16 17 IEEE 802 networks are intended to have wide applicability in many environments. The primary aim is to 18 provide for low-cost devices and networks, suitable for consumer, commercial, educational, governmental, 19 and industrial applications. The following lists are intended to show some applications and devices and, as 20 such, are not intended to be exhaustive, nor do they constitute a set of required items: 21 22 — Client/server applications

23 — Database access 24 25 — Desktop publishing 26 — Electronic mail

27 — File transfer 28 29 —Graphics 30 — Handover services

31 —Multimedia 32 33 — Office automation 34 — Process control

35 — Robotics 36 37 — Telecommunication 38 — Text processing

39 — Transaction processing 40 41 IEEE 802 networks are intended to support various data devices, such as the following: 42 43 — Bridges, routers, and gateways 44 45 — Computers 46 — Image and video monitors 47 — Mass storage devices 48 49 — Monitoring and control equipment 50 — Photocopiers and facsimile machines 51 — Printers and plotters 52 53 —Terminals 54 — Wireless terminals

1 4.3 An international family of standards 2 3 The terms LAN, MAN, PAN, and RAN encompass a number of data communications technologies and 4 applications of these technologies. So it is with the IEEE 802 standards. In order to provide a balance 5 between the proliferation proliferation of a very large number of different and incompatible local and 6 metropolitan networks, on the one hand, and the need to accommodate rapidly changing technology and to 7 satisfy certain applications or cost goals, on the other hand, several types of medium access technologies are 8 currently defined specified in the family family of IEEE 802 standards. In turn, these MAC standards are 9 defined specified for a variety variety of physical media. A logical link control (LLC) standard, a secure data 10 exchange standard, and MAC bridging standards are intended to be used in conjunction with the MAC 11 standards. An architecture Architecture and protocols for the management management of IEEE 802 12 networks are also definedspecified. 13 14 The IEEE 802 standards have been developed and applied in the context of a global data communications 15 industry. IEEE 802 standards are recognized to be international standards in their own right. In addition, 16 some IEEE 802 standards have progressed progressed to become standards within Joint Technical 17 Committee 1, Information Technology, 1 of the International Organization for Standardization and the 18 International Electrotechnical Electrotechnical Commission (ISO/IEC JTC 1), International 19 Telecommunications Union Standardization sector Sector (ITU-T), International Telecommunications 20 Union Radiocommunications sector Sector (ITU-R), and a wide variety of national body standards 21 development organizations (SDOs). 22 23 24 4.4 Organization of IEEE 802 standards 25 26 The IEEE 802 LAN/MAN Standards Committee (LMSC) sponsors a large number of standards projects. 27 The current state of IEEE 802 standards is illustrated in Figure 1. The IEEE 802 committee is very active, so 28 for the latest status of the IEEE 802 working groups and standards, refer to http://www.ieee802.org. 29 30 IEEE 802 31 802 Overview and Architecture 32 33 802.1 802.3 802.11 802.15 34 35 802.3 Ethernet 802.11 WLAN 802.15.1 WPAN 802.1D Bridges 802.1AR Secure 36 device ID 802.3.1 MIB 802.15.2 Coexistence 802.1Q Bridges for Ethernet 37 and VLANs 802.1AS Time 802.15.3 High rate WPAN synchronization 38 802.1X Port-based 802.15.4 Low rate WPAN 39 network access control 802.1AX Link 802.15.5 Mesh for WPAN aggregation 40 802.1AB Connectivity 802.15.6 Wireless body discovery 802.1BA Audio area networks 41 video bridging 42 802.1AC MAC service 802.15.7 Visible definition 802.1BR Bridge light communications 43 port extension 802.1AE MAC 44 security 45 46 47 802.16 802.17 802.20 802.21 802.22

48 802.16 Broadband 802.17 Resilient 802.20 Mobile 802.21 Media 802.22 Cognitive 49 wireless access packet ring broadband wireless independent WRAN 50 802.16.1 Advanced 802.20.1 PICS for handover 802.22.1 Enhance 51 air interface 802.20 harmful interference 52 802.16.2 Coexistence 802.20.2 Minimum protection performance 53 54 Figure 1—Current family of IEEE 802 standards

1 At any given point in time, an IEEE 802 standard may have one or more amendments related to it. Each 2 amendment, once approved, is considered to be part of the base standard. At a future time, these 3 amendments are made a part of the base standard and a new standard is issued. This is illustrated in Figure 2 4 for the case of IEEE Std 802.15.4™-2011 revision which incorporated the amendments IEEE Std 5 802.15.4a™-2007, IEEE Std 802.15.4c™-2009 and IEEE Std 802.15.4d™-2009 into the base standard 6 IEEE Std 802.15.4-2006. 7 8 9 802.15 10 802.15.4-2006 11 Low rate WPAN 12 802.15.4a-2007 802.15 13 Alternative PHYs 802.15.4-2011 14 802.15.4c-2009 China 780 MHz band operation Low rate WPAN 15 802.15.4d-2009 16 Japan 950 MHz band operation 17 Figure 2—Creation of IEEE Std 802.15.4-2011 from base standard and amendments 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54

1 5. Reference models (RMs) 2 3 4 5.1 Introduction 5 6 This clause defines the IEEE 802 RM. The intent of presenting this model is as follows: 7 8 9 a) To provide an overview of the standard

10 b) To serve as a guide to reading other IEEE 802 standards 11 12 13 The IEEE 802 RM is patterned after derived from the open systems interconnection Open Systems 14 Interconnection (OSI) basic reference model RM (OSI/RM), ISO/IEC 7498-11 [B7]. It is assumed that the 15 reader has some familiarity with the OSI/RM and its terminology. The IEEE 802 standards encompass 16 emphasize the functionality of the lowest two layers of the OSI/RM, i.e., physical layer (PHY) and data link 17 layer (DLL), and the higher layers as they relate to network management. The IEEE 802 RM is similar to the 18 OSI/RM in terms of its layers and the placement of its service boundaries. Figure 3 shows the architectural 19 view of IEEE 802 RM for end stations and its relation to the OSI/RM. A variation of the model applies 20 within bridges, as described in 5.3.2. 21 MAC medium access control sublayer LSAP link service access point 22 MSAP MAC service access point PSAP PHY service access point 23

24 Application 25 26 Presentation LSAPs 27 Upper layer Upper layer 28 Session protocols MSAPs protocols 29 Transport Optional 30 MSAPs 31 Network LLC PSAPs LLC 32 MAC and options Optional MAC and options 33 Data link PSAPs 34 35 Physical Physical Physical

36 Medium Medium 37 38 39 Figure 3—IEEE 802 RM for end stations 40 41 For the mandatory packet services supported by all IEEE 802 networks, the DLL is structured as two 42 sublayers, with the LLC sublayer operating over a MAC sublayer. In addition, some IEEE 802 technologies 43 provide direct support by the MAC sublayer for an alternative sublayer operating at the same place in the 44 architecture as does the LLC sublayer, that multiplexes based on the EtherType field. For the other IEEE 45 802 technologies, the equivalent multiplexing functionality is provided by encapsulation of the EtherType 46 within LLC protocol data units (PDUs), using the subnetwork access protocol (SNAP) specified in Clause 9 47 of this standard. 48 49 50 For the mandatory data services supported by all IEEE 802 networks, the DLL is structured as two 51 sublayers, with the LLC sublayer, described in 5.2.2, operating over a MAC sublayer, described in 5.2.3. 52 53 Each IEEE 802 standard has RMs that are more detailed in order to describe the structure for that specific 54 standard. The RMs for the IEEE 802 standards are given in Annex B.

2 MAC medium access control sublayer LSAP link service access point MSAP MAC service access point PSAP PHY service access point 3 4 5 Application 6 Presentation 7 LSAPs Upper layer Upper layer 8 Session protocols MSAPs protocols 9 10 Transport Optional 11 MSAPs 12 Network LLC PSAPs LLC 13 Optional Data link MAC and options MAC and options 14 PSAPs

15 Physical Physical Physical 16 17 Medium Medium 18 19 Figure 4—IEEE 802 RM for end stations 20 21 The IEEE 802 implementation models (IEEE 802 IMs) are more specific than the IEEE 802 RMs, allowing 22 differentiation between implementation approaches (e.g., different MAC protocols and PHY layers). 23 24 Figure 4 illustrates an IEEE Std 802.3 IM and its relation to the IEEE 802 RM. 25 26 LLC LLC 27 LLC logical link control sublayer 28 MAC MAC MAC medium access control sublayer

29 RS PHY physical layer device

30 RS reconciliation sublayer CGMII CGMII 100 Gb/s media independent interface 31 PCS PCS physical coding sublayer 32 FEC forward error correction 33 FEC (optional) PMA physical medium attachment Physical 34 PHY PMA PMD physical medium dependent

35 AN auto negotiation PMD MDI medium dependent interface 36 AN (conditional) 37 38 MDI 39 Medium Medium 40 IEEE 802 RM 802.3 IM (100 Gb/s) 41 42 Figure 5—IEEE 802 RM and an example of an end-station IM 43 44 45 Considerations of management, security, and media-independent handover (MIH) in IEEE 802 networks are 46 also covered by IEEE 802 standards; these optional features lead to an elaboration of the RM, as illustrated 47 in Figure 5. IEEE 802 network management provides a DLL management protocol, e.g., link layer 48 discovery protocol (LLDP), and IEEE Std 802.3 PAUSE, protocols for exchange of management 49 information between stations; managed objects are defined for all IEEE 802 standards. The media 50 independent control function (MICF) is a parallel control plane that provides control functions for different 51 MAC and PHY sublayers. Some examples of this MICF are the IEEE Std 802.21™ media independent 52 handover function (MIHF), the control functions proposed in IEEE 802.19.1 Task Group and IEEE Std 53 802.22™. IEEE Std 802.1X™-2010 forms part of the LLC sublayer and provides a secure, connectionless 54 service immediately above the MAC sublayer.

1 2 3 LLC LLC

4 LLC logical link control sublayer MAC MAC MAC medium access control sublayer 5 RS PHY physical layer device 6 RS reconciliation sublayer 7 CGMII CGMII 100 Gb/s media independent interface 8 PCS PCS physical coding sublayer

9 FEC forward error correction FEC (conditional) PMA physical medium attachment 10 Physical PHY PMA PMD physical medium dependent 11 AN auto negotiation 12 PMD MDI medium dependent interface 13 AN (conditional)

14 MDI 15 Medium Medium 16 17 IEEE 802 RM 802.3 IM (100 Gb/s) 18 Figure 6—IEEE 802 RM and an example of an end-station IM (100 Gb/s) 19 20 21 22 IEEE 802 network MICSAP Higher layers Higher layers 23 management 24 LSAP 25 26 802M LLC 27 Management information 28 802.1X MICF 29 Data link layer MSAP 30 MICLSAP

31 MAC 32 (Managed 33 objects) PSAP

34 MICPSAP 35 PHY PHY 36 37 38 39 Medium Medium 40 41 Figure 7—IEEE 802 RM with end-station management, security and MIH 42 43 44 5.2 RM description for end stations 45 46 The IEEE 802 RM maps to the OSI/RM as shown in Figure 3. The applicable part of the OSI/RM consists of 47 the lowest two layers: the DLL and the PHY. These map onto the same two layers in the IEEE 802 RM. The 48 MAC sublayer of the IEEE 802 RM exists between the PHY layer and the LLC sublayer to provide a 49 common service for the LLC sublayer (certain MAC types provide additional MAC service features that can 50 be used by LLC, in addition to the common core features). Service access points (SAPs) for connecting the 51 layers and sublayers are shown in Figure 3. 52 53 54

1 2 MICSAP 3 IEEE 802 network 4 Higher layers management Higher layers 5 LSAP 6 7 802 management protocols 8 Management 9 information LLC 10 802.1X MICF Data link layer 11 MSAP 12 MICLSAP 13 MAC 14 (Managed objects) 15 PSAP 16 MICPSAP 17 PHY PHY 18 19 20 Medium Medium 21 22 Figure 8—IEEE 802 RM with end-station management, security and MIH 23 24 25 5.2.1 SAPs 26 27 One or more link service access points (LSAPs) provide interface ports to support one or more higher layer 28 users above the LLC sublayer. 29 30 In addition, the end station optionally provides one or more media-independent control service access points 31 (MICSAPs) that interface between one or more higher layers and the control and management planes 32 enabling higher layer information to pass to the MICF and vice versa. 33

34 The MAC sublayer provides one or more MAC service access points (MSAPs) as interface ports to the LLC

35 sublayer in an end station. In general, the MSAP is identified (for transmission and reception) by a single

36 individual 48-bit extended unique identifiers identifier (EUI-48s48) or 64-bit extended unique identifiers

37 identifier (EUI-64s64) and (for reception) by the network-wide broadcast EUI-48 or EUI-64; it can also be

38 identified (for reception) by one or more group EUI-48s or EUI-64s. Clause 8 provides details of how these

39 EUI-48s or EUI-64s are constructed and used. The MAC sublayer optionally provides a media independent

40 control link service access point (MICLSAP) which is used to provide an interface port to support control of

41 the MAC by the medium independent control function (MICF). 42 43 A user of LLC is identified by, at a minimum, the logical concatenation of the MAC Address field 44 (containing an EUI-48 or EUI-64) and the LLC Address field in a frame. See ISO/IEC 8802-2 for a 45 description of LLC addresses. 46 47 48 The PHY provides a physical layer service access point (PSAP). In addition, the PHY layer optionally 49 provides a media independent control physical layer service access point (MICPSAP) which is used to 50 provide an interface port to control of the PHY by the MICF. 51 52 5.2.2 LLC sublayer 53 54 The LLC sublayer contains a variety of entities, as illustrated in Figure 6.

2 Higher layer Higher layer Higher layer Higher layer

3 protocol 1 protocol 2 protocol 2 protocol n

4 LSAP LSAP LSAP LSAP 5 6 Protocol discrimination entity (PDE) 7 8 9 802.1X 802.1AE 802.1AX 10 11 12 MSAP 13 14 Figure 9—LLC sublayer in 802 RM 15 16 The protocol discrimination entity (PDE) is used by the LLC sublayer to determine the higher layer protocol 17 to which to deliver an LLC PDU. Two methods may be used in the PDE. The two methods are: 18 19 1) EtherType protoocol discrimination (EPD) which uses the EtherType value provided at the 20 MSAP, and 21 2) LLC protocol discrimination (LPD), which uses the protocols defined in ISO/IEC 8802-2. 22 23 The LLC sublayer standardEPD provides a connectionless service for protocol discrimination. LPD, ISO/ 24 IEC 8802-2however, describes provides three types of operation for data communication between peer LLC 25 entities: unacknowledged connectionless-mode (LLC Type 1)mode, connection-mode (LLC Type 2)mode, 26 and acknowledged connectionless-mode (LLC Type 3)mode. 27

28 With LLC Type 1 operation, information frames are exchanged between LLC entities without the need for

29 the prior establishment of a logical link between peers. The LLC sublayer does not provide any

30 acknowledgments for these LLC frames, nor does it provide any flow control or error recovery procedures. 31

32 LLC Type 1 also provides a TEST function and an Exchange Identification (XID) function. The capability

33 to act as responder for each of these functions is mandatory: this allows a station that chooses to support

34 initiation of these functions to check the functioning of the communication path between itself and any other

35 station, to discover the existence of other stations, and to find out the LLC capabilities of other stations. 36

37 With LLC Type 2 operation, a logical link is established between pairs of LLC entities prior to any exchange

38 of information frames. In the data transfer phase of operation, information frames are transmitted and

39 delivered in sequence. Error recovery and flow control are provided, within the LLC sublayer. 40

41 With LLC Type 3 operation, information frames are exchanged between LLC entities without the need for

42 the prior establishment of a logical link between peers. However, the frames are acknowledged to allow

43 error recovery and proper ordering. Further, LLC Type 3 operation allows one station to poll another for

44 data. 45 46 NOTE—ISO/IEC 8802-2 defines four classes of LLC, each of which groups together support for a different combination 47 of LLC types. All classes include mandatory support of LLC Type 1. 48 49 The IEEE 802 architecture allows an alternate LLC sublayer that supports protocol discrimination using an 50 EtherType. For example, IEEE Std 802.3 is capable of natively representing the EtherType within its MAC 51 frame format and so a connectionless LLC service can be provided via use of the EtherType without the use 52 of the protocols defined in ISO/IEC 8802-2,which is used to support EPD. IEEE Std 802.3 also natively 53 supports ISO/IEC 8802-2 LLC (over a limited range of packet frame sizes). In other IEEE 802 networks, 54 such as IEEE Std 802.11™, that do not represent EtherTypes in the MAC frame format, protocol

1 identification via the use of an EtherType EPD can be achieved by means of the SNAP, as described in 2 Clause 9. In either of these techniques, the EtherType is effectively being used as a means of identifying an 3 LSAP that provides LLC service to the protocol concerned. New IEEE 802 standards shall support protocol 4 discrimination in the LLC sublayer using EtherTypesEPD. 5 6 IEEE Std 802.1AE™ MAC security provides connectionless user data confidentiality, frame data integrity, 7 and data origin authenticity by media access independent protocols and entities that operate transparently to 8 MAC clients. 9 10 IEEE Std 802.1AX™ provides the ability to aggregate two or more links together to form a single logical 11 link at a higher data rate. 12 13 IEEE Std 802.1X™ 1X provides authentication, authorization, and cryptographic key agreement 14 mechanisms to support secure communication between end stations connected by IEEE 802 networks. 15

16 5.2.3 MAC sublayer 17

18 The MAC sublayer performs the functions necessary to provide packetframe-based, connectionless-

19 mode (datagram style) data transfer between stations in support of the next higher sublayer, as

20 described in 5.1, for networks that support it. The term MAC frame, or simply frame, is used to describe the

21 packets datagrams transferred within the MAC sublayer. In some MAC types, some MAC frames are used

22 in support of the MAC sublayer functionality itself, rather than for transfer of data from the next higher

23 sublayer. 24 25 The principal functions of the MAC sublayer comprise the following: 26 27 — Frame delimiting and recognition 28 — Addressing of destination stations (both as individual stations and as groups of stations) 29 30 — Conveyance of source-station addressing information 31 — Transparent data transfer of PDUs from the next higher sublayer 32 — Protection against errors, generally by means of generating and checking frame check sequences 33 — Control of access to the physical transmission medium 34 35 Other functions of the MAC sublayer—applicable particularly when the supporting implementation includes 36 interconnection devices such as bridges—include flow control between an end station and an 37 interconnection device, as described in 5.3, and filtering of frames according to their destination addresses to 38 reduce the extent of propagation of frames in parts of an IEEE 802 network that do not contain 39 communication paths leading to the intended destination end station(s). 40 41 The functions listed are those of the MAC sublayer as a whole. Responsibility for performing them is 42 distributed across the transmitting and receiving end stations, and any interconnection devices such as 43 bridges. Devices with different roles therefore can behave differently in support of a given function. For 44 example, the basic transmission of a MAC frame by a bridge is very similar to transmission by an end 45 station, but not identical. Principally, the handling of source-station addressing is different. 46 47 The various MAC specifications all specify MAC frame formats in terms of a serial transmission model for 48 the service provided by the supporting PHY. This model supports concepts such as “first bit (e.g., of a 49 particular octet) to be transmitted,” and a strict order of octet transmission, in a uniform manner. However, 50 the ways in which the model has been applied in different MAC specifications are not completely uniform 51 with respect to bit-ordering within octets (see Clause 8, and particularly 8.7, for examples and explanation). 52 53 The serial transmission model does not preclude current or future MAC specifications from using partly or 54 wholly octet-oriented specifications of frame formats or of the interface to the PHY.

1 5.2.4 PHY 2 3 The PHY provides the capability of transmitting and receiving bits between PHY entities. A pair of PHY 4 entities identifies the peer-to-peer unit exchange of bits between two MAC users. 5

6 The PHY provides the capability of transmitting and receiving modulated signals assigned to specific

7 frequency channels, in the case of broadband or wireless, or to a single-channel band, in the case of

8 baseband. 9 10 Note that, whereas the service offered to the MAC sublayer is expressed as the transfer of bits (in sequences 11 representing MAC frames), the actual symbols that are encoded for transmission do not always represent 12 individual bits. Particularly at speeds of 100 Mb/s and above, or for wireless transmission, the PHY layer 13 can map blocks of several bits (e.g., 4, 5, or 8 bits) to different multi-element symbols. In some PHY 14 encodings, these symbols are subject to further transformation before transmission, and in some cases, the 15 transmission is spread over multiple physical data paths. 16 17 18 5.2.5 Layer and sublayer management 19 20 The LLC, MAC, and PHY standards also include a management component that specifies managed objects 21 and aspects of the protocol machine that provides the management view of these resources. See Clause 7 for 22 further information. 23 24 25 5.3 Interconnection and interworking 26 27 In some cases, the end stations in an IEEE 802 network have no need to communicate with end stations on 28 other networks. However, this is not expected to be the norm; there are many cases in which end stations on 29 an IEEE 802 network need to communicate with end stations on other networks and so devices that 30 interconnect the IEEE 802 network with other kinds of networks are required. In addition, several standard 31 methods have been developed that permit a variety of interconnection devices to operate transparently to end 32 stations on a network in order to extend the capabilities available to end stations, particularly in terms of the 33 geographical extent and/or total number of end stations that can be supported. 34 35 Standard methods of interworking fall into the following three general categories, depending on the layer at 36 which the corresponding interconnection devices operate: 37

38 — PHY interconnection, using devices usually termed repeaters or hubs, as described in 5.3.1. 39 — MAC interconnection, using devices termed bridges, as described in 5.3.2. 40 41 — Network-layer interconnection, using devices usually termed routers, as described in 5.3.3. 42 43 5.3.1 PHY interconnection: Repeaters and hubs 44 45 The original IEEE 802 standards were for end stations attached to a shared communication medium. This 46 basic configuration is referred to as a single access domain; the domain consists of the set of stations such 47 that, at most, only one can transmit at a given time, with all other stations acting as (potential) receivers. In 48 this situation the function of handling the “one-at-a-time” access arbitration is performed by the set of 49 MACs on a shared medium. 50 51 A repeater is a device used to interconnect segments of the physical communications media, for example, to 52 extend the range of a network when the physical specifications of the technology would otherwise be 53 exceeded, while providing a single access domain for the attached stations. Repeaters used in support of 54 multiple end stations attached by star-wired network topologies are frequently referred to as hubs.

1 5.3.2 MAC-sublayer interconnection: Bridges 2

3 5.3.2.1 Bridges and bridged IEEE 802 networks 4 5 6 Bridges are stations that interconnect multiple access domains. IEEE Std 802.1D provides the basic 7 specification for bridge interworking among IEEE 802 networks. A bridged IEEE 802 network consists of 8 one or more bridges together with the complete set of access domains that they interconnect. A bridged 9 IEEE 802 network provides end stations belonging to any of its access domains with the connectivity of a 10 network that contains the whole set of attached end stations. IEEE Std 802.1Q adds additional capabilities to 11 the bridge specification in IEEE Std 802.1D including virtual bridged networks (VLANs), priorities, and 12 provider bridging, as defined described in 5.3.2.5. 13 14 A bridged network can provide for the following: 15 16 17 — Communication between stations attached to IEEE 802 networks of different MAC types 18 — Communication between stations attached to networks of different MAC types that conform to the 19 Internal Sublayer Service as specified in IEEE Std 802.1AC. 20 — An increase in the total throughput of a network over that of a purely shared media network 21 22 — An increase in the physical extent of, or number of permissible attachments to, a network

23 — Partitioning of the physical network for administrative or maintenance reasons 24 25 26 The term switch is often used to refer to some classes of bridge. However, there is no consistent meaning 27 applied to the distinction between the terms bridge and switch, and IEEE Std 802.1D does not make any 28 such distinction. Hence, this standard only uses the term bridge. 29 30 5.3.2.2 Relaying and filtering by bridges 31 32 A bridge processes protocols in the MAC sublayer and is functionally transparent to LLC and higher layer 33 protocols. MAC frames are forwarded between access domains, or filtered (i.e., not forwarded to certain 34 access domains), on the basis primarily of EUI-48 addressing information. Figure 7 shows the position of 35 the bridging functions within the MAC sublayer; note particularly that the relaying and filtering functions 36 are considered to belong entirely within the MAC sublayer. 37 38 End station Bridge End station MAC service 39 LLC LLC user 40 Relay MAC service 41 provider

42 MAC sublayer

43 MAC MAC MAC MAC } 44 45 Physical layer 46 47 Media 48 LAN LAN

49 Figure 10—Internal organization of the MAC sublayer with bridging 50 51 52 Filtering by bridges tends to confine traffic to only those parts of the bridged network that lie between 53 transmitting end stations and the intended receivers. This permits a bridged network to support several 54 transmitting end stations at any given time (up to the total number of access domains present).

1 End station Bridge End station 2 MAC service 3 LLC LLC user

4 Relay MAC service 5 provider 6 MAC sublayer 7 MAC MAC MAC MAC } 8 9 Physical layer

10 Media

11 LAN LAN 12 13 Figure 11—Internal organization of the MAC sublayer with bridging 14

15 5.3.2.3 Resolving topologies with multiple paths 16

17 A key aspect of IEEE Std 802.1D and IEEE Std 802.1Q is the specification of the rapid spanning tree

18 protocol (RSTP), which is used by bridges to configure their interconnections in order to prevent looping

19 data paths in the bridged IEEE 802 network. In the event that the basic interconnection topology of bridges

20 and networks contains multiple possible paths between certain points, use of the RSTP blocks some paths in

21 order to produce a simply connected active topology for the flow of MAC user traffic between end stations.

22 For each point of attachment of a bridge to a network, the RSTP selects whether or not MAC user traffic is

23 to be received and transmitted by the bridge at that point of attachment. 24 25 The RSTP adapts to changes in the configuration of the bridged IEEE 802 network, maintaining 26 connectivity while avoiding data loops. Some configuration changes can cause temporary interruptions of 27 connectivity between parts of the bridged IEEE 802 network, typically lasting for a few tens of milliseconds 28 at most. 29 30 31 IEEE Std 802.1Q defines specifies a variant of RSTP, the multiple spanning tree protocol (MSTP), that can 32 configure multiple, independent spanning trees within a bridged network. In addition, IEEE Std 802.1Q also 33 defines specifies shortest path bridging (SPB) which allows the use of shortest path communication within 34 administratively defined network regions, while retaining concurrent support for all existing spanning tree 35 protocols. The use of SPB, both for unicast and multicast, allows multiple paths to be used simultaneously. 36 37 5.3.2.4 Transparent bridging 38 39 IEEE Std 802.1D and IEEE Std 802.1Q specify transparent bridging operation, so called because the MAC 40 bridging function does not require the MAC user frames transmitted and received to carry any additional 41 information relating to the operation of the bridging functions; end-station operation is unchanged by the 42 presence of bridges. 43 44 5.3.2.5 Provider bridging 45 46 IEEE Std 802.1Q specifies the method by which the MAC service is supported by virtual bridged LANs, the 47 principles of operation of those networks, and the operation of VLAN-aware bridges, including 48 management, protocols, and algorithms. The specification standard also enables a service provider to use the 49 architecture and protocols defined specified in order to offer the equivalent of separate LANs, bridged 50 LANs, or virtual bridged LANs to a number of customers, while requiring no cooperation between the 51 customers, and minimal cooperation between each customer and the service provider. 52 53 Provider backbone bridging further extends the concept of provider bridging by allowing a backbone 54 network, under the administrative control of a single backbone service provider, to support multiple service

1 providers, each administering their own distinct provider bridged network to support distinct sets of 2 customers. 3 4 5.3.2.6 Bridging example 5

6 Some bridges are used to interconnect access domains that each contain a very small number of end stations

7 (often, a single end station). Others interconnect multiple access domains that contain principally other

8 bridges, thus, forming a backbone for the bridged IEEE 802 networks. Bridged IEEE 802 network

9 configurations that involve these kinds of interconnection have become widespread as the technologies have

10 developed. These configurations allow the construction of networks with much larger numbers of end

11 stations and much higher aggregate throughput than was previously achievable. 12

13 Figure 8 illustrates the kind of bridged IEEE 802 network that can be configured with bridge-style

14 interconnection. The bridges A and B, and the IEEE Std 802.3 LAN configurations to which they attach, are

15 typical of the older style of bridged IEEE 802 network in which a bridge interconnects a small number of

16 access domains each containing many end stations, as is similar with K and L and their IEEE Std 802.17™

17 ring. The IEEE Std 802.17 ring and the IEEE Std 802.3 links between S and T and S and U form backbone

18 networks. On the other hand, the bridges S, T, and U function as bridge bridges that combines IEEE Std

19 802.17, IEEE Std 802.3 and IEEE Std 802.16™ networks. S is a backbone bridge, handling a number of

20 network attachments. T and U are bridges that support multiple end stations, with connection to the

21 backbonea backbone network. B and K also provide access to the backbonea backbone network. The end

22 station shown connected to S by a point-to-point link could be a server system. 23 24 End station 25 802.11 26 Bridge ...... 27 IEEE 802 28 network link 29 K 30 31 32 802.15.1 33 B 802.17 L

34 802.3 35 36 ... A 37 38 802.3 S

39 ...... 8 2.3 02 40 80 .3 41 42 T U 802.16 43 802.3 44 45 ...... 46 47 Figure 12—A bridged IEEE 802 network 48 49 50 5.3.3 Network-layer interconnection: Routers 51 52 The third category of interconnection uses network-layer interconnection devices, generally known as 53 routers, that operate as IEEE 802 end stations. These process network layer protocols that operate directly 54 above the LLC sublayer or equivalent, with forwarding decisions based on network layer addresses. Details

1 2 End station 3 802.11 Bridge 4 ......

5 IEEE 802 6 network link K 7 8 9

10 802.15.1 11 B 802.17 L 12 802.3 13 ... 14 A 15 802.3 16 S 17 ...... 8 2.3 02 18 80 .3 19 20 T U 802.16 21 802.3 22 23 ...... 24 25 Figure 13—A bridged IEEE 802 network 26 of this kind of interconnection lie outside of the scope of IEEE 802 standards, but the various standard and 27 proprietary network-layer protocols involved represent a very substantial part of the user traffic on many 28 IEEE 802 networks. In particular, IEEE 802 networks are often interconnected by routers for the Internet 29 Protocol (IP) and its related routing and management protocols, either directly to other IEEE 802 networks 30 or by means of WAN links. 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54

1 6. General requirements for an IEEE 802 network 2 3 4 6.1 Services supported 5 6 With the descriptions in Clause 5 as a basis, an IEEE 802 network can be characterized as a communication 7 resource that provides sufficient capabilities to support the MAC service defined specified in IEEE Std 8 802.1AC, between two or more MSAPs. In particular, this requires the ability to convey LLC data from one 9 MSAP to n other MSAPs, where n can be any number from 1 to all of the other MSAPs on the network. An 10 IEEE 802 network is required, at a minimum, to support the MAC Internal Sublayer Service defined 11 specified in IEEE Std 802.1D and IEEE Std 802.1Q1AC, and support the use of EtherTypes for protocol 12 identification at the LLC sublayer. 13 14 15 6.2 Size and extent 16 17 The initial IEEE 802 network technologies were designed to be capable of supporting access domains 18 containing at least 200 end stations and with geographical extent of at least 2 km for IEEE 802 LANs (using 19 PHY repeaters if necessary) and 50 km for metropolitan area networks (MANs). For some IEEE 802 20 networks, subsequent developments in technology and performance have been accompanied by a reduction 21 in the size and extent required in individual access domains, recognizing that these can readily and cost- 22 effectively be interconnected in bridged IEEE 802 networks that are capable of offering at least the original 23 minimum size and extent, with increased overall bandwidth and performance. In other cases, IEEE 802 24 networks have been defined for larger areas, e.g., RANs, using wireless technology. Size and extent 25 requirements for future IEEE 802 network technologies are, similarly, expected to be determined by 26 application needs and opportunities. 27

28 6.3 Error ratios 29 30 31 Error performance of IEEE 802 networks is required to shall be as follows 32 33 a) For wired or optical fiber physical media: Within a single access domain, the probability that a 34 transmitted MAC frame (excluding any preamble) is not reported correctly at the PHY service inter- 35 face of an intended receiving peer MAC entity, due only to operation of the PHY, shall be less than × -8 36 8 10 per octet of MAC frame length.

37 NOTE—For some applications and data rates, better performance than this may be required. 38 39 b) For wired or optical fiber physical media with frames shorter than 2048 octets: The probability that 40 an MSDU delivered at an MSAP contains an undetected error, due to operation of the MAC service -14 41 provider, shall be less than 5 × 10 per octet of MSDU length.

42 NOTE—For example, the worst-case probability of losing a maximum-length IEEE Std 802.3 frame at the PHY is to be 43 less than 1.21 × 10-4, or approximately 1 in 8250. The worst-case probability that a similar frame, which contains an 44 MSDU of 1500 octets, is delivered with an undetected error is to be less than 7.5 × 10-11, or approximately 1 in 13 300 45 000 000.

46 c) For wireless physical media: The error performance within a single access domain is variable over

47 time and no guarantee of service can be given. 48 49 50 6.4 Transient service interruption 51 52 Insertion of a station into, or removal of a station from, an IEEE 802 network shall cause at most a transient 53 loss of availability of the access domain(s) to which the station attaches, lasting not more than 1 s. Failure of 54 a station, including loss of power, shall not cause more than at most a transient fault for the access domain(s)

1 to which it was attached, with duration of order 1 s. The preceding requirements assume that the new 2 configuration of the network without the lost station is valid. 3 4 6.5 Safety, lightning and galvanic protection 5 6 Equipment implementing IEEE 802 standards is typically subject to guidance and requirements relating to 7 safety and to protection of the equipment and its users from lightning and galvanic effects. Such guidance 8 and requirements are outside of the scope of IEEE 802 standardization; they are typically specified by other 9 organizations with different legal, geographical, and industrial scope. However, the general underlying 10 concerns can have an influence on the PHY aspects of IEEE 802 standards. 11 12 13 6.6 Regulatory requirements 14 15 Equipment implementing IEEE 802 standards can be subject to regulations imposed within particular 16 geographical and political domains. For example, the deployment of equipment implementing IEEE 802 17 wireless standards are subject to local regulations that pertain to the use of radio-frequency transmission. 18 Such regulations are typically outside of the scope of IEEE 802 standardization; they are typically specified 19 by other organizations with different legal, geographical, and industrial scope. However, the general 20 underlying concerns can have an influence on the MAC and PHY aspects of IEEE 802 standards. 21 22 While regulatory compliance is out of scope of IEEE 802 standards, the need to comply with regulations can 23 influence the design of IEEE 802 standards. 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54

1 7. IEEE 802 network management 2 3 4 7.1 General 5 6 The provision of an adequate means of remote management is an important factor in the design of today's 7 network equipment. Such management mechanisms fall into two broad categories: those that provide 8 general-purpose management capability, allowing control and monitoring for a wide variety of purposes, 9 and those that provide specific capabilities aimed at a particular aspect of management. These aspects of 10 management are discussed in 7.2 and 7.3, respectively. 11 12 13 7.2 General-purpose IEEE 802 network management 14 15 This subclause introduces the functions of management to assist in the identification of the requirements 16 placed on IEEE 802 network equipment for support of management facilities, and it identifies 17 general-purpose management standards that may be used as the basis of developing management 18 specifications for such equipment. 19 20 7.2.1 Management functions 21 22 Management functions relate to users’ needs for facilities that support the planning, organization, 23 supervision, control, protection and security of communications resources, and account for their use. These 24 facilities may be categorized as supporting the functional areas of configuration, fault, performance, 25 security, and accounting management. These can be summarized as follows. 26 27 — Configuration management provides for the identification of communications resources, 28 initialization, reset and closeshut-down, the supply of operational parameters, and the establishment 29 and discovery of the relationships between resources. 30 — Fault management provides for fault prevention, detection, diagnosis, and correction. 31 32 — Performance management provides for evaluation of the behavior of communications resources and 33 of the effectiveness of communication activities.

34 — Security management provides for the protection of resources. 35 36 — Accounting management provides for the identification and distribution of costs and the setting of 37 charges. 38 39 Management facilities in IEEE 802 network equipment address some or all of these areas, as appropriate to 40 the needs of that equipment and the environment in which it is to be operated. 41 42 7.2.2 Management architecture 43 44 The management facilities defined specified in IEEE 802 standards are based on the concept of managed 45 objects, which model the semantics of management operations. Operations on a managed object supply 46 information concerning, or facilitate control over the managed object and thereby, indirectly, the process or 47 entity associated with that object. 48 49 Operations on a managed object can be initiated by mechanisms local to the equipment being managed (e.g., 50 via a control panel built into the equipment), or can be initiated from a remote management system by means 51 of a general-purpose management protocol carried using the data services provided by the IEEE 802 52 network to which the equipment being managed is connected. The entity that does both the network 53 communication of the management protocol and the interaction to and from the managed objects is called 54 the agent.

1 The simple network management protocol Simple Network Management Protocol (SNMP), as described in 2 RFC 3411 [B5]8, provides a general-purpose management protocol that is relevant to can be used for the 3 management of IEEE 802 network equipment. 4 5 7.2.3 Managed object definitions 6 7 In order for an IEEE 802 standard to specify management facilities, it is necessary for it to define specify 8 managed objects that model the operations that can be performed on the communications resources specified 9 in the standard. The components of a managed object definition are: 10 11 a) A definition of the functionality provided by the managed object, and the relationship between this 12 functionality and the resource to which it relates.

13 b) A definition of the syntax that is used to convey management operations, and their arguments and

14 results, in a management protocol. 15 c) An address that allows the management protocol to specifically communicate with the managed 16 object in question. In IEEE 802 this is done with an object identifier (OID), as described in 17 Clause 10. 18 19 The functionality of a managed object can be described in a manner that is independent of the protocol that 20 is used; this abstract definition can then be used in conjunction with a definition of the syntactic elements 21 required in order to produce a complete definition of the object for use with specific management protocols. 22 23 The SNMP protocol is used in many cases together with the structure of management information known as 24 SMIv2, IETF RFC 2578 [B33]2578, RFC 2579 [B3], and RFC 2580 [B4], which uses a set of macros based 25 on a subset of ASN.1 for defining managed objects. 26 27 The choice of notational tools for defining managed objects depensd depends on which of the available 28 management protocols the standard supports. 29 30 31 7.3 Special-purpose IEEE 802 network management standards 32 33 Special-purpose protocols relating to the management functionality of IEEE 802 stations can be developed 34 where the use of a general-purpose management protocol is inappropriate. Examples of special-purpose 35 management protocols that can be found in the family of IEEE 802 standards include the connectivity fault 36 management protocol defined specified in IEEE Std 802.1Q, the operations, administration, and 37 maintenance (OAM) protocol defined specified in IEEE Std 802.3, and LLDP in IEEE Std 802.1AB™. 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 8The numbers in brackets correspond to those of the bibliography in Annex A.

1 8. EUI-48s, EUI-64s and protocol identifiers 2 3 4 8.1 General 5 6 7 9. Extended unique identifiers (EUIs) 8

9 9.1 Overview and history 10 11 The IEEE makes it possible for organizations to employ unique individual EUI-48s, EUI-64s, group 12 addresses, and protocol identifiers. A universal address is an EUI-48 or EUI-64 that is globally unique. In 13 addition, the IEEE has set aside a group of EUI-48s and EUI-64s that are locally administered. EUI-48 14 addressing is required if interoperability through bridges is required for an IEEE 802 a standard. New 15 standards that only require routed connectivity should use EUI-64 addressing. 16 17 The IEEE enables globally unique addresses, referred to as universal addresses, by assigning 18 organizationally unique identifiers (OUIs), which are three octets (24 bits) in length. Because the assignment 19 of the OUI in effect reserves a block of each derivative identifier (i.e., blocks of individual EUI-48s, EUI- 20 64s, group addresses, and protocol identifiers), the address space of the OUI is chosen to be large. Although 21 the OUIs are 24 bits in length, as shown in Figure 9, but their true address space is 22 bits. The LSB of the 22 first octet may be set to one or zero depending on the application. The next-to-LSB of the first octet is zero, 23 for all universal addresses. The remaining 22 bitsbits of the OUI are assigned by the RAC; when used in a 24 field of an IEEE 802 standard, which the organization field of the OUI shall not be changed contain the 25 value assigned by the assignee, result in 222 (approximately 4 million) identifiers; see Figure 8RAC. 26 27 Application dependent: e.g., I/G address bit, M bit in protocol IDs 28 Octet 0 0

29 Octet 1

30 Octet 2 31 32 Figure 9—Structure of an OUI 33 34 Application dependent: e.g., Application dependent: e.g., 35 U/L bit in addresses, X bit in protocol IDs I/G bit in addresses, M bit in protocol IDs 36 37 Octet 0 38 Octet 1 39 Octet 2 40 41 Figure 10—Structure of an OUI 42 43 The universal administration of EUI-48s began with the Xerox Corporation administering Block Identifiers 44 (Block IDs) for Ethernet addresses. Block IDs, referred to as OUI by the IEEE, were assigned by the 45 Ethernet Administration Office and were 24 bits in length. An organization developed addresses by 46 assigning the remaining 24 bits. For example, the address as represented by the six octets P-Q-R-S-T-U 47 comprises the Block ID, P-Q-R, and the locally assigned octets S-T-U. 48 49 The IEEE, because of the work in IEEE 802 on standardizing networking technologies, has assumed the 50 responsibility of defining and carrying out procedures for the universal administration of these addresses. 51 The IEEE has also been designated by ISO/IEC to act as a registration authority for ISO/IEC 8802 series of 52 standards. In carrying out the procedures, the IEEE acts as the registration authority for OUIs.9 The 53 54 9Interested applicants should contact the IEEE Registration Authority, http://standards.ieee.org/develop/regauth/oui

1 responsibility for defining the procedures is discharged by the IEEE Registration Authority Committee 2 (RAC), which is chartered by the IEEE Standards Association Board of Governors. In IEEE 802 networks, 3 the term MAC address refers to an EUI-48. In some IEEE 802 standards, the term extended address refers to 4 EUI-64. 5 6 9.2 Notational conventions 7 8 9 Hexadecimal representation is a sequence of octet values in which the values of the individual octets are 10 displayed in order from left to right, with each octet value represented as a two-digit hexadecimal numeral, 11 and with the resulting pairs of hexadecimal digits separated by hyphens. The order of the hexadecimal digits 12 in each pair, and the mapping between the hexadecimal digits and the bits of the octet value, are derived by 13 interpreting the bits of the octet value as a binary numeral using the normal mathematical rules for digit 14 significance. 15 16 Bit-reversed representation is a sequence of octet values in which the values of the individual octets are 17 displayed in order from left to right, with each octet value represented as a two-digit hexadecimal numeral, 18 and with the resulting pairs of hexadecimal digits separated by colons. The order of the hexadecimal digits 19 in each pair, and the mapping between the hexadecimal digits and the bits of the octet value, are derived by 20 reversing the order of the bits in the octet value and interpreting the resulting bit sequence as a binary 21 numeral using the normal mathematical rules for digit significance. 22 23 NOTE—The bit-reversed representation is of historical interest only and is no longer applicable to any active IEEE 802 standard. 24 25 Figure 10 provides a comparative example of bit-reversed and hexadecimal representation. 26 27 28 9.3 OUI 29 30 OUIs allow a general means of assuring unique identifiers for a number of purposes. OUIs are a 22-bit field 31 assigned from a 24-bit space. The IEEE Registration Authority assigns OUI values. The IEEE Registration 32 Authority also has additional products that use the OUI assignment as its base, e.g. OUI-36, but which do 33 not include the assignment of an OUI10. 34 35 NOTE—The acronym OUI without modification is only used to refer to the 24-bit field assigned by the Registration 36 Authority. The acronym Acronym OUI-36 is used refers to refer to the 36a product that allows assignment of 4096 glo- 37 bally unique EUI-bit field assigned by the Registration Authority48 addresses. However, while not appropriate, the acronym OUI has been used to refer to generally to all Registration Authority assignments. As a result, the use of OUI is not 38 always consistent within all IEEE standards. 39

40 The standard representation of the OUI is as a string of three octets, using the hexadecimal representation. 41 42 43 9.4 Universal addresses 44 45 9.4.1 Concept 46 47 The concept of universal addressing is based on the idea that all potential members of a network need to 48 have a unique identifier (if they are going to coexist in the network)identifier. The advantage of a universal 49 address is that a station with such an address can be attached to any IEEE 802 network in the world with an 50 assurance that the address is unique, if all stations adhere to the rules and that the security of the network 51 prevents malicious spoofing of addresses. Two different lengths of the universal address have been 52 definedspecified, 48 bit (EUI-48) and 64 bit (EUI-64). 53 54 10More information on OUIs can be found on the IEEE Registration Authority web site, http://standards.ieee.org/develop/regauth/

1 EUI-64s were introduced when it seemed that the EUI-48 space would be exhausted in the near future. 2 Initially, new IEEE standards projects that did not require backward compatibility with EUI-48 were 3 requested to use the new EUI-64. This led to some IEEE 802 standards adopting EUI-64, which cannot be 4 bridged onto IEEE 802 networks that use EUI-48. The reason is that the bridging function in IEEE Std 5 802.1D and IEEE Std 802.1Q assume that addresses are unique among all the connected networks. 6 Truncating an EUI-64 into an EUI-48 field can lead to two stations having the same EUI-48 value. Instead, 7 traffic between EUI-64 and EUI-48 addressed networks needs to be routed at a layer above the DLL. 8 9 Universal addresses are created from the OUI. The universally or locally administered (U/L) address bit is 10 the bit of octet 0 adjacent to the I/G address bit. This bit indicates whether the address has been assigned by 11 a local or universal administrator. Universally administered addresses have the U/L bit set to 0. If the U/L bit 12 is set to 1, the remaining 46 bits (i.e. all bits except the I/G and U/L bits) have been are locally administered 13 and have no relationship should not be expected to meet the uniqueness requirement of the IEEE-assigned 14 values (as described herein). 15 16 17 A universal address consists of two parts: one the leading bits are assigned by the IEEE Registration 18 Authority and one assigned the remaining bits by the that assignee. The IEEE Registration Authority offers 19 several products (e.g., OUI, OUI-36, IAB-12). They vary in the number of universal addresses the assignee 20 can create. In the case where the IEEE assigns an OUI, the first 24 bits correspond to the OUI as assigned by 21 the IEEE, except that the assignee may set the LSB of the first octet to one for group addresses or set it to 22 zero for individual addresses. The second part, comprising the remaining 24 bits for an EUI-48 or the 23 remaining 40 bits for an EUI-64, is administered by the assignee. In the EUI-48, an example of which is 24 shown in Figure 10, the OUI is contained in octets 0, 1, 2, and the value assigned by the assignee is 25 contained in octets 3, 4, 5. This address, including its OUI, is used throughout this document as the basis for 26 examples of EUI-48s and protocol identifiers. In the case where the IEEE assigns an OUI-36, the first 36 bits 27 correspond to the OUI-36 as assigned by the IEEE, except that the assignee may set the LSB of the first octet 28 to one for group addresses or set it to zero for individual addresses. The second part, comprising the 29 remaining 12 bits for an EUI-48 or the remaining 28 bits for an EUI-64, is administered by the assignee. In 30 the EUI-48, an example of which is shown in Figure 9, the OUI is contained in octets 0, 1, 2, 3 and the LSB 31 least significant nibble of octet 4, and the value assigned by the assignee is contained in the MSB most 32 significant nibble of octet 4 and octet 5. 33 34 Hexadecimal representation: AC-DE-48-00-00-80 35 Bit-reversed representation: 35:7B:12:00:00:01 36 37 Octet: 012345

38 LSB MSB LSB MSB 39 40 0011 0101 0111 1011 0001 0010 0000 0000 0000 0000 0000 0001 41 U/L address bit 42 I/G address bit 43 44 OUI 45 OUI-36

46 U/L address bit

47 I/G address bit 48 Octet 0 1 0 1 0 1 1 0 0 49 Octet 1 1 1 0 1 1 1 1 0 50 Octet 2 0 1 0 0 1 0 0 0 51 Octet 3 0 0 0 0 0 0 0 0 Octet 4 0 0 0 0 0 0 0 0 52 Octet 5 1 0 0 0 0 0 0 0 53 54 Figure 11—Example EUI-48

1 NOTE—The octet string AC-DE-48 is used because it is clear when a bit pattern is reversed. This OUI could be in use 2 and is not a reserved value.

3 An IEEE 802 network with EUI-48s is not able to bridge to an IEEE 802 network with EUI-64s. Bridging

4 for an IEEE 802 network with EUI-64 addresses is not currently defined. 5 6 An example of an EUI-64 is illustrated in Figure 11. 7 8 Hexadecimal representation: AC-DE-48-00-00-80-53-84 9 Bit-reversed representation: 35:7B:12:00:00:01:CA:21 10 Octet: 012345 67

11 LSB MSB LSB MSB 12 13 0011 0101 0111 1011 0001 0010 0000 0000 0000 0000 0000 0001 1100 1010 0010 0001 14 U/L address bit 15 I/G address bit

16 OUI 17 OUI-36 18 U/L address bit

19 I/G address bit 20 Octet 0 1 0 1 0 1 1 0 0 21 Octet 1 1 1 0 1 1 1 1 0 22 Octet 2 0 1 0 0 1 0 0 0 23 Octet 3 0 0 0 0 0 0 0 0 Octet 4 0 0 0 0 0 0 0 0 24 Octet 5 1 0 0 0 0 0 0 0 25 Octet 6 0 1 0 1 0 0 1 1 26 Octet 7 1 0 0 0 0 1 0 0 27 Figure 12—Example EUI-64 28 29 30 The standard representation of an EUI-48 is as a string of six octets, using the hexadecimal representation. 31 See 8.7 for further specification relating to use of the bit-reversed representation. 32 33 NOTE—The upper, bit-stream representation of the EUI-48 in Figure 10 and the EUI-64 in Figure 11 shows the LSB of 34 each octet first; this corresponds to the data-communications convention for representing bit-serial transmission in left- 35 to-right order, applied to the model for transmission of EUI-48 fields (see 5.2.3) and EUI-6 64 fields. See also 8.7 for further discussion of bit-ordering issues. The lower, octet-sequence representation shows the bits within each octet in the 36 usual order for binary numerals; the order of octet transmission is from the top downward. 37 38 39 The individual/group (I/G) address bit, least significant bit (LSB) of octet 0, is used to identify the 40 destination address as an individual address or a group address. If the I/G address bit is 0, it indicates that the 41 address field contains an individual address. If this bit is 1, the address field contains a group address that 42 identifies one or more (or all) stations connected to the IEEE 802 network. The all-stations broadcast 43 address is a special, predefined group address of all 1’s. 44 45 9.4.2 Interworking with EUI-48 and EUI-64 46 47 EUI-64s were introduced in response to concerns that the EUI-48 space could be exhausted by the breadth of 48 products using OUIs to generate unique identifiers. Initially, new IEEE standards projects that did not 49 require backward compatibility with EUI-48 were requested to use the new EUI-64. This led to some IEEE 50 802 standards adopting EUI-64, which cannot be bridged onto IEEE 802 networks that use EUI-48. The 51 reason is that the bridging function in IEEE Std 802.1D and IEEE Std 802.1Q assume that addresses are 52 unique among all the connected networks. Truncating an EUI-64 into an EUI-48 field can lead to two 53 stations having the same EUI-48 value. Instead, traffic between EUI-64 and EUI-48 addressed networks 54 needs to be routed at a layer above the DLL.

1 Bridging for an IEEE 802 network with EUI-64 addresses is not currently specified. 2 3 9.4.3 Assignment by organizations 4 5 The IEEE intends not to assign additional OUIs or OUI-36s to any organization unless the organization has 6 exhausted this address block. 7 8 9 Varying the last 24 bits in the block of EUI-48s for a given OUI allows the OUI assignee approximately 16 10 million unique individual addresses and 16 million unique group addresses It is important to note that no 11 other organization may assign (i.e., universally unique). Similarly, varying the last 8 bits in the block of 12 EUI-48s for a given OUI-36 allows the OUI-36 assignee 4096 unique individual addresses and 4096 unique 13 group addresses. The IEEE intends not to assign additional created from OUIs or OUI-36s to any 14 organization unless the organization has exhausted this address block. Therefore, it is important for the IEEE 15 to maintain a single point of contact with each assignee to avoid complicating the assignment process. It is 16 important to note that in no way should these addresses not be used for purposes that would lead to skipping 17 large numbers of them (for example, as product identifiers for the purpose of aiding company inventory 18 procedures). The IEEE asks that organizations not misuse the assignments of the last 24 24 bits and thereby 19 unnecessarily exhaust the block. There are sufficient identifiers to satisfy most needs for a long time, even in 20 volume production; however, no address space is infinite. 21 22 The method that an assignee uses to ensure that no two of its stations carry the same address depends on the 23 assignment or manufacturing process, the nature of the organization, and the organization’s philosophy. 24 However, the users of networks worldwide expect to have unique addresses. The ultimate responsibility for 25 assuring that user expectations and requirements are met, therefore, lies with the organization offering such 26 stations. 27

28 9.4.4 Uniqueness of address assignment 29 30 31 An issue to be considered is the nature of the station to which uniqueness of address assignment applies. 32 33 The recommended approach is for each station associated with a distinct point of attachment to an IEEE 802 34 network to have its own unique EUI-48 or EUI-64. Typically, therefore, an IEEE 802 network adapter card 35 (or, e.g., an equivalent chip or set of chips on a motherboard) should have one unique EUI-48 or EUI-64 for 36 each IEEE 802 network attachment that it can support at a given time. 37

38 NOTE—It is recognized that an alternative approach has gained currency in some implementations, in which the station 39 is interpreted as a complete computer system, which can have multiple attachments to different networks. Under this 40 interpretation, a single EUI-48 or EUI-64 is used to identify all of the system’s points of attachment to the networks in 41 question. This approach, unlike the recommended one, does not automatically meet the requirements of IEEE Std 42 802.1D MAC bridging. 43

44 9.5 Local addresses 45 46 47 Local addresses are EUI-48s or EUI-64s for which there is no guarantee that the address is unique in all 48 IEEE 802 networks. Local addresses may be assigned any value that has the U/L bit set to indicate a local 49 addresses and an I/G bit value that indicates whether the address is individual or group. Local addresses 50 need to be unique on a LAN or bridged LAN unless the bridges support VLANs with independent learning. 51 52 The I/G bit is set as described in 8.4.1. 53 54 NOTE—OUI assignments do not apply to local addresses

1 9.6 SNAP identifiers 2 3 Clause 9 specifies the SNAP, which permits multiplexing and demultiplexing of private and public 4 protocols, as described in 9.1, among multiple users of a data link. An organization that has an OUI assigned 5 to it may use its OUI to assign universally unique protocol identifiers to its own protocols, for use in the 6 protocol identification field of SNAP data units, as described in 9.5. 7

8 The protocol identifier is five octets in length and follows the LLC header in a frame. The first three octets

9 of the protocol identifier consist of the OUI in exactly the same fashion as in EUI-48. The remaining two

10 octets are administered by the assignee. In the protocol identifier, an example of which is shown in

11 Figure 11, the OUI is contained in octets 0, 1, 2 with octets 3, 4 being assigned by the assignee of the OUI. 12 13 Hexadecimal representation: AC-DE-48-00-80 14 Octet: 01234 15 LSB MSB LSB MSB 16 17 0011 0101 0111 1011 0001 0010 0000 0000 0000 0001

18 X bit 19 M bit 20 OUI 21 22 X bit 23 M bit 24 Octet 0 1 0 1 0 1 1 0 0 25 Octet 1 1 1 0 1 1 1 1 0 Octet 2 0 1 0 0 1 0 0 0 26 Octet 3 0 0 0 0 0 0 0 0 27 Octet 4 1 0 0 0 0 0 0 0

28 Figure 13—Protocol identifier 29 30 31 The standard representation of a protocol identifier is as a string of five octets using the hexadecimal 32 representation. 33 34 The LSB of the first octet of a protocol identifier is referred to as the M bit. All identifiers derived from 35 OUIs assigned by the IEEE shall have the M bit set to zero. Values with the M bit set to one are reserved. 36 37 Protocol identifiers may be assigned universally or locally. The X bit of a protocol identifier is the bit of the 38 first octet adjacent to the M bit. All identifiers derived from OUIs assigned by the IEEE have the X bit set to 39 zero and are universally assigned. Values with the X bit set to one are locally assigned and have no 40 relationship to the IEEE-assigned values. They may be used, but there is no assurance of uniqueness. 41 42 43 9.7 OUI and OUI-36 as protocol identifiers 44 45 An organization that has an OUI or OUI-36 assigned to it may use its OUI or OUI-36 to assign universally 46 unique protocol identifiers to its own protocols, for use with various protocols described in IEEE 802 47 standards, potentially with additional octets as part of the identifier. 48 49 The LSB of the first octet of a OUI, as shown in Figure 12, or OUI-36, as shown in Figure 13, used as as 50 protocol identifier is referred to as the M bit. All OUI & OUI-36 identifiers assigned by the IEEE shall have 51 the M bit set to zero. Values with the M bit set to one are reserved. 52 53 The X bit of a protocol identifier is the bit of the first octet adjacent to the M bit. All OUI and OUI-36 54 identifiers assigned by the IEEE with the X bit set to zero may also be used to create EUI-48 and EUI-64

1 Hexadecimal representation: AC-DE-48 2 Octet: 012 3 X bit

4 LSB MSB LSB MSB M bit 5 Octet 0 1 0 1 0 1 1 0 0 6 0011 0101 0111 1011 0001 0010 Octet 1 1 1 0 1 1 1 1 0 7 X bit Octet 2 0 1 0 0 1 0 0 0 8 M bit 9 Figure 14—Format of an OUI used as protocol identifier 10

25 11 26 9.8 Standardized EUI-48 and EUI-64 group addresses 27 28 The previous subclauses described the assignment of individual and group EUI-48s and EUI-64s, and 29 protocol identifiers for public or private use by private organizations. There is also a need for standardized 30 EUI-48 and EUI-64 group addresses to be used with standard protocols. The administration of these 31 standardized EUI-48 and EUI-64 group addresses, including the procedure for application and a list of 12 32 currently assigned values, is described on the web pages for the IEEE Registration Authority . These 33 standardized EUI-48 and EUI-64 group addressess come from a block of universally administered EUI-48s 34 and EUI-64s derived from an OUI that has been assigned by the IEEE for this purpose. 35 36 9.9 Bit-ordering and different MACs 37 38 39 Throughout this subclause, considerations relating to the order of bit and/or octet transmission refer to the 40 basic bit-serial model of transmission that applies to the representation of MAC frames at the boundary 41 between the MAC and the PHY, as described in 5.2.3. 42 43 9.9.1 General considerations 44 45 The transmission of data on IEEE Std 802.3 networks is represented, as described in 5.2.3, as occurring LSB 46 first within each octet. This is true for the entire frame: MAC Address fields (source and destination 47 EUI-48’s), MAC-specific fields (e.g., length Length/Type field), and the MAC Information field. 48 49 On some other network types, each octet of the MAC Information field is represented as being transmitted 50 most significant bit (MSB) first. The MAC Address fields (source and destination EUI-48), however, are 51 represented as being transmitted with the LSB of each octet first. Thus, the first bit transmitted is the I/G 52 53 11These were previously referred to as standard group MAC addresses. 54 12http://standards.ieee.org/develop/regauth/grpmac

1 address bit, as in IEEE Std 802.3 networks. For frames that originate within the MAC (e.g., MAC-embedded 2 management frames), the ordering of bits within the MAC Information field is defined specified by the 3 MAC specification.standard 4 5 For most purposes, the difference in the bit ordering used to represent transmission of the octets of the MAC 6 Information field is of no consequence, whether considered within a given MAC type, or across different 7 MAC types. Each octet of user data is mapped to and from the appropriate ordering, symmetrically by the 8 transmitting and receiving MAC entities. An unfortunate exception has occurred, however, where the octets 9 concerned are those of an EUI-48 that is embedded, as user data, in the MAC Information field. 10 11 9.9.2 Recommendation 12 13 Designers of protocols that operate above the DLL are strongly recommended to avoid specifying new 14 protocols that result in frames of noncanonical format. 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54

1 9. EtherTypes and SNAP Protocol identifiers 2 3 4 9.1 Introduction 5 6 This clause defines a method describes methods that allows multiple network layer protocols to coexist in an 7 IEEE 802 network. This protocol provides for the coexistence of multiple network layer protocols, the 8 migration of existing networks to future standard protocols, and allows future higher layer protocols to be 9 accommodated.These methods provide for 10 11 EtherType shall be supported for protocol identification at the LLC sublayer in new IEEE 802 standard. 12 13 14 9.2 Basic concepts 15 16 — Coexistence the coexistence of multiple network layer protocols, 17 — the migration of existing networks to future standard protocols, and 18 19 — the accomodation of future higher layer protocols. 20 21 Within a given layer, entities can exchange data by a mutually agreed upon protocol mechanism. A pair of 22 entities that do not support a common protocol cannot communicate with each other. For multiple protocols 23 to coexist within a layer, it is necessary to determine which protocol is to be invoked to process a service 24 data unit delivered by the lower layer. 25 26 9.2.1 Multiple protocols above the LLC sublayer 27

28 Various network and higher layer protocols have been assigned reserved LLC addressesaddresses or

29 EtherTypes, as recorded by the IEEE Registration Authority13. These addresses permit multiple network

30 layer protocols to coexist at a single MAC station. One half of the LLC address space is reserved for such

31 assignment. 32

33 Other protocols are accommodated in two ways. One way is by local assignment of LSAPs, for which the

34 other half of the LLC address space is available. Thus, users can agree to use locally assigned LSAPs for

35 either an instance of communication or a type of communication. 36 37 The second way is through the use of a particular reserved LLC address value that has been assigned for use 38 in conjunction with the SNAP identifiers, as described in 9.5, which provides for multiplexing and 39 demultiplexing of public and private protocols among multiple users of a data link. 40 41 42 9.2.2 Multiple protocols above the alternative sublayer 43 44 The Ethernet MAC frame format includes a 16-bit type value, whose function is to identify the particular 45 protocol pertaining to the user data contained in the frame. See 9.3 for further details. 46 47 This clause describes the protocol identifiers used for the LPD and EPD methods as well as a protocol 48 identifier based on OUI-36. 49 50 The EPD method shall be the primary specified means for protocol identification at the LLC sublayer in 51 IEEE 802 standards developed after January 201114, excluding amendements to existing standards. 52 53 13More information can be found at http://standards.ieee.org/develop/regauth/llc 54 14IEEE Std 802.2™-1989 (reaffirmed 2003) was administratively withdrawn as an IEEE standard on 11 January 2011.

1 9.3 EtherTypes 2

3 9.3.1 Format, function, and administration 4 5 Protocol discrimination performed by the EPD method is based on parsing EtherType 6 informationEtherTypes. The For example, the value of the Type/Length field in the IEEE Std 802.3 MAC 7 frame format directs the protocol parser into the LLC space if the value is less than 1536. This allows frames 8 of both formats to be freely intermixed on a given IEEE 802 network and at a given station. 9 10 11 The administration of the registration of EtherType values was originally undertaken by the Xerox 12 Corporation under the name “Type Value”. The operation of the EtherType registration authority along with 13 full recognition of all assignments of EtherTypes made by the predecessor administration is now the 14 responsibility of the IEEE Registration Authority. 15 16 EtherTypes protocol identification values are assigned by the IEEE Registration Authority15 and are used to 17 identify the protocol that is to be invoked to process the user data in the frame. An EtherType is a sequence 18 of two octets, interpreted as a 16-bit numeric value with the first octet containing the most significant 8 bits 19 and the second octet containing the least significant 8 bits. Values in the range 0–1535 are not available for 20 use in order to retain legacy compatibility with Length field based protocols. 21

22 Examples of EtherTypes are 0x0800 and 0x8DD, which are used to identify IPV4 and IPV6, respectively. 23 24 It is strongly recommended when designing new protocols to be identified by an EtherType, that fields be 25 assigned to provide for sub-typing. The format used for subtyping in a protocol described in 9.2.3 is 26 preferredrecommended. 27 28 29 9.3.2 EtherTypes for prototype and vendor-specific protocol development 30 31 The existing EtherType identifier space is a finite resource. In order to develop protocols that use an 32 EtherType value as a protocol identifier, it has historically been necessary for vendors to apply for type 33 values from this limited identifier space, both for development purposes and for assignment to the final 34 protocol. This can lead to waste of the identifier space for no useful purpose, as some of these protocol 35 developments do not result in viable or usable protocols. The mechanisms identified in this clause allow 36 prototype and experimental protocols to be developed without consuming type values, and also provides a 37 means whereby protocol developers can assign permanent protocol identifier values without consuming type 38 values from this limited resource. 39

40 The EtherType identifier space is a finite resource. The vendor specific protocol identifier is a means

41 whereby protocol developers may assign permanent protocol identifier values without consuming type

42 values from this limited resource. This can be useful for prototype, experimental and private/proprietary

43 protocols to be developed without impacting the global EtherType namespace. 44 45 These objectives are supported by following EtherType assignments, and associated rules for their use: 46 47 48 a) Two EtherType values, known as the Local Experimental EtherTypes, as defined specified in 9.2.3, 49 assigned, as the name implies, for experimental use within a local area; and

50 b) A single EtherType value, known as the OUI Extended EtherType, as defined specified in 9.2.4,

51 assigned for the identification of vendor-specific protocols. 52

53 15More information on EtherTypes can be found on the IEEE Registration Authority web site, http://standards.ieee.org/develop/ 54 regauth/ethertype/

1 The values of the Local Experimental EtherTypes and the OUI Extended EtherType are defined listed in 2 Table 1. 3 4 5 Table 1—Assigned EtherType values 6

7 Name Value 8 9 Local Experimental EtherType 1 88-B5 10 Local Experimental EtherType 2 88-B6 11 12 OUI Extended EtherType 88-B7 13 14 15 9.3.3 Local Experimental EtherTypes 16

17 The Local Experimental EtherTypes are intended for use in conjunction with experimental protocol

18 development within a privately administered development network; for example within an experimental

19 network that has no wide area connectivity. Within that network, a local administrator is free to use a Local

20 Experimental EtherType and to assign subtypes for protocol development purposes. However, by virtue of

21 the way these EtherTypes are intended to be used, the following practical and administrative constraints

22 apply to their use: 23

24 a) Since the format for protocols using the Local Experimental EtherTypes does not contain a means to

25 identify the administrative domain, it may not be possible to identify the protocol of a frame if pro-

26 tocols developed within different administrative domains using Local Experimental EtherTypes are

27 used in the same network. Hence, the use of these EtherTypes to identify protocols can only be

28 achieved reliably if all uses of the EtherTypes are within the control of a single administrative

29 domain. Therefore, these EtherTypes shall not be used in protocols or products that are to be

30 released for use in the wider networking community, as freeware, shareware, or as any part of a

31 company’s commercial product offering. Products shall be transitioned to a product EtherType

32 before it is deployed in an environment outside the developing organization’s administrative con-

33 trol; for example, when deployed with a customer or any other connected environments for testing. 34 35 b) Any request by any individual or organization to have the value of a Local Experimental EtherType 36 shall not be permanently assigned for use with a given protocol or protocols will be summarily 37 refusedprotocols. 38 c) It is recommended that end End stations that bound any administrative domain should be configured 39 to prevent frames containing a Local Experimental EtherType from passing either into or out of a 40 domain in which its contents can be misinterpreted. For example, the default configuration of any 41 firewall should be to not pass this EtherType. 42 43 A Local Experimental EtherType is used in the normal way, as a value that is placed in the Type/Length 44 field of an Ethernet frame, or as described in 9.4 for encapsulation of Ethernet frames over LLC using SNAP 45 identifiers, as described in 9.5. 46 47 A Local Experimental EtherType is processed by the PDE in the same manner as other Ethertype values. 48 49 In order to allow for different experimental protocols, sub-protocols, and versions, to coexist within the 50 same experimental network, a protocol subtype and a protocol version identifier shall be used in conjunction 51 with the Local Experimental EtherType value. This is illustrated in Figure 12, which shows the format of an 52 Ethernet IEEE Std 802.3 frame carrying a Local Experimental EtherType. The lengths of the protocol 53 subtype and the protocol version identifier fields, and their order of appearance within the frame, are not 54 constrained by this standard.

2 IEEE Std 802.3 MAC header MAC information 3 Destination Source Local experimental Protocol subtype Protocol version Protocol data FCS 4 MAC address MAC address EtherType (2 octets) (N octets)

5 Protocol identification field Protocol data field 6 7 Figure 12—Example of an IEEE Std 802.3 frame carrying the Local Experimental EtherType 8 9 10 Two Local Experimental EtherType values are provided, to allow protocols that need more than one distinct 11 EtherType value, or two distinct protocols, to be developed within a single administrative domain. In 12 particular, the provision of two Local Experimental EtherTypes allows for cases where it is necessary to be 13 able to distinguish protocols or sub-protocols at the EtherType level, in order to facilitate the use of filtering 14 actions in bridges. 15 16 The combination of the Local Experimental EtherType value, the protocol subtype, and the protocol version, 17 provide the protocol identifier for the experimental protocol. The values assigned to the protocol subtype 18 and protocol version are locally administered; their meaning cannot therefore be correctly interpreted 19 outside of the administrative domain within which the value was allocated. 20 21 NOTE—The use of this format provides for a simple migration path to the use of a distinct EtherType permanently 22 assigned to the protocol. The routine examination of proposals made to the IEEE Registration Authority for the alloca- 23 tion of EtherTypes includes a check that the proposed protocol format has sufficient subtype capability to withstand enhancement by the originator without the need for the assignment of a further EtherType in the future, and inclusion of 24 the subtype and version values could be deemed to meet this requirement. While the existence of such a mechanism in 25 the protocol specification is not in itself sufficient to ensure that an application for an EtherType succeeds, its existence 26 is a necessary element of an acceptable protocol design. The subtyping mechanism defined described here offers one 27 way that this requirement may be met. 28 29 9.3.4 OUI Extended EtherType 30 31 The OUI Extended EtherType provides a means of protocol identification similar to that offered by the 32 SNAP identifier described in 9.59.5.1. Like the SNAP identifier, the OUI Extended EtherType allows an 33 organization to use protocol identifiers, as described in 9.5. An organization allocates protocol identifiers to 34 its own protocols, in a manner that ensures that the protocol identifier is globally unique. 35 36 NOTE—The requirement for global uniqueness of protocol identifiers means that if protocol identifier X has been allo- 37 cated for use by an organization’s protocol, then that protocol identifier can be used with either the SNAP identifier or 38 the OUI Extended EtherType to identify that protocol. Conversely, it means that protocol identifier X cannot be used to identify any other protocol. 39 40 The OUI Extended EtherType is used in processed by the normal way, as a value that is placed PDE in the 41 Type/Length field of an Ethernet frame, or same manner as described in 9.4 for encapsulation of Ethernet 42 frames over LLCother Ethertype values. Immediately following the EtherType value is a protocol identifier, 43 as described in 9.5, consisting of a three-octet OUI value followed by two octets administered by the OUI 44 assignee. The OUI value provides an administrative context within which the assignee can allocate values to 45 a 16-bit protocol subtype. This approach is closely similar to the LLCLPD-based SNAP identifier 46 mechanism defined specified in Clause 99.5; however, the OUI Extended EtherType is used in place of the 47 LLC header. 48 49 NOTE—The two octets of the protocol identifier that are administered by the OUI assignee can be used in any way that 50 the assignee chooses; however, as OUIs are a finite resource, it is advisable not to choose an allocation approach that is 51 wasteful, as would be the case, for example, if the assignee chose to use these two octets to encode a length value. 52 53 Figure 13 shows the format of an IEEE Std 802.3 frame carrying the OUI Extended EtherType in the 54 Length/Type field. The value used for the OUI component of the protocol identifier is an OUI value

1 assigned to the organization that has developed the vendor-specific protocol. The combination of the OUI 2 Extended EtherType, the OUI value, and the 16-bit value administered by the OUI assignee provide a 3 unique protocol identifier for the vendor-specific protocol. The 16-bit values are administered by the 4 organization to which the OUI has been assigned; their meaning can therefore only be correctly interpreted 5 by reference to the organization that owns the OUI concerned. 6 7 IEEE Std 802.3 MAC header MAC information 8 Destination Source OUI extended Protocol identifier Protocol data FCS 9 MAC address MAC address EtherType (2 octets) (5 octets) (N octets) 10 Protocol identification field Protocol data field

11 Figure 13—IEEE Std 802.3 frame with the OUI Extended EtherType encoded

12 in the Length/Type field 13 14 NOTE—As the protocol designer is free to define specify the structure of the Protocol Data field, pad octets can be 15 included in the definition of this field, for example, for the purposes of alignment with 4-octet or 8-octet boundaries. 16

17 As discussed in 9.2.3, it is good protocol development practice to use a protocol subtype, along with a

18 protocol version identifier in order to avoid having to allocate a new protocol identifier when a protocol is

19 revised or enhanced. Users of the OUI Extended EtherType are therefore encouraged to include protocol

20 subtype and version information in the specification of the protocol data for their protocols. 21

22 It is the intention that this method of protocol identification be used in products or protocols that are planned

23 to be released into multi-vendor environments outside of the control of the administration that assigns the

24 protocol identifier. The use of this mechanism allows such protocols to be developed and distributed without

25 the need for a specific EtherType to be assigned for the use of each protocol. 26

27 As the OUI Extended EtherType is a normal EtherType value, it is possible to use the encoding described in

28 9.4 to carry its value within an LLC PDU, using a SNAP identifier with the RFC 1042 OUI. Figure 14 shows

29 the format of an IEEE Std 802.3 frame carrying the OUI Extended EtherType encoded in this way. In this

30 case, it would be more appropriate to use SNAP identifier directly (i.e., omit the RFC 1042 OUI and OUI

31 Extended EtherType fields shown in Figure 14); however, this is a valid encoding of the OUI Extended

32 EtherType that can result from the application of the encapsulation described in 9.4. 33 34 LLC PDU header and SNAP IEEE Std 802.3 MAC header SNAP data fieldl 35 identification field 36 Destination Source Length SNAP SNAP UI RFC 1042 OUI extended Protocol Protocol data FCS MAC address MAC address “AA” “AA” “03” OUI 00-00-00 EtherType identifier 37 SNAP identifier field Protocol data 38 field 39 40 Figure 14—IEEE Std 802.3 frame with the OUI Extended EtherType encoded in an LLC PDU 41 42 43 9.4 OUI and OUI-36 as protocol identifiers 44 45 An organization that has an OUI or OUI-36 assigned to it may use its OUI or OUI-36 to assign universally 46 unique protocol identifiers to its own protocols, for use with various protocols described in IEEE 802 47 standards, potentially with additional octets as part of the identifier. 48 49 The LSB of the first octet of a OUI, as shown in Figure 15, or OUI-36, as shown in Figure 16, used as a 50 protocol identifier is referred to as the M bit. All OUI & OUI-36 identifiers assigned by the IEEE have the M 51 bit set to zero. Values with the M bit set to one are reserved. 52 53 The X bit of a protocol identifier is the bit of the first octet adjacent to the M bit. All OUI and OUI-36 54 identifiers assigned by the IEEE with the X bit set to zero may also be used to create EUI-48 and EUI-64

1 Hexadecimal representation: AC-DE-48 2 Octet: 012 3 X bit

4 LSB MSB LSB MSB M bit 5 Octet 0 1 0 1 0 1 1 0 0 6 0011 0101 0111 1011 0001 0010 Octet 1 1 1 0 1 1 1 1 0 7 X bit Octet 2 0 1 0 0 1 0 0 0 8 M bit 9 Figure 15—Format of an OUI used as protocol identifier 10

11 Hexadecimal representation: AC-DE-48-00-8 12 Octet: 01234 13 X bit 14 LSB MSB LSB MSB M bit 15 Octet 0 1 0 1 0 1 1 0 0 16 0011 0101 0111 1011 0001 0010 0000 0000 1000 Octet 1 1 1 0 1 1 1 1 0 Octet 2 0 1 0 0 1 0 0 0 X bit 17 Octet 3 0 0 0 0 0 0 0 0 18 M bit Octet 4 1 0 0 0 19 20 Figure 16—Format of an OUI-36 used as a protocol identifier 21 addresses. An OUI or OUI-36 identifier assigned by the IEEE with the X bit set one shall only be used as an 22 OUI or OUI-36 protocol identifier, respectively. Any EUI-48 or EUI-64 addresses created with these OUI or 23 OUI-36 have no relationship to the IEEE-assigned values; they may be used, but there is no assurance of 24 uniqueness. 25 26 9.5 Encapsulation of Ethernet frames over LLCwith LPD 27 28 29 This subclause specifies the standard method for conveying Ethernet frames across IEEE 802 networks that 30 offer only the LLC sublayer, LPD function and not the alternative sublayer, directly above EPD function in 31 the MAC LLC sublayer. 32 33 An Ethernet frame conveyed on an LLCLPD-only IEEE 802 network shall be encapsulated in a SNAP data 34 unit contained in an LLC PDU of type UI, as follows: 35 36 a) The Protocol Identification field of the SNAP data unit shall contain a SNAP identifier in which 37 1) The three OUI octets each take the value zero. 38 2) The two remaining octets take the values, in the same order, of the two octets of the Ethernet 39 frame’s EtherType. 40 b) The Protocol Data field of the SNAP data unit shall contain the user data octets, in order, of the 41 Ethernet frame.

42 c) The values of the Destination MAC Address field and Source MAC Address field of the Ethernet

43 frame shall be used in the Destination MAC Address field and Source MAC Address field, respec-

44 tively, of the MAC frame in which the SNAP data unit is conveyed. 45 46 NOTE—This encapsulation was originally specified in RFC 1042 [B1], which contains recommendations relating to its 47 use. Further recommendations are contained in RFC 1390 [B2]. 48 49 9.6 SNAP identifiersSNAP 50 51 SNAP provides a method for multiplexing and demultiplexing of private and public protocols among 52 multiple users of a data link. An organization that has an OUI assigned to it may use its OUI to assign 53 universally unique protocol identifiers to its own protocols, for use in the protocol identification field of 54 SNAP data units.

1 9.6.1 SNAP identifier 2

3 The protocol identifier is five octets in length and follows the LLC header in a frame. The first three octets

4 of the protocol identifier consist of the OUI in exactly the same fashion as in EUI-48. The remaining two

5 octets are administered by the assignee. In the protocol identifier, an example of which is shown in

6 Figure 17, the OUI is contained in octets 0, 1, 2 with octets 3, 4 being assigned by the assignee of the OUI. 7 8 Hexadecimal representation: AC-DE-48-00-80 9 Octet: 01234 10 LSB MSB LSB MSB 11 12 0011 0101 0111 1011 0001 0010 0000 0000 0000 0001

13 X bit 14 M bit 15 OUI 16 17 X bit 18 M bit 19 Octet 0 1 0 1 0 1 1 0 0 20 Octet 1 1 1 0 1 1 1 1 0 Octet 2 0 1 0 0 1 0 0 0 21 Octet 3 0 0 0 0 0 0 0 0 22 Octet 4 1 0 0 0 0 0 0 0

23 Figure 17—Protocol identifier 24 25 26 The standard representation of a protocol identifier is as a string of five octets using the hexadecimal 27 representation. 28 29 The LSB of the first octet of a protocol identifier is referred to as the M bit. All identifiers derived from 30 OUIs assigned by the IEEE shall have the M bit set to zero. Values with the M bit set to one are reserved. 31 32 33 Protocol identifiers may be assigned universally or locally. The X bit of a protocol identifier is the bit of the 34 first octet adjacent to the M bit. All identifiers derived from OUIs assigned by the IEEE have the X bit set to 35 zero and are universally assigned. Values with the X bit set to one are locally assigned and have no 36 relationship to the IEEE-assigned values. They may be used, but there is no assurance of uniqueness. 37 38 9.6.2 SNAP address 39

40 The reserved LLC address for use with SNAP is called the SNAP address. It is defined specified to be the bit

41 pattern (starting with the LSB) Z1010101, in which the symbol Z indicates that either value 0 or 1 can occur,

42 depending on the context in which the address appears (as specified in ISO/IEC 8802-2). The two possible

43 values have hexadecimal representation AA and AB. 44 45 The SNAP address identifies, at each MSAP, a single LSAP for standard, public, and private protocol usage. 46 To permit multiple public and private network layer protocols to coexist at one MSAP, each public or 47 private protocol using SNAP must shall employ a protocol identifier that enables SNAP to discriminate 48 among these protocols. 49 50 51 9.6.3 SNAP data unit format 52 53 Each SNAP data unit shall conform to the format shown in Figure 18 and shall form the entire content of the 54 LLC information field.

1 In Figure 18, the Protocol Identification field is a five-octet field containing a protocol identifier whose 2 format and administration are as described in 8.59.5.1. The Protocol Data field is a field whose length, 3 format, and content are defined specified by a public or private protocol specification. Each public or private 4 protocol begins its PDU format with the Protocol Identification field, which shall contain the protocol 5 identifier assigned to the protocol. 6 7 Octet: 0 4(N+4)5 8 SNAP identifier Protocol data 9

10 Figure 18—SNAP data unit format 11 12 13 Figure 19 illustrates how a SNAP data unit appears in a complete MAC frame (the IEEE Std 802.3 MAC 14 format is used for the example). The LLC control field (CTL) is shown for PDU type UI, Unnumbered 15 Information, which is the most commonly used PDU type in this context; however, other information- 16 carrying LLC PDU types may also be used with SNAP identifiers. 17 18 IEEE Std 802.3 MAC header MAC information = LLC PDU

19 Destination Source Length SNAP SNAP UI SNAP identifier Protocol data FCS 20 MAC address MAC address N+8 “AA” “AA” “03” (N octets) 21 DSAP SSAP CTL Protocol Protocol data field identification field 22 23 LLC PDU header SNAP data unit 24 Figure 19—SNAP data unit in IEEE Std 802.3 MAC frame 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54

1 10. Allocation of object identifier (OID) values in IEEE 802 standards 2 3 4 10.1 General 5 6 From time to time, various IEEE 802 standards have a requirement to allocate OID values—the most 7 common example being for the purpose of defining management information base (MIB) objects for SNMP, 8 but other examples exist. MIB modules describe the structure of the management data of a device subsystem 9 and use a hierarchical name space based on OIDs to identify variables. This clause defines specifies a simple 10 and consistent OID hierarchy, based on the use of the OID value that has been assigned by ISO to identify 11 the IEEE 802 series of standards. This hierarchy should be used by all current and future IEEE 802 Working 12 Groups, and can be used flexibly to meet the needs of the standards defined developed by those working 13 groups. This establishes a consistent practice within IEEE 802 for the development and allocation of OIDs. 14 Consistency of OID allocation facilitates implementation and operation of IEEE 802 compliant equipment. 15 16 17 10.2 OIDs and ISO standards 18 19 An OID is an ASN.1 data type, defined specified in ITU-T Recommendation X.660, that is used as a means 20 of defining unique identifiers for objects. Values of the OID data type can then be used to name the objects 21 to which they relate. 22 23 The OID data type consists of a sequence of one or more non-negative integers, often referred to as arcs, that 24 define specify a hierarchy, or tree, of OID values. The first arc in the sequence identifies the registration 25 authority responsible for allocating the values of the second and subsequent arcs. For example: 26 27 iso (1) 28

29 indicates that an initial arc value of 1 identifies ISO as the registration authority. Subsequent arcs in the

30 sequence aredetermined are determined by ISO, or are allocated by registration authorities subordinate to

31 ISO. 32

33 Under the iso arc, a second arc has been allocated to identify organizations recognized by ISO, such as the

34 IEEE; hence, the two-integer sequence 35 36 iso (1) iso-identified-organization (3) 37 38 39 Under the iso-identified-organization arc, a subsequent arc has been allocated to identify the IEEE; hence, 40 the three-integer sequence 41 42 iso (1) iso-identified-organization (3) ieee (111) 43 44 indicates that the fourth integer identifies a particular registry within the IEEE, and that the allocation of the 45 fourth and subsequent arcs is the responsibility of the IEEE. Under the ieee arc, the IEEE Registration 46 Authority has defined specified an arc for the numbered series of IEEE standards; hence, the four-integer 47 sequence 48 49 iso (1) iso-identified-organization (3) ieee (111) 50 standards-association-numbered-series-standards (2) 51 52 indicates that the fifth integer is used to identify a particular IEEE numbered series standard. The actual 53 number corresponding to the numbered series standard is used in the fifth arc; hence the following identifies 54 the IEEE 802 series of standards:

1 iso (1) iso-identified-organization (3) ieee (111) 2 standards-association-numbered-series-standards (2) ieee-802 (802) 3 4 The responsibility for allocating the subsequent arcs under iso (1) iso-identified-organization (3) ieee (111) 5 standards-association-numbered-series-standards (2) ieee-802 (802) lies with IEEE 802. 6

7 As the standard number 802 is used to identify the member of the family of IEEE 802 standards, this

8 particular sequence of integer values can form the basis of an OID hierarchy for use by the individual

9 standards in the IEEE 802 family. The act of assigning a number to a standard has the effect of automatically

10 assigning an OID arc to that standard, and therefore no further administrative effort is needed before that

11 standard can allocate OID values under that point in the tree, using the subsequent arcs. 12 13 14 10.3 The OID hierarchy for IEEE 802 standards 15

16 The OID value assigned to the family of IEEE 802 standards is: 17 18 iso (1) iso-identified-organization (3) ieee (111) 19 standards-association-numbered-series-standards (2) ieee-802 (802) 20 21 22 The next arc under iso (1) iso-identified-organization (3) ieee (111) standards-association-numbered-series- 23 standards (2) ieee-802 (802) shall be is used to differentiate between members of the family of IEEE 802 24 standards, by using it as a working group designator, as follows: 25 26 iso (1) iso-identified-organization (3) ieee (111) 27 standards-association-numbered-series-standards (2) ieee-802 (802) ieee802dotX (X) 28 29 where X is the working group number of the IEEE 802 Working Group responsible for that standard. These 30 arcs are assigned for use in all current and future IEEE 802.X standards. 31 32 For example, under this hierarchy, the value used within the for standards defined developed by the IEEE 33 802.3 Working Group is: 34

35 iso (1) iso-identified-organization (3) ieee (111)

36 standards-association-numbered-series-standards (2) ieee-802 (802) ieee802dot3 (3) 37 38 and the value used within the for IEEE 802.11 standards is: 39 40

41 iso (1) iso-identified-organization (3) ieee (111) 42 standards-association-numbered-series-standards (2) ieee-802 (802) ieee802dot11 (11) 43 44 The working group concerned is free to decide how further arcs are allocated within their standards, in a 45 manner that makes sense for their particular needs. 46 47 It is the responsibility of each working group to ensure that any values that are allocated to the fifth and 48 subsequent arcs are documented, in a manner that ensures that the same OID value cannot be assigned to 49 two different objects. In the IEEE 802.1 Working Group, this has been achieved in the past by placing tables 50 of OID allocations in an annex within the standard concerned16; in the IEEE 802.3 Working Group, a master 51 spreadsheet of allocated OID values is maintained by the Chair and posted on their website. For future 52 allocations, adopting a master spreadsheet approach is appropriate. 53 54 16More information on IEEE 802.1 OIDs can be found on the working group web site, http://www.ieee802.org/1/pages/OIDS.html

1 It is important that the allocation scheme for the fifth and subsequent arcs is constructed in a manner that 2 leaves appropriate “escapes” for uses that cannot be foreseen. The simple expedient of allocating a “type of 3 allocation” value as the fifth arc is sufficient to ensure that such an escape is always available. 4 5 10.4 The OID hierarchy under iso(1) std(0) iso8802(8802) 6 7 The 2001 revision of this standard documented the use of iso(1) std(0) iso8802(8802) as the root arc under 8 which IEEE 802 Standards standards would develop their OID hierarchies. The use of this root arc is 9 deprecated. 10 11 12 10.5 Migration from previous OID allocations 13 14 The OID hierarchy described in this clause need not have any effect upon existing IEEE 802 standards that 15 have already solved this problem by using a specific allocation obtained elsewhere (for example, from 16 ANSI). The primary aims of documenting this procedure are:. 17 18 a) To ensure that OIDs can be allocated under iso(1) std(0) iso8802(8802) in a manner that ensures that 19 they are unique, and 20 b) To avoid the need for any further administrative overhead (such as applying for the use of an OID 21 arc) for any future uses of OIDs in IEEE 802 standards. 22 23 With the hierarchy as defined specified in this clause, as new working groups are created in IEEE 802, their 24 base OID arc is also created automatically, so no administrative effort is required on the part of the working 25 group, other than to determine how the fifth and subsequent arcs are used in their standards. 26 27 For those working groups that have already made use of other allocation schemes (e.g., IEEE Std 802.3 and 28 IEEE Std 802.1), it may be considered appropriate to migrate existing allocations to the hierarchy defined 29 specified in this clause. In considering this, the following should be borne in mind: 30 31 — While it might be perceived as “tidy” to have all IEEE 802 OIDs allocated under a single arc of the 32 OID tree, this is not a requirement for any other reason; one OID value is no better or no worse than 33 any other from a technical point of view (with the possible exception that the encoded length can 34 vary with the number of arcs to be encoded), as long as any given OID identifies a single object. 35 17 36 — If migration is desired, there is no requirement to remove the old OID values . Indeed, this is not 37 permitted for objects defined in SNMP MIB modules that are not obsolete, as specified in IETF RFC 2578, nor is it permitted to associate such objects with more than one OID value. Instead, new defi- 38 18 39 nitions are required to be created and registered under the desired OID tree . 40 41 42 43 44 45 46 47 48 49 50 51 17There is no general requirement that an object should only have a single identifier; if it has more than one, then it can be “reached” by following more than one set of branches of the naming tree, just as a map can provide more than one path to a destination. 52 18 This appears to contradict the earlier statement and footnote that indicate that it doesn’t matter if multiple object identifiers point at 53 the same object; however, this is a specific requirement imposed on MIB objects for SNMP by the relevant Internet Engineering Task 54 Force (IETF) standards, and not a general rule.

1 Annex A 2

3 (informative) 4 5 6 Bibliography 7 8 Bibliographic references are resources that provide additional or helpful material but do not need to be 9 understood or used to implement this standard. Reference to these resources is made for informational use 10 only. 11 12 13 14 A.1 General IEEE 802 standards 15 16 [B1] IEEE Std 802.1AB™, IEEE Standard for Local and Metropolitan Area Networks—Station and 19 17 Medium Access Control Connectivity Discovery. 18 19 [B2] IEEE Std 802.1AC™, IEEE Standard for Local and Metropolitan Area Networks—Media Access Con- 20 trol (MAC) Service definition. 21 22 [B3] IEEE Std 802.1AE™, IEEE Standard for Local and Metropolitan Area Networks: Media Access Con- 23 trol (MAC) Security. 24 25 [B4] IEEE Std 802.1AR™, IEEE Standard for Local and Metropolitan Area Networks—Secure Device 26 Identity. 27 28 [B5] IEEE Std 802.1AS™, IEEE Standard for Local and Metropolitan Area Networks—Timing and Syn- 29 chronization for Time-Sensitive Applications in Bridged Local Area Networks. 30 31 [B6] IEEE Std 802.1AX™, IEEE Standard for Local and Metropolitan Area Networks—Link Aggregation. 32 33 [B7] IEEE Std 802.1BA™, IEEE Standard for Local and Metropolitan Area Networks—Audio Video 34 Bridging (AVB) Systems. 35 36 [B8] IEEE Std 802.1BR™, IEEE Standard for Local and Metropolitan Area Networks—Virtual Bridged 37 Local Area Networks – Bridge Port Extension 38 39 [B9] IEEE Std 802.1D™, IEEE Standard for Local and Metropolitan Area Networks: Media Access Control 40 (MAC) Bridges. 41 42 [B10] IEEE Std 802.1Q™, IEEE Standard for Local and Metropolitan Area Networks—Media Access Con- 43 trol (MAC) Bridges and Virtual Bridged Local Area Networks. 44 45 [B11] IEEE Std 802.1X™, IEEE Standard for Local and Metropolitan Area Networks—Port-Based Net- 46 work Access Control. 47 48 [B12] IEEE Std 802.3™, IEEE Standard for Ethernet. 49

50 [B13] IEEE Std 802.3.1™, IEEE Standard for Management Information Base (MIB) Definitions for Ether-

51 net 52

53 19The IEEE standards and products referred to in Annex A are trademarks owned by the Institute of Electrical and Electronics 54 Engineers, Incorporated.

1 [B14] IEEE Std 802.11™, IEEE Standard for Information technology—Telecommunications and Informa- 2 tion Exchange Between Systems—Local and Metropolitan Area Networks—Specific Requirements—Part 3 11: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Specifications. 4 5 [B15] IEEE Std 802.15.1™, IEEE Standard for Information technology—Telecommunications and infor- 6 mation exchange between systems—Local and Metropolitan Area Networks—Specific requirements—Part 7 15.1: Wireless LAN medium access control (MAC) and physical layer (PHY) specifications for wireless 8 personal area networks (WPANs). 9 10 [B16] IEEE Std 802.15.2™, IEEE Recommended Practice for Information technology—Telecommunica- 11 tions and Information Exchange Between Systems—Local and Metropolitan Area Networks—Specific 12 Requirements—Part 15.2: Coexistence of Wireless Personal Area Networks with Other Wireless Devices 13 Operating in Unlicensed Frequency Bands. 14

15 [B17] IEEE Std 802.15.3™, IEEE Standard for Information technology—Telecommunications and Infor-

16 mation Exchange Between Systems—Local and Metropolitan Area Networks—Specific Requirements—

17 Part 15.3: Wireless Medium Access Control (MAC) and Physical Layer (PHY) Specifications for High Rate

18 Wireless Personal Area Networks (WPANs). 19

20 [B18] IEEE Std 802.15.4™, IEEE Standard for Local and Metropolitan Area Networks—Part 15.4: Low-

21 Rate Wireless Personal Area Networks (LR-WPANs). 22 23 [B19] IEEE Std 802.15.5™, IEEE Recommended Practice for Information technology—Telecommunica- 24 tions and information exchange between systems—Local and metropolitan area networks—Specific 25 requirements—Part 15.5: Mesh Topology Capability in Wireless Personal Area Networks (WPANs). 26 27 [B20] IEEE Std 802.15.7™, IEEE Standard for Local and Metropolitan Area Networks—Part 15.7: Short- 28 Range Wireless Optical Communication Using Visible Light. 29 30 [B21] IEEE Std 802.16™, IEEE Standard for Air Interface for Broadband Wireless Access Systems. 31 32 33 [B22] IEEE Std 802.16.1™, IEEE Standard for WirelessMAN-Advanced Air Interface for Broadband Wire- 34 less Access Systems. 35 36 [B23] IEEE Std 802.16.2™, IEEE Recommended Practice for Local and Metropolitan Area Networks - 37 Coexistence of Fixed Broadband Wireless Access Systems. 38 39 [B24] IEEE Std 802.17™, IEEE Standard for Information technology—Telecommunications and informa- 40 tion exchange between systems—Local and Metropolitan Area Networks—Specific requirements—Part 17: 41 Resilient packet ring (RPR) access method and physical layer. 42 43 [B25] IEEE Std 802.20™, IEEE Standard for Local and Metropolitan Area Networks—Part 20: Air Inter- 44 face for Mobile Broadband Wireless Access Systems Supporting Vehicular Mobility—Physical and Media 45 Access Control Layer Specification. 46 47 [B26] IEEE Std 802.20.2™, IEEE Standard for Conformance to IEEE 802.20 Systems—Protocol Imple- 48 mentation Conformance Statement (PICS) Proforma. 49 50 [B27] IEEE Std 802.20.3™, IEEE Standard for Minimum Performance Characteristics of IEEE 802.20 Ter- 51 minals and Base Stations/Access Nodes 52 53 [B28] IEEE Std 802.21™, IEEE Standard for Local and Metropolitan Area Networks—Media Independent 54 Handover Services.

1 [B29] IEEE Std 802.22™, IEEE Standard for Information Technology—Telecommunications and informa- 2 tion exchange between systems Wireless Regional Area Networks (WRAN)—Specific requirements Part 3 22: Cognitive Wireless RAN Medium Access Control (MAC) and Physical Layer (PHY) Specifications: 4 Policies and Procedures for Operation in the TV Bands 5 6 [B30] IEEE Std 802.22.1™, IEEE Standard for Information Technology—Telecommunications and infor- 7 mation exchange between systems—Local and Metropolitan Area Networks—Specific requirements Part 8 22.1: Standard to Enhance Harmful Interference Protection for Low-Power Licensed Devices Operating in 9 TV Broadcast Bands 10 11 12 A.2 Other standards developing organizations 13 14 [B31] IETF RFC 1042, A Standard for the Transmission of IP Datagrams over IEEE 802 Networks. Postel, 15 J., and Reynolds, J., February 1988.20 16 17 [B32] IETF RFC 1390, Transmission of IP and ARP over FDDI Networks. Katz, D., January 1993. 18 19 [B33] IETF RFC 2578, STD 58, Structure of Management Information Version 2 (SMIv2), McCloghrie, K., 20 Perkins, D., Schoenwaelder, J., Case, J., Rose, M. and S. Waldbusser, April 1999. 21 22 [B34] IETF RFC 2579, STD 58, Textual Conventions for SMIv2, McCloghrie, K., Perkins, D., Schoen- 23 waelder, J., Case, J., Rose, M. and S. Waldbusser, April 1999. 24 25 [B35] IETF RFC 2580, STD 58, Conformance Statements for SMIv2, McCloghrie, K., Perkins, D., Schoen- 26 waelder, J., Case, J., Rose, M. and S. Waldbusser, April 1999. 27 28 [B36] IETF RFC 3411, STD 62, An Architecture for Describing Simple Network Management Protocol 29 (SNMP) Management Frameworks. 30 31 [B37] IETF RFC 5677, IEEE 802.21 Mobility Services Framework Design (MSFD). Melia, T., Bajko, G., 32 Das, S., Golmie, N., and Zuniga, JCJ. C., December 2009. 33 34 [B38] 35 36 [B39] ISO/IEC 7498-1:1994, Information technology—Open Systems Interconnection—Basic Reference 37 Model: The Basic Model. 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 20Internet RFCs are available from the IETF at http://tools.ietf.org/index.

1 Annex B 2

3 (informative) 4 5 6 Reference models (RMs) for IEEE 802 Standards 7 8

9 B.1 IEEE Std 802.3 RMs 10 11 IEEE Std 802.3 offers multiple options, each of which has a different RM. 12 13 The basic RM for IEEE Std 802.3 stations without optional sublayers is illustrated in Figure B.1. 14 15 OAM operations, administration and MSAP MAC service access point 16 maintenance sublayer OSAP OAM service access point 17 RS reconciliation sublayer MCSAP MAC control service access point 18 LSAP link service access point PSAP PHY service access point 19 20 21 Network LSAP 22 MAC Client MSAP 23 Data link 24 MAC PSAP 25 26 RS IEEE Std 802.3 27 Physical Scope PHY 28

29 Medium Medium 30 31 Figure B.1—Basic RM for IEEE Std 802.3 stations 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54

1 The RM for IEEE Std 802.3 including IEEE Std 802.3az-2010 and IEEE Std 802.3bf-2011 is illustrated in 2 Figure B.2. 3

4 OAM operations, administration and MSAP MAC service access point

5 maintenance sublayer OSAP OAM service access point

6 RS reconciliation sublayer MCSAP MAC control service access point

7 LSAP link service access point PSAP PHY service access point 8 9 LSAP 10 Network 11 MAC Client MSAP OSAP 12 MCSAP Energy efficient 13 OAM (optional) Ethernet PSAP 14 Data link (optional) 15 MAC Control (optional) IEEE Std 802.3 Time sync PSAP 16 (optional) Scope PSAP 17 MAC 18 RS 19 Physical PHY 20 21 Medium Medium 22 23 Figure B.2—The RM for IEEE Std 802.3 point-to-point stations 24 25 26 The RM for IEEE Std 802.3 for point-to-multipoint Ethernet passive optical networks (EPON) optical line 27 terminal (OLT) is illustrated in Figure B.3. 28 OAM operations, administration and MSAP MAC service access point 29 maintenance sublayer OSAP OAM service access point 30 RS reconciliation sublayer MCSAP MAC control service access point 31 LSAP link service access point PSAP PHY service access point 32 33 LSAP 34 Network OSAP 35 36 MSAP MAC Client MCSAP MAC Client MAC Client 37 MSAP OAM (optional) OAM (optional) OAM (optional) 38 Data link MSAP 39 Multipoint MAC Control 40 PSAP 41 MAC MAC MAC 42 IEEE Std 802.3 RS 43 Scope Physical PHY 44 Time sync PSAP (optional) 45 46 Medium Medium

47 Figure B.3—IEEE Std 802.3 RM for point-to-multipoint optical line terminal 48 49 50 51 52 53 54

1 The RM for IEEE Std 802.3 Ethernet passive optical networks (EPON) optical network unit (ONU) is 2 illustrated in Figure B.4. 3

4 OAM operations, administration and MSAP MAC service access point

5 maintenance sublayer OSAP OAM service access point

6 RS reconciliation sublayer MCSAP MAC control service access point

7 LSAP link service access point PSAP PHY service access point 8 9 LSAP 10 Network 11 MAC Client MSAP OSAP 12 MCSAP 13 OAM (optional) 14 Data link 15 Multipoint MAC Control MSAP IEEE Std 802.3 16 Time sync PSAP Scope PSAP (optional) 17 MAC 18 RS 19 Physical PHY 20 21 Medium Medium 22 23 Figure B.4—The RM for IEEE Std 802.3 point-to-multipoint ONU 24 25 26 IEEE Std 802.3ah™-2004 and IEEE Std 802.3av-2009 introduced the concept of subscriber access network. 27 The purpose of Ethernet in the first mile (EFM) and its distinction from traditional Ethernet networks, is that 28 it specifies functionality required for the subscriber access network, i.e., public network access. Network 29 design considerations for public access that may differ from traditional Ethernet LANs include the 30 operations, administration and management (OAM) function, and the regulatory requirements. 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54

1 B.2 IEEE Std 802.11 RM 2 3 The IEEE Std 802.11 11-2012 RM is based on the general station (STA) model, as shown in Figure B.5. 4 5 MSGCF_SAP 6 IEEE Std 802.1X Port IEEE Std 802.1X

7 Filtering (Optional) MAC State Generic Authenticator 8 Convergence Function /Supplicant 9 MAC_SAP 10 MAC Sublayer MSGCF_SME_SAP 11 Management 12 RSNA Key Entity MLME_SAP 13 Data Link MAC Sublayer Management 14 Layer 15 MLME- PHY_SAP PLME_SAP 16 17 Station 18 PLCP Sublayer Management 19 PMD_SAP PHY Layer Physical PLME_SAP Entity 20 Layer Management 21 PMD Sublayer Entity 22 23 24 25 Figure B.5—IEEE Std 802.11-2012 STA RM 26 27 The interconnections between IEEE Std 802.11 11-2012 STAs follow two general models. 28 29 Several types of peer-to-peer, direct, pair-wise communication between STAs are definedprovided, each 30 applicable in differing use scenarios. In these direct communications, the pair STAs are symmetrical, with 31 each STA generally matching the simple STA model, although they may take on different behavioral roles 32 for the purpose of establishing and maintaining the interconnection link. 33 34 The other interconnection model model, the infrastructure model, supports multiple STAs, collected into 35 one or more wireless access domains. These access domains are interconnected via the distribution system, 36 and can interwork with other IEEE 802 networks via one or more portals. 37 38 Each access domain in the infrastructure model is established by an access point (AP), which extends the 39 basic STA model to include repeating and bridging forwarding functions that allow communications 40 between non-AP STAs that do not directly interconnect. The AP acts as a repeater to enable 41 communications between non-AP STAs within the access domaindomain (intra-BSS relay). The AP acts as 42 performs a bridgeforwarding function, via the distribution systemDistribution System, to enable 43 communications between non-AP STAs in different IEEE Std 802.11 wireless access domainsdomains 44 (inter-BSS relay). Finally, via portalsPortals, APs support communications between IEEE Std 802.11 STAs 45 and stations attached to other IEEE 802 networks. 46 47 48 49 50 51 52 53 54

1 Figure B.6 illustrates the Reference Model for an AP, and its relationship to the distribution system and 2 portals. 3 4 5 IEEE Std 802.1X MSGCF_SAP 6 IEEE Std 802.1X 7 port filtering MAC State Generic (optional) Authenticator 8 Convergence Function MAC_SAP /Supplicant 9

10 MSGCF_SME_SAP 11 portal 12 MAC Sublayer RSNA Key

13 Distribution Management Management 14 System Entity 15 IEEE Std 16 MLME_SAP 802.1X Filter 17 Station 18 Data Link Management 19 Layer MAC sublayer Entity 20 MLME- 21 PHY_SAP PLME_SAP 22 23 PLCP sublayer 24 PMD_SAP PHY Layer 25 Physical PLME_SAP Layer Management 26 Entity 27 PMD Sublayer 28 29 30 31 RX TX 32 Example data flows 33 Figure B.6—IEEE Std 802.11 AP RM 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54

1 Figure B.6 illustrates the infrastructure model for APs, The Distribution System and Portals. The arrows 2 indicate the intra-BSS and inter-BSS relay functions for MSDUs as well as interconnection to other 802 3 networks. 4 5 Integration 6 7 8 PortPort al al

9 Other 802 10 network 11 Distribution System 12 13 14 802.1XPort 802.1X Port 15 Filtering (Optional) Filtering (Optional) 16 17 18 Data Link MAC Sublayer MAC Sublayer 19 Layer 20 21 Physical 22 PHY PHY Layer 23 24 25 26 APs 27 28 29 Non-AP 30 STA 31 Non-AP 32 STA Non-AP 33 STA 34 35 Figure B.7—IEEE Std 802.11 infrastructure model 36 37

38 B.3 IEEE 802.15 RMs 39 40 41 B.3.1 IEEE Std 802.15.3™ RM 42 43 44 45 46 47 48 49 50 51 52 53 54

1 The RM for IEEE Std 802.15.3 is illustrated in Figure B.7. 2 3 4 Frame convergence sublayer 5 P (FCSL) A 6 and L Device management entity (DME) 7

8 MAC SAP MLME SAP 9 10 M 11 802.15.3 A Media access control MLME 12 C sublayer (MAC) 13

14 PHY SAP PLME SAP 15 16 17 P H PHY layer PLME 18 Y 19 20 21 22 Figure B.8—IEEE Std 802.15.3 RM 23 24 Frame convergence sublayer (FCSL) and 25 Device management entity (DME) 26 PAL 27

28 MAC SAP MLME SAP 29 30 MAC Medium acces control 31 (MAC) sublayer MLME 32 33 PHY SAP PLME SAP 34 35 PHY PHY layer PLME 36 37 38 39 Figure B.9—IEEE Std 802.15.3 RM 40

41 The PHY SAP and physical layer management entity (PLME) SAP are not defined specified in IEEE Std

42 802.15.3 as they are rarely, if ever, exposed in a typical implementation. The PHY management objects and

43 attributes are accessed through the MAC sublayer management entity (MLME) SAP with the generic

44 management primitives used to access the MAC management objects and attributes. 45

46 The MAC SAP and MLME SAP are defined specified as logical interfaces to access the services provided

47 by IEEE Std 802.15.3 end stations. 48

49 The PLME and MLME are logical entities that control the PHY and MAC, respectively, based on request

50 from the higher layers. 51 52 53 54

1 The frame convergence sublayer (FCSL) is used to allow multiple protocols to simultaneously access the 2 services of an IEEE Std 802.15.3 PAN. IEEE Std 802.15.3 defines specifies an FCSL for connection to the 3 ISO/IEC 8802-2 LLC. 4 5 B.3.2 IEEE Std 802.15.4 RM 6 7 The RM for IEEE Std 802.15.4 is illustrated in Figure B.8. 8

9 Upper layers 10 11 12 MCPS SAP MLME SAP 13 MAC 14 15 PLME SAP 16 PD SAP 17 PHY 18 19 Physical medium 20 21 Figure B.10—IEEE Std 802.15.4 RM 22

23 The upper layers shown in Figure B.8 consist of a network layer, which provides network configuration,

24 manipulation, and message routing, and an application layer, which provides the intended function of the

25 device. The upper layers are not defined specified in IEEE Std 802.15.4. 26 27 28 B.3.3 IEEE Std 802.15.6™ RM 29 30 The RM for IEEE Std 802.15.6 hub or node are shown in Figure B.9. 31 32 MAC-SAP 33 34 MAC sublayer Node or hub 35 PHY-SAP management 36 entity 37 PHY layer 38 39 40 Figure B.11—IEEE Std 802.15.6 RM 41 42 43 B.3.4 IEEE Std 802.15.7™ RM 44 45 46 47 48 49 50 51 52 53 54

1 The RM for IEEE Std 802.15.7 is shown in Figure B.10. 2

3 MCPS-SAP MLME-SAP 4 5 MAC common MLME 6 part sublayer MAC PIB 7 8 PD-SAP PLME-SAP 9 PLME 10 11 PHY layer PHY PIB 12

13 OPTICAL-SAP 14

15 Figure B.12—IEEE Std 802.15.7 RM 16 17 18 The MAC sublayer provides the following two services, accessed through two SAPs: 19 20 a) The MAC data service, accessed through the MAC common part sublayer (MCPS) data SAP 21 (MCPS-SAP), and 22 b) The MAC management service, accessed through the MLME-SAP. 23 24 In addition to these external interfaces, an implicit interface also exists between the MLME and the MAC 25 common part sublayer that allows the MLME to use the MAC data service. 26 27 The PHY provides two services, accessed through two SAPs: the PHY data service, accessed through the 28 PHY data SAP (PD-SAP), and the PHY management service, accessed through the PLME’s SAP (PLME- 29 SAP). The optical SAP (OPTICAL-SAP) provides an interface between the PHY layer and the optical 30 channel and is not specified in the standard. 31 32 33 B.4 IEEE Std 802.16 RM 34 35 36 B.4.1 Protocol RM 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54

1 Figure B.11 illustrates the protocol RM for IEEE Std 802.16. 2 3 6FRSHRIVWDQGDUG 4 HQWLW\ 5 &66$3 6 7 6HUYLFHVSHFLILF 8 FRQYHUJHQFHVXEOD\HU 9 &6 10

0$&6$3 06$3 11 0$&

12 0$&FRPPRQSDUW 13 VXEOD\HU 0$&&36 14 15 6HFXULW\VXEOD\HU 16 17 3+<6$3 0DQDJHPHQW 18 LQIRUPDWLRQ EDVH 0,% 19 3+

35 MAC_SAP management part 36 Distributed coexistence

MAC commom M_SAP 37 MAC information database 38 part sublayer (MAC CPS) Distributed radio 39 resource management 40 Security sublayer 41 Coexistence protocol PHY_SAP 42 (CXP) 43 C_SAP 44 Management PHY PHY layer 45 (PHY) information base (MIB) Network control and management system and management control Network 46 47 48 Data plane Management/control plane 49 Figure B.14—IEEE Std 802.16 protocol RM 50 51 52 The service-specific convergence sublayer (CS) provides any transformation or mapping of external 53 network data, received through the CS service access point (SAP), into MAC service data units (SDUs) 54 received by the MAC common part sublayer (CPS) through the MAC SAP. This includes classifying

1 external network SDUs and associating them to the proper MAC service flow identifier and connection 2 identifier. Multiple CS specifications are provided for interfacing with various protocols. 3 4 The MAC CPS provides the core MAC functionality of system access, bandwidth allocation, connection 5 establishment, and connection maintenance. Quality of service (QoS) is applied to the transmission and 6 scheduling of data over the PHY. 7 8 The security sublayer in the MAC provides authentication, secure key exchange, and encryption. 9 10 Data, PHY control, and statistics are transferred between the MAC CPS and the PHY via the PHY SAP 11 (which is implementation specific). 12 13 The PHY definition includes multiple specifications, each appropriate to a particular frequency range and 14 application. 15 16 B.4.2 Network reference model 17 18 Figure B.12 describes a simplified network RM for IEEE Std 802.16. 19 20 21 Network control and Network control and 22 management system (NCMS) management system (NCMS) 23 (SS/MS side) (BS side) 24

25 M-SAP C-SAP C-SAP M-SAP 26 27 28 IEEE Std 802.16 entity (SS/MS) IEEE Std 802.16 entity (BS) 29 U 30 31 32 Figure B.15—IEEE Std 802.16 network RM 33 34 The network control and management system (NCMS) abstraction allows the PHY/MAC layers specified in 35 IEEE Std 802.16 to be independent of the network architecture, the transport network, and the protocols 36 used at the backend and therefore allows greater flexibility. 37 38 NCMS logically exists at base station (BS) side and subscriber station/mobile subscriber station (SS/MS) 39 side of the radio interface, termed NCMS(BS) and NCMS(SS/MS), respectively. Any necessary inter-BS 40 coordination is handled through the NCMS(BS). 41 42 The control SAP (C-SAP) and management SAP (M-SAP) exposes the control plane and management plane 43 functions to upper layers. The NCMS uses the C-SAP and M-SAP to interface with the IEEE Std 802.16 44 entity. In order to provide correct MAC operation, NCMS is present within each SS/MS. The NCMS is a 45 layer independent entity that may be viewed as a management entity or control entity. General system 46 management entities can perform functions through NCMS and standard management protocols can be 47 implemented in the NCMS. 48 49 An IEEE Std 802.16 entity is defined as the logical entity in an SS/MS or BS that comprises the PHY and 50 MAC layers of the data plane and the management/control plane. The IEEE Std 802.16 end stations can 51 include SS, MS, or BS. Multiple SS or MS may be attached to a BS. 52 53 SS or MS communicate to the BS over the U interface using a primary management connection, a basic 54 connection, or a secondary management connection.

1 B.5 IEEE Std 802.21 RM 2 3 Figure B.13 shows an implementation view of a dual-mode IEEE Std 802.11/IEEE Std 802.16 station with 4 IEEE Std 802.21 MIH functionality. The MIHF provides the required services to perform handovers 5 between IEEE Std 802.11 and IEEE Std 802.16 access technologies. Also, the MIHF becomes a higher layer 6 when it requires data transport services to communicate with an IEEE Std 802.21 MIH peer. In the case of 7 layer 2 transport of MIH data, services are provided by the IEEE Std 802.16 CS_SAP, or the IEEE Std 8 802.11 LSAP. In case of layer 3 transport, services are provided as described in RFC 5677 [B6]. 9 10 MIH User 11 12 Higher Layers 13 MIH_SAP 14 15 CS_SAP LSAP MSGCF_SAP 16 Service specific convergence sublayer MIHF LLC MAC state generic convergence function 17 MAC_SAP

18 MAC common part C_SAP MAC_SAP MSGCF_SME_SAP sublayer 19 Management MAC MLME MLME_SAP 20 Security sublayer entity 21 PHY_SAP PHY_SAP MLME_PLME_SAP SME

22 PLCP PHY M_SAP PLME PLME_SAP 23 and PMD 24 25 IEEE 802.16 IEEE 802.21 IEEE 802.11 26 27 Figure B.16—Example of dual-mode IEEE Std 802.11 and IEEE Std 802.16 end 28 station with IEEE Std 802.21 end-station RM 29 30 31 32 B.6 IEEE Std 802.22 RM 33 34 The RM of IEEE Std 802.22 is depicted in Figure B.14. A unique characteristic of this architecture is its 35 cognitive components which is used to allow for dynamic frequency selection, and avoid interference to 36 incumbents on a real-time basis. 37

38 B.6.1 Data plane 39 40 The service-specific convergence sublayer (CS) provides the transformation or mapping of external network 41 data that is received through the CS SAP, into MAC SDUs and data that is received by the MAC CPS 42 through the MAC SAP. Multiple CS specifications are provided for interfacing with various protocols. 43 44 The MAC CPS provides the core MAC functionality of system access, connection establishment, and 45 connection maintenance. The data that the MAC layer receives from the various CSs through the MAC SAP 46 is classified according to the particular MAC connections. 47 48 The security sublayer 1 provides mechanisms for authentication, secure key exchange, encryption, etc. 49 50 Data, PHY control, and radio statistics are transferred between the MAC CPS and the PHY via the PHY 51 SAP. 52 53 54 B.6.2 Management/control plane

1 CS convergence sublayer SM-GL SAP:spectrum manager, geolocation 2 PHY SAPPHY service access point service access point 3 MAC SAPMAC sublayer service access point NCMS: network control and management system 4 CS SAP convergence sublayer service AAA authentication, authorization 5 access point and accounting 6 SM-SSF SAP:spectrum manager, spectrum M-SAP management service access point 7 sensing function service access point C-SAP control service access point 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 Figure B.17—IEEE Std 802.22 RM for the BS and CPE 34 35 The management/control plane contains the management information base (MIB). SNMP is used to 36 communicate with the MIB database and some of its primitives can be used to manage the network entities, 37 38 e.g., base station (BS), customer-premises equipment (CPE), bridges, routers. The MIB at the CPE is a 39 subset of MIB at the BS. 40 41 42 B.6.3 Cognitive plane 43

44 The SM maintains spectrum availability information, manages channel lists, manages quiet periods 45 scheduling, implements self-coexistence mechanisms and processes requests from the MAC/PHY. The SM 46 is the central point at the BS where all the information on the spectrum availability resulting from the 47 48 database service and the SSF is gathered. Based on this combined information, local regulations, and 49 predefined SM policies, the SM provides the necessary configuration information to the BS MAC, which 50 then remotely configures all the registered CPEs. Connection B2 is used for configuration of the SM at the 51 BS, transmission of the available TV channel list to the SM, as well as to report the RF environment 52 information via the MIB objects. Connection B1 is used by the SM to initiate a channel move, to configure 53 the SSA at the CPE (e.g., backup/candidate channel list, etc.) as well as to gather information from the CPEs 54 (e.g., local sensing information, local geolocation information, etc.).

1 AAA authentication, authorization and MAC SAP MAC sublayer service 2 accounting access point 3 CS convergence sublayer PHY SAP PHY service access point 4 C-SAP control service access point SM-SSF SAP spectrum manager, spectrum 5 CS SAP convergence sublayer service access sensing function service access 6 point point 7 M-SAP management service access point SM-GL SAP spectrum manager, geolocation 8 NCMS network control and management system service access point 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41

42 Figure B.18—IEEE Std 802.22 RM for the BS and CPE 43 44 The spectrum sensing automaton (SSA), is present at the BS and at the CPEs and independently implements 45 specific procedures for sensing the RF environment at initialization of the BS and before the registration of a 46 CPE with the BS. The SSA at the CPE also includes features to allow proper operation when the CPE is not 47 under the control of a BS. At any other time, the SSA at the CPE is under the control of the SM. The SSA at 48 the BS is also active when the BS is not transmitting to conduct out-of-band sensing. The SSA located at the 49 BS can also carry out sensing to clear channels when the base station is not transmitting. 50 51 The spectrum sensing function (SSF) implements spectrum sensing algorithms while the geolocation (GL) 52 module provides the information to determine the location of the IEEE Std 802.22 end station (BS or CPE). 53 54

1 The role of the security sublayer 2 is to provide enhanced protection to the incumbents as well as necessary 2 protection to the IEEE Std 802.22 stations. 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54

1 Annex C 2

3 (informative) 4 5 6 Examples of bit ordering for addresses 7 8 9 10 C.1 General 11 12 This Annex illustrates the various bit- and octet-transmission scenarios that can occur, and it is intended as a 13 basis for clarifying the issue of bit-ordering for EUI-48s across different MACs. Throughout, the examples 14 make use of the OUI value AC-DE-48, introduced in 8.4.1. This three-octet value is considered in its two 15 possible roles: as the first part of a five-octet protocol identifier, and as the first part of a six-octet EUI-48. 16 The consistent representations of the OUI in its role as part of a protocol identifier are contrasted with the 17 sometimes variable representations that apply to its role as part of an EUI-48. 18 19 NOTE—Protocol identifiers always form part of the normal user data in a MAC Information field; hence, there is 20 nothing special about OUI octets in their protocol identifier role. 21 22 23 C.2 Illustrative examples 24 25 For the examples, the bit significance of an OUI in general is defined to be as illustrated in Figure C.1. 26 27 MSB LSB 28 Octet 0 h g f e d c b a 29 Octet 1 p o n m l k j i 30 Octet 2 x w v u t s r q 31 When used in an EUI-48: Bit “a” of the OUI = I/G address bit. Bit “b” of the OUI = U/L address bit. 32 33 When used in a protocol identifiers: 34 Bit “a” of the OUI = M bit. Bit “b” of the OUI (always zero) = X bit. 35 Figure C.1—Bit significance of an OUI 36 37 38 When transmitted on a network with all data octets of the OUI transmitted LSB first, the OUI portions of a 39 protocol identifier and of an EUI-48 appear as in Figure C.2. When transmitted on a network with the data 40 octets of the OUI transmitted MSB first, the OUI portions of a protocol identifier, and of an EUI-48 41 contained in a MAC Address field, appear as in Figure C.3. 42 43 In some circumstances, it is necessary to convey EUI-48s as data within MAC Information fields, e.g., as 44 part of a management protocol or a network layer routing protocol. 45 46 For network types in which Figure C.2 applies, such as IEEE Std 802.3, the bit-ordering within the octets of 47 an EUI-48 conveyed as data is the same as both the ordering when the address appears in a MAC Address 48 field and the ordering for octets of nonaddress information. 49 50 For network types in which Figure C.3 applies there appears to be a choice of representations for EUI-48s 51 conveyed as data, as follows: 52 53 — Canonical format: The octets of the EUI-48 can be treated like any other data octets and transmitted 54 with the bit-ordering of Figure C.3(a). The canonical format is illustrated in Figure C.4.

1 2 General OUI OUI = AC-DE-48

3 abcdefgh ijklmnop qrstuvwx 00110101 01111011 00010010 4 time time 5 AC DE 48 6 time 7 8 a) OUI within a protocol identifier (in a MAC Information field, as normal data) 9 OUI within a MAC Address field 10 OUI = AC-DE-48 11 abcdefgh ijklmnop qrstuvwx 00110101 01111011 00010010 12 time time 13 AC DE 48 14 time 15 b) OUI within a MAC Address field 16 17 Figure C.2—Order of bit and octet transmission for an OUI with LSB transmitted first 18 19 20 General OUI OUI = AC-DE-48 21 hgfedcba ponmlkji xwvutsrq 10101100 11011110 01001000 22 time time

23 AC DE 48

24 time 25 a) OUI within a protocol identifier (in a MAC Information field, as normal data) 26 27 OUI within a MAC Address field OUI = AC-DE-48 28 29 abcdefgh ijklmnop qrstuvwx 00110101 01111011 00010010 time time 30 31 AC DE 48 32 time

33 b) OUI within a MAC Address field 34 35 Figure C.3—Order of bit and octet transmission for an OUI with MSB transmitted first 36 37 General OUI 38 OUI = AC-DE-48 39 hgfedcba ponmlkji xwvutsrq 00110101 01111011 00010010 40 time time 41 AC DE 48 42 time 43 44 Figure C.4—Order of bit and octet transmission for an OUI in an EUI-48 with 45 MSB transmitted first, canonical format.

46 — Noncanonical format: The bit-ordering of Figure C.3(b) is treated as a property of the EUI-48 rather 47 than of the MAC Address field as transmitted in MAC frames, and the EUI-48 octets are transmitted 48 with the bit-ordering reversed compared with normal data octets. The noncanonical format is illus- 49 trated in Figure C.5. 50 51 52 The noncanonical format has the unfortunate consequence that applications operating in environments 53 containing a mixture of LAN types have to handle different representations of EUI-48s, according to the 54 environment in which the EUI-48 is to be used.

1 2 General OUI OUI = AC-DE-48 3 4 abcdefgh ijklmnop qrstuvwx 00110101 01111011 00010010 time time 5 6 35 7B 12 7 time 8 9 Figure C.5—Order of bit and octet transmission for an OUI in an EUI-48 10 with MSB transmitted first, noncanonical format. 11 12 In Figure C.2, Figure C.3, Figure C.4, and Figure C.5, it can be seen that the interpretation of OUI bits as 13 octet values is consistent. This reversal of the bit order applies only to all six octets (not just the OUI) of an 14 EUI-48 placed in the MAC Information field of a frame by a protocol that uses the bit-reversed view of the 15 EUI-48s derived from Figure C.3(b). Frames containing, or possibly containing, such EUI-48s are described 16 as having noncanonical format. Frames that cannot contain such EUI-48s are described as having canonical 17 format. 18 19 Note that there is no way of knowing, from MAC layer information only, whether a particular frame is in 20 canonical or noncanonical format. In general, this depends on which higher layer protocols are present in the 21 frame. 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54

1 Annex D 2 3 4 (informative) 5 6 7 List of IEEE 802 standards 8 9 This annex contains a list of approved IEEE 802 standards that was current when this standards was 10 completed. 11 12 IEEE Std 802.1AB™, IEEE Standard for Local and Metropolitan Area Networks—Station and Medium 13 Access Control Connectivity Discovery.20 14 15 IEEE Std 802.1AC™, IEEE Standard for Local and Metropolitan Area Networks—Media Access Control 16 (MAC) Service definition. 17

18 IEEE Std 802.1AE™, IEEE Standard for Local and Metropolitan Area Networks: Media Access Control

19 (MAC) Security. 20 21 IEEE Std 802.1AR™, IEEE Standard for Local and Metropolitan Area Networks—Secure Device Identity. 22 23 24 IEEE Std 802.1AS™, IEEE Standard for Local and Metropolitan Area Networks—Timing and Synchroni- 25 zation for Time-Sensitive Applications in Bridged Local Area Networks. 26 27 IEEE Std 802.1AX™, IEEE Standard for Local and Metropolitan Area Networks—Link Aggregation. 28 29 IEEE Std 802.1BA™, IEEE Standard for Local and Metropolitan Area Networks—Audio Video Bridging 30 (AVB) Systems. 31 32 IEEE Std 802.1BR™, IEEE Standard for Local and Metropolitan Area Networks—Virtual Bridged Local 33 Area Networks – Bridge Port Extension 34

35 IEEE Std 802.1D™, IEEE Standard for Local and Metropolitan Area Networks: Media Access Control

36 (MAC) Bridges. 37 38 IEEE Std 802.1Q™, IEEE Standard for Local and Metropolitan Area Networks—Media Access Control 39 (MAC) Bridges and Virtual Bridged Local Area Networks. 40 41 42 IEEE Std 802.1X™, IEEE Standard for Local and Metropolitan Area Networks—Port-Based Network 43 Access Control. 44 45 IEEE Std 802.3™, IEEE Standard for Ethernet. 46 47 IEEE Std 802.3.1™, IEEE Standard for Management Information Base (MIB) Definitions for Ethernet 48

49 IEEE Std 802.11™, IEEE Standard for Information technology—Telecommunications and Information

50 Exchange Between Systems—Local and Metropolitan Area Networks—Specific Requirements—Part 11:

51 Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Specifications. 52

53 20The IEEE standards and products referred to in Annex D are trademarks owned by the Institute of Electrical and Electronics 54 Engineers, Incorporated.

1 IEEE Std 802.15.1™, IEEE Standard for Information technology—Telecommunications and information 2 exchange between systems—Local and Metropolitan Area Networks—Specific requirements—Part 15.1: 3 Wireless LAN medium access control (MAC) and physical layer (PHY) specifications for wireless personal 4 area networks (WPANs). 5 6 IEEE Std 802.15.2™, IEEE Recommended Practice for Information technology—Telecommunications and 7 Information Exchange Between Systems—Local and Metropolitan Area Networks—Specific Require- 8 ments—Part 15.2: Coexistence of Wireless Personal Area Networks with Other Wireless Devices Operating 9 in Unlicensed Frequency Bands. 10 11 IEEE Std 802.15.3™, IEEE Standard for Information technology—Telecommunications and Information 12 Exchange Between Systems—Local and Metropolitan Area Networks—Specific Requirements—Part 15.3: 13 Wireless Medium Access Control (MAC) and Physical Layer (PHY) Specifications for High Rate Wireless 14 Personal Area Networks (WPANs). 15 16 IEEE Std 802.15.4™, IEEE Standard for Local and Metropolitan Area Networks—Part 15.4: Low-Rate 17 Wireless Personal Area Networks (LR-WPANs). 18 19 IEEE Std 802.15.5™, IEEE Recommended Practice for Information technology—Telecommunications and 20 information exchange between systems—Local and metropolitan area networks—Specific requirements— 21 Part 15.5: Mesh Topology Capability in Wireless Personal Area Networks (WPANs). 22 23 IEEE Std 802.15.7™, IEEE Standard for Local and Metropolitan Area Networks—Part 15.7: Short-Range 24 Wireless Optical Communication Using Visible Light. 25 26 IEEE Std 802.16™, IEEE Standard for Air Interface for Broadband Wireless Access Systems. 27 28 IEEE Std 802.16.1™, IEEE Standard for WirelessMAN-Advanced Air Interface for Broadband Wireless 29 Access Systems. 30 31 IEEE Std 802.16.2™, IEEE Recommended Practice for Local and Metropolitan Area Networks -Coexist- 32 ence of Fixed Broadband Wireless Access Systems. 33 34 IEEE Std 802.17™, IEEE Standard for Information technology—Telecommunications and information 35 exchange between systems—Local and Metropolitan Area Networks—Specific requirements—Part 17: 36 Resilient packet ring (RPR) access method and physical layer. 37 38 IEEE Std 802.20™, IEEE Standard for Local and Metropolitan Area Networks—Part 20: Air Interface for 39 Mobile Broadband Wireless Access Systems Supporting Vehicular Mobility—Physical and Media Access 40 Control Layer Specification. 41 42 IEEE Std 802.20.2™, IEEE Standard for Conformance to IEEE 802.20 Systems—Protocol Implementation 43 Conformance Statement (PICS) Proforma. 44 45 IEEE Std 802.20.3™, IEEE Standard for Minimum Performance Characteristics of IEEE 802.20 Terminals 46 and Base Stations/Access Nodes 47 48 IEEE Std 802.21™, IEEE Standard for Local and Metropolitan Area Networks—Media Independent Han- 49 dover Services. 50 51 IEEE Std 802.22™, IEEE Standard for Information Technology—Telecommunications and information 52 exchange between systems Wireless Regional Area Networks (WRAN)—Specific requirements Part 22: 53 Cognitive Wireless RAN Medium Access Control (MAC) and Physical Layer (PHY) Specifications: Poli- 54 cies and Procedures for Operation in the TV Bands

1 IEEE Std 802.22.1™, IEEE Standard for Information Technology—Telecommunications and information 2 exchange between systems—Local and Metropolitan Area Networks—Specific requirements Part 22.1: 3 Standard to Enhance Harmful Interference Protection for Low-Power Licensed Devices Operating in TV 4 Broadcast Bands 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54