Media Access Control (MAC) Service: IEEE Standard For Local and Metropolitan Area Networks

IEEE Standard for
Local and metropolitan area networks—
Media Access Control (MAC) Service

Definition
IEEE Computer Society
Sponsored by the
LAN/MAN Standards Committee
IEEE
3 Park Avenue IEEE Std 802.1AC™-2012
New York, NY 10016-5997
USA
14 September 2012
IEEE Std 802.1AC™-2012
IEEE Standard for


Definition
Sponsor
LAN/MAN Standards Committee
of the
IEEE Computer Society
Approved 30 August 2012

IEEE-SA Standards Board
Abstract: The MAC service provided by all IEEE 802® MACs along with the Internal Sublayer
Service (ISS) that is provided by IEEE 802 MACs to the relay function of a Media Access Control
(MAC) Bridge are defined in this standard.
Keywords: IEEE 802, IEEE 802.1AC, Internal Sublayer Service, ISS, local area networks, MAC
Service, metropolitan area networks
The Institute of Electrical and Electronics Engineers, Inc.

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

All rights reserved. Published 14 September 2012. Printed in the United States of America.
IEEE and 802 are registered trademarks in the U.S. Patent & Trademark Office, owned by The Institute of Electrical and
Electronics Engineers, Incorporated.
Print: ISBN 978-0-7381-7304-7 STD97279

PDF: ISBN 978-0-7381-7356-6 STDPD97279
IEEE prohibits discrimination, harassment and bullying. For more information, visit http://www.ieee.org/web/aboutus/whatis/policies/p9-26.html.
No part of this publication may be reproduced in any form, in an electronic retrieval system or otherwise, without the prior written permission of the
publisher.
Notice and Disclaimer of Liability Concerning the Use of IEEE Documents: IEEE Standards documents are developed
within the IEEE Societies and the Standards Coordinating Committees of the IEEE Standards Association (IEEE-SA)
Standards Board. IEEE develops its standards through a consensus development process, approved by the American National
Standards Institute, which brings together volunteers representing varied viewpoints and interests to achieve the final product.
Volunteers are not necessarily members of the Institute and serve without compensation. While IEEE administers the process
and establishes rules to promote fairness in the consensus development process, IEEE does not independently evaluate, test, or
verify the accuracy of any of the information or the soundness of any judgments contained in its standards.
Use of an IEEE Standard is wholly voluntary. IEEE disclaims liability for any personal injury, property or other damage, of any
nature whatsoever, whether special, indirect, consequential, or compensatory, directly or indirectly resulting from the
publication, use of, or reliance upon any IEEE Standard document.
IEEE does not warrant or represent the accuracy or content of the material contained in its standards, and expressly disclaims
any express or implied warranty, including any implied warranty of merchantability or fitness for a specific purpose, or that the
use of the material contained in its standards is free from patent infringement. IEEE Standards documents are supplied “AS IS.”
The existence of an IEEE Standard does not imply that there are no other ways to produce, test, measure, purchase, market, or
provide other goods and services related to the scope of the IEEE standard. Furthermore, the viewpoint expressed at the time a
standard is approved and issued is subject to change brought about through developments in the state of the art and comments
received from users of the standard. Every IEEE standard is subjected to review at least every ten years. When a document is
more than ten years old and has not undergone a revision process, it is reasonable to conclude that its contents, although still of
some value, do not wholly reflect the present state of the art. Users are cautioned to check to determine that they have the latest
edition of any IEEE standard.
In publishing and making its standards available, IEEE is not suggesting or rendering professional or other services for, or on
behalf of, any person or entity. Nor is IEEE undertaking to perform any duty owed by any other person or entity to another. Any
person utilizing any IEEE Standards document, should rely upon his or her own independent judgment in the exercise of
reasonable care in any given circumstances or, as appropriate, seek the advice of a competent professional in determining the
appropriateness of a given IEEE standard.
Translations: The IEEE consensus development process involves the review of documents in English only. In the event that an
IEEE standard is translated, only the English version published by IEEE should be considered the approved IEEE standard.
Official Statements: A statement, written or oral, that is not processed in accordance with the IEEE-SA Standards Board
Operations Manual shall not be considered the official position of IEEE or any of its committees and shall not be considered to
be, nor be relied upon as, a formal position of IEEE. At lectures, symposia, seminars, or educational courses, an individual
presenting information on IEEE standards shall make it clear that his or her views should be considered the personal views of
that individual rather than the formal position of IEEE.
Comments on Standards: Comments for revision of IEEE Standards documents are welcome from any interested party,
regardless of membership affiliation with IEEE. However, IEEE does not provide consulting information or advice pertaining
to IEEE Standards documents. Suggestions for changes in documents should be in the form of a proposed change of text,
together with appropriate supporting comments. Since IEEE standards represent a consensus of concerned interests, it is
important to ensure that any responses to comments and questions also receive the concurrence of a balance of interests. For
this reason, IEEE and the members of its societies and Standards Coordinating Committees are not able to provide an instant
response to comments or questions except in those cases where the matter has previously been addressed. Any person who
would like to participate in evaluating comments or revisions to an IEEE standard is welcome to join the relevant IEEE working
group at http://standards.ieee.org/develop/wg/.
Comments on standards should be submitted to the following address:
Secretary, IEEE-SA Standards Board

445 Hoes Lane
Piscataway, NJ 08854
USA
Photocopies: Authorization to photocopy portions of any individual standard for internal or personal use is granted by The
Institute of Electrical and Electronics Engineers, Inc., provided that the appropriate fee is paid to Copyright Clearance Center.
To arrange for payment of licensing fee, please contact Copyright Clearance Center, Customer Service, 222 Rosewood Drive,
Danvers, MA 01923 USA; +1 978 750 8400. Permission to photocopy portions of any individual standard for educational
classroom use can also be obtained through the Copyright Clearance Center.
Notice to users
Laws and regulations
Users of IEEE Standards documents should consult all applicable laws and regulations. Compliance with the
provisions of any IEEE Standards document does not imply compliance to any applicable regulatory
requirements. Implementers of the standard are responsible for observing or referring to the applicable
regulatory requirements. IEEE does not, by the publication of its standards, intend to urge action that is not
in compliance with applicable laws, and these documents may not be construed as doing so.
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 documents should be aware that these documents may be superseded at any time
by the issuance of new editions or may be amended from time to time through the issuance of amendments,
corrigenda, or errata. An official IEEE document at any point in time consists of the current edition of the
document together with any amendments, corrigenda, or errata then in effect. 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-SA Website at http://standards.ieee.org/index.html or
contact the IEEE at the address listed previously. For more information about the IEEE Standards
Association or the IEEE standards development process, visit IEEE-SA Website at http://standards.ieee.org/
index.html.
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.
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 at 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
under reasonable rates, with reasonable terms and conditions that are demonstrably free of any unfair
discrimination to applicants desiring to obtain such licenses.
iv Copyright © 2012 IEEE. All rights reserved.

Essential Patent Claims may exist for which a Letter of Assurance has not been received. The IEEE is not
responsible for identifying Essential Patent Claims for which a license may be required, for conducting
inquiries into the legal validity or scope of Patents Claims, or determining whether any licensing terms or
conditions provided in connection with submission of a Letter of Assurance, if any, or in any licensing
agreements are reasonable or non-discriminatory. Users of this standard are expressly advised that
determination of the validity of any patent rights, and the risk of infringement of such rights, is entirely their
own responsibility. Further information may be obtained from the IEEE Standards Association.
Copyright © 2012 IEEE. All rights reserved. v

Participants
The following is a list of participants in the Interworking activities of the IEEE 802.1™ Working Group
during the development of IEEE Std 802.1AC. Voting members at the time of publication are marked with
an asterisk (*):
Tony Jeffree, Chair

Glenn Parsons, Vice Chair
Stephen Haddock, Chair, Interworking Task Group
John Messenger, Editor
Zehavit Alon Franz Goetz Glenn Parsons
Yafan An Mark Gravel Donald Pannell
Ting Ao Eric Gray Mark Pearson
Peter Ashwood-Smith Yingjie Gu Joseph Pelissier
Christian Boiger Craig Gunther Rene Raeber
Brad Booth Stephen Haddock Karen Randall
Paul Bottorff Hitoshi Hayakawa Josef Roese
Rudolf Brandner Tony Jeffree Dan Romascanu
Craig Carlson Markus Jochim Jessy Rouyer
Xin Chang Girault Jones Ali Sajassi
Weiying Cheng Daya Kamath Panagiotis Saltsidis
Paul Congdon Hal Keen Michael Seaman
Diego Crupnicoff Srikanth Keesara Koichiro Seto
Rodney Cummings Yongbum Kim Rakesh Sharma
Claudio Desanti Philippe Klein Takeshi Shimizu
Donald Eastlake, 3rd Oliver Kleineberg Kevin Stanton
Janos Farkas Jeff Lynch Michael Johas Teener
Donald Fedyk Thomas Mack-Crane Patricia Thaler
Norman Finn David Martin Jeremy Touve
Andre Fredette John Messenger Maarten Vissers
Geoffrey Garner John Morris Yuehua Wei
Anoop Ghanwani Eric Multanen Min Xiao
David Olsen
vi Copyright © 2012 IEEE. All rights reserved.

The following members of the individual balloting committee voted on this standard. Balloters may have
voted for approval, disapproval, or abstention.
Thomas Alexander Shinkyo Kaku Herbert Ruck
Mark Anderson Piotr Karocki Randall Safier
Alex Ashley Stuart Kerry Panagiotis Saltsidis
Hugh Barrass Yongbum Kim John Santhoff
Nancy Bravin Bruce Kraemer Peter Saunderson
William Byrd Thomas Kurihara Bartien Sayogo
Keith Chow James Lansford Gil Shultz
Charles Cook Brian L’Ecuyer Kapil Sood
Rodney Cummings William Lumpkins Amjad Soomro
Sourav Dutta Greg Luri Matthew Squire
Richard Edgar Thomas Mack-Crane Manikantan Srinivasan
Michael Fischer Elvis Maculuba Thomas Starai
Yukihiro Fujimoto Wayne Manges Walter Struppler
Devon Gayle Arthur Marris Patrik Sundstrom
Randall C. Groves David Martin Joseph Tardo
Stephen Haddock Jeffery Masters William Taylor
David Hunter John Messenger Patricia Thaler
Noriyuki Ikeuchi Michael Montemurro Solomon Trainin
Paul Isaacs Jose Morales Dmitri Varsanofiev
Akio Iso Michael S. Newman Prabodh Varshney
Atsushi Ito Nick S.A. Nikjoo John Vergis
Raj Jain Satoshi Obara Ludwig Winkel
Junghoon Jee Maximilian Riegel Michael Wright
Tony Jeffree Benjamin Rolfe Oren Yuen
Tal Kaitz Daidi Zhong
Copyright © 2012 IEEE. All rights reserved. vii

When the IEEE-SA Standards Board approved this standard on 30 August 2012, it had the following
membership:
Richard H. Hulett, Chair

John Kulick, Vice Chair
Robert M. Grow, Past Chair
Konstantinos Karachalios, Secretary
Satish Aggarwal Alexander Gelman Oleg Logvinov
Masayuki Ariyoshi Paul Houzé Ted Olsen
Peter Balma Jim Hughes Gary Robinson
William Bartley Young Kyun Kim Jon Walter Rosdahl
Ted Burse Joseph L. Koepfinger* Mike Seavey
Clint Chaplin David J. Law Yatin Trivedi
Wael Diab Thomas Lee Phil Winston
Jean-Philippe Faure Hung Ling Yu Yuan
*Member Emeritus
Also included are the following nonvoting IEEE-SA Standards Board liaisons:
Richard DeBlasio, DOE Representative

Michael Janezic, NIST Representative
Michelle Turner
IEEE Standards Program Manager, Document Development
Kathryn Bennett
IEEE Standards Program Manager, Technical Program Development
viii Copyright © 2012 IEEE. All rights reserved.

Introduction
This introduction is not part of IEEE Std 802.1AC-2012, IEEE Standard for Local and metropolitan area networks—
Media Access Control (MAC) Service Definition.
During the history of IEEE 802, several different MAC types have been developed, all of which have a core
of functionality that is common to IEEE 802 MACs in general, but all of which also provide functionality
that extends beyond that common core. An example can be found in the way priority information is
conveyed in different MACs; some have no means of conveying priority, some can convey two different
priority code points, some can convey eight priority code points.
While such differences are not an issue in a Local Area Network (LAN) that employs a single MAC
technology, they can become an issue in LANs where more than one MAC technology is employed, for
example in Bridged LANs. It was therefore important at an early stage of MAC Bridge development to
develop a clear definition of the MAC service that would facilitate the definition of a common Bridging
technology that could apply to all MAC types.
The MAC service definition was first standardized as ISO/IEC 15802-1:1995 [B8]; when the ISO/IEC
standard reached its 5-year revision point, IEEE 802 was asked to take over the document and revise it to
reflect changes since publication.a This revision emphasizes the fundamental relayable nature of the MAC
service provided to end stations by defining it in terms of the service, common to bridges and end stations,
previously documented as the Internal Sublayer Service (ISS) in IEEE Std 802.1D™.b In addition to the
material that was contained in ISO/IEC 15802-1, this standard documents the ISS that was originally
defined in IEEE Std 802.1D.
This standard contains state-of-the-art material. The area covered by this standard is undergoing evolution.
Revisions are anticipated within the next few years to clarify existing material, to correct possible errors, and
to incorporate new related material. Information on the current revision state of this and other IEEE 802
standards may be obtained from
Secretary, IEEE-SA Standards Board

445 Hoes Lane
Piscataway, NJ 08854
USA
a
The numbers in brackets correspond to those of the bibliography in Annex A.
b
Information on references can be found in Clause 2.
Copyright © 2012 IEEE. All rights reserved. ix

Contents
1. Scope.................................................................................................................................................... 1
2. Normative references ........................................................................................................................... 2
3. Definitions ........................................................................................................................................... 3
3.1 Basic reference model definitions................................................................................................ 3

3.2 Service conventions definitions ................................................................................................... 3
4. Acronyms and abbreviations ............................................................................................................... 4
5. Conformance........................................................................................................................................ 5
6. Conventions ......................................................................................................................................... 6
6.1 General considerations................................................................................................................. 6

6.2 Parameters.................................................................................................................................... 6
7. Basic architectural concepts and terms ................................................................................................ 7
7.1 Protocol entities, peers, layers, services, and clients ................................................................... 7

7.2 Service interface primitives, parameters, and frames .................................................................. 7
7.3 Layer management interfaces ...................................................................................................... 8
7.4 Service access points, interface stacks, and ports ........................................................................ 8
7.5 MAC method independent protocols and shims.......................................................................... 9
7.6 MAC Service clients .................................................................................................................... 9
7.7 Stations and systems .................................................................................................................... 9
7.8 Connectionless connectivity ...................................................................................................... 10
8. Overview of the MAC Service .......................................................................................................... 11
9. Model of the MAC Service................................................................................................................ 12
9.1 Model of a MAC connectionless-mode transmission................................................................ 12

9.2 Service provided by the connectionless-mode MAC Service ................................................... 12
10. Quality of connectionless-mode service ............................................................................................ 13
10.1 Determination of QoS for connectionless-mode service ........................................................... 13

10.2 Definition of connectionless-mode QoS parameters ................................................................. 13
11. Internal Sublayer Service................................................................................................................... 14
11.1 Service primitives and parameters ............................................................................................. 14

11.2 Status parameters ....................................................................................................................... 16
11.3 Point-to-point parameters .......................................................................................................... 16
12. Support of the Internal Sublayer Service ........................................................................................... 18
12.1 Support of the Internal Sublayer Service by specific MAC procedures.................................... 18
Copyright © 2012 IEEE. All rights reserved. xi

13. MAC Service ..................................................................................................................................... 25
13.1 Function ..................................................................................................................................... 25

13.2 Service primitives and parameters ............................................................................................. 25
13.3 Status parameters ....................................................................................................................... 26
13.4 Sequence of primitives............................................................................................................... 26
Annex A (informative) Bibliography ............................................................................................................ 27
xii Copyright © 2012 IEEE. All rights reserved.

Figures
Figure 7-1—MAC entities, the MAC Service, and MAC Service users (clients)........................................... 8
Figure 7-2—An interface stack........................................................................................................................ 9
Figure 9-1—Model for a MAC Service Connectionless-mode Transmission .............................................. 12
Figure 13-1—Sequence of primitives............................................................................................................ 26
Copyright © 2012 IEEE. All rights reserved. xiii

Tables
Table 12-1—Priority to MAC service class mapping ................................................................................... 21
Table 12-2—MAC service class to priority mapping.................................................................................... 22
xiv Copyright © 2012 IEEE. All rights reserved.

IEEE Standard for

Definition
IMPORTANT NOTICE: IEEE Standards documents are not intended to ensure safety, health, or
environmental protection, or ensure against interference with or from other devices or networks.
Implementers of IEEE Standards documents are responsible for determining and complying with all
appropriate safety, security, environmental, health, and interference protection practices and all
applicable laws and regulations.
This IEEE document is made available for use subject to important notices and legal disclaimers. These
notices and disclaimers appear in all publications containing this document and may be found under the
heading “Important Notice” or “Important Notices and Disclaimers Concerning IEEE Documents.”
They can also be obtained on request from IEEE or viewed at http://standards.ieee.org/IPR/
disclaimers.html.
1. Scope
The scope of this standard is to define the Media Access Control (MAC) Service provided by all IEEE 802®
MACs, and the Internal Sublayer Service (ISS) provided within MAC Bridges, in abstract terms of the
following:
a) Their semantics, primitive actions, and events; and

b) The parameters of, interrelationship between, and valid sequences of these actions and events.
Copyright © 2012 IEEE. All rights reserved. 1

IEEE
Std 802.1AC-2012 IEEE STANDARD FOR LOCAL AND METROPOLITAN NETWORKS—
2. Normative references
The following referenced documents are indispensable for the application of this document (i.e., they must
be understood and used, so each referenced document is cited in the text and its relationship to this
document is explained). For dated references, only the edition cited applies. For undated references, the
latest edition of the referenced document (including any amendments or corrigenda) applies.
IEEE Std 802®, IEEE Standard for Local and Metropolitan Area Networks: Overview and Architecture.1, 2
IEEE Std 802.1D™, IEEE Standard for Local and Metropolitan Area Networks—Media Access Control
(MAC) Bridges.
IEEE Std 802.1Q™, IEEE Standard for Local and Metropolitan Area Networks—Media Access Control
(MAC) and Virtual Bridged Local Area Networks.
ISO/IEC 7498-1, Information technology—Open Systems Interconnection—Basic Reference Model: The

Basic Model.3
ISO/IEC 7498-3, Information technology—Open Systems Interconnection—Basic Reference Model:

Naming and addressing.
ISO/IEC 10731, Information technology—Open Systems Interconnection—Basic Reference Model—

Conventions for the definition of OSI services.
1
IEEE publications are available from The Institute of Electrical and Electronics Engineers (http://standards.ieee.org/).
2The IEEE standards or products referred to in this clause are trademarks of The Institute of Electrical and Electronics Engineers, Inc.
3
ISO/IEC publications are available from the ISO Central Secretariat (http://www.iso.org/). ISO publications are also available in the
United States from the American National Standards Institute (http://www.ansi.org/).
2 Copyright © 2012 IEEE. All rights reserved.

IEEE
MEDIA ACCESS CONTROL (MAC) SERVICE DEFINITION Std 802.1AC-2012
3. Definitions
For the purposes of this document, the following terms and definitions apply. The IEEE Standards
Dictionary Online should be consulted for terms not defined in this clause.4
3.1 Basic reference model definitions
Although the MAC Service is not identified or defined in the Open Systems Interconnection (OSI) Basic
Reference Model, this standard is based on the concepts developed in the Basic Reference Model and makes
use of the following terms defined in ISO/IEC 7498-1 and ISO/IEC 7498-3, as they might apply to the MAC
Sublayer:5
a) Entity
b) Sublayer
c) Service
d) Service access point (SAP)
e) Service data unit (SDU)
f) Subnetwork address
3.2 Service conventions definitions
Although the MAC Service is not identified or defined in the OSI Basic Reference Model, this standard
makes use of the following terms defined in ISO/IEC 10731, as they might apply to the MAC Sublayer:
a) Service user
b) Service provider
c) Primitive
d) Request
e) Indication
4IEEE Standards Dictionary Online subscription is available at:

http://www.ieee.org/portal/innovate/products/standard/standards_dictionary.html.
5
Information on references can be found in Clause 2.

IEEE
4. Acronyms and abbreviations
For the purposes of this standard, the following acronyms and abbreviations apply:
ISS Internal Sublayer Service
LAN Local Area Network
LLC Logical Link Control
MAC Media Access Control
MSAP Media Access Control Service access point
MSDU Media Access Control Service data unit
OSI Open Systems Interconnection
QoS Quality of Service
SAP service access point
SDU service data unit

IEEE
5. Conformance
This standard does not specify individual implementation or products, nor does it constrain the
implementation of MAC entities and interfaces within an information processing system.
There is no conformance of equipment to this standard. Instead, conformance is achieved through

implementation of conforming MAC Protocols that fulfil the ISS and MAC Service defined in this standard.

IEEE
6. Conventions
6.1 General considerations
This standard uses the descriptive conventions given in ISO/IEC 10731.
The service model, service primitives, and time-sequence diagrams used are entirely abstract descriptions;
they do not represent a specification for implementation.
6.2 Parameters
Service primitives, used to represent service user/service provider interactions (ISO/IEC 10731), convey
parameters that indicate information available in the user/provider interaction, and have a global
significance.

IEEE
7. Basic architectural concepts and terms
The architectural concepts used in this and other IEEE 802.1™ standards are based on the layered protocol
model introduced by the OSI Reference Model (ISO/IEC 7498-1) and used in the MAC Service Definition
(this standard), in IEEE Std 802, in other IEEE 802 standards, and elsewhere in networking. IEEE 802.1
standards in particular have developed terms and distinctions useful in describing the MAC Service and its
support by protocol entities within the MAC Sublayer.6
7.1 Protocol entities, peers, layers, services, and clients
The fundamental notion of the model is that each protocol entity within a system is instantiated at one of a
number of strictly ordered layers, and communicates with peer entities (operating the same or an
interoperable protocol within the same layer) in other systems by using the service provided by interoperable
protocol entities within the layer immediately below, and thus provides service to protocol entities in the
layer above. The implied repetitive stacking of protocol entities is essentially unbounded at the lowest level
and is bounded at the highest level by an application supported by peer systems. In descriptions of the
model, the relative layer positions of protocol entities and services are conventionally referred to by N,
designating a numeric level. The N-service is provided by an N-entity that uses the (N – 1) service provided
by the (N – 1) entity, while the N-service user is an (N + 1) entity. Figure 7-1 illustrates these concepts with
reference to the MAC Sublayer, which contains MAC entities that provide the MAC Service, to MAC
Service users.
7.2 Service interface primitives, parameters, and frames
Each N-service is described in terms of service primitives and their parameters, each primitive
corresponding to an atomic interaction between the N-service user and the N-service provider, with each
invocation of a primitive by a service user resulting in the service issuing corresponding primitives to peer
service users. The purpose of the model is to provide a framework and requirements for the design of
protocols while not unnecessarily constraining the internal design of systems; primitives and their
parameters are limited to (but include all of) the information elements conveyed to corresponding peer
protocol entities or required by other systems (and not supplied by protocols in lower layers) to identify
(address) those entities and deliver the information. The parameters of service primitives do not include
information that is used only locally, i.e., within the same system, to identify entities or organize resources
for example.7
The primitives of the MAC Service comprise a data request and a corresponding data indication, each with
MAC destination address, MAC source address, a MAC Service Data Unit (MSDU) comprising one or more
octets of data, and priority parameters. Taken together these parameters are conveniently referred to as a
frame, although this does not imply that they are physically encoded by a continuous signal on a
communication medium, that no other fields are added or inserted by other protocol entities prior to
transmission, or that the priority is always encoded with the other parameters transmitted.
6Drawing on prior network layer standards, including ISO/IEC 7498-1, wherever possible.
7
These points are frequently misunderstood by those unfamiliar with the reference model, who take it as simply restating common
sense principles of modular engineering. Early variants of the MAC Service, for example, omitted the source MAC address parameter
on the grounds that it was a fixed property of the transmitting station and should be supplied by the MAC entity itself, despite the fact
that communicating peer service users (and the protocols they operate) required that information. The introduction of MAC Bridges
necessitated the development of a MAC ISS with the required parameter and has led to a restatement of the service definition included
in a number of standards. However the source address parameter would still have been required even if MAC Bridges did not exist.
Similarly, versions of the MAC Service have included local acknowledgment primitives or status return codes for primitives issued.
These play no part in defining the peer-to-peer communication and do not conform to the reference model. The scope of some
IEEE 802 standards does include the definition of interfaces, particularly electrical interfaces, within systems. These play a valuable
role in defining components used to build those systems, but should not be confused with OSI service interfaces.

IEEE
MAC Client MAC Client
MA_UNITDATA.request (destination_address, MA_UNITDATA.indication (destination_address,

source_address, source_address,
msdu, priority) msdu, priority)
MSAP MSAP
MAC Service
MAC Entity MAC Entity
LAN
Figure 7-1—MAC entities, the MAC Service, and MAC Service users (clients)
7.3 Layer management interfaces
A given N-entity can have many associated management controls, counters, and status parameters that are
not communicated to its user’s peers and whose values are either not determined by its user or not required
to change synchronously with the occurrence of individual N-service primitives to ensure successful
(N + 1)-protocol operation. Communication of the values of these parameters to and from local entities, i.e.,
within the same system, is modeled as occurring not through service primitives8 but through a layer
management interface. One protocol entity, for example a simple network management protocol (SNMP)
entity, can be used to establish the operational parameters of another. Communication of the results of Fault
Alarms to entities responsible for managing the network is one of the uses of layer management interfaces.
7.4 Service access points, interface stacks, and ports
Each service is provided to a single protocol entity at a service access point (SAP) within a system. A given
N-entity can support a number of N-SAPs and use one or more (N – 1)-SAPs. The SAP serves to delineate
the boundary between protocol specifications and to specify the externally observable relationship between
entities operating those protocols. A SAP is an abstraction and does not necessarily correspond to any
concrete realization within a system, but an N-entity often associates management counters with the SAP
and provides status parameters that can be used by the (N + 1)-entity using the SAP. Examples include the
MAC_Operational and operPointToPointMAC status parameters (6.6.2, 6.6.3 in IEEE Std 802.1Q-2011).
Each SAP has an identifier with a value that is local to the system and uniquely identifies the SAP within the
system.
The network and link layers9 of the reference model accommodate many different real networks,
subnetworks, and links with the requirements for bandwidth, multiplexing, security, and other aspects of
communication differing from network to network. A given service, e.g., the MAC Service, is often
8This would require considerable enlargement and continuous modification of service interfaces, obscuring their original purpose, not
to mention the creation of many additional interfaces and the addition of “pass-through” functions to others.
9
The data link layer, as originally envisaged in the OSI reference model, contained no addressing and caused some involved in its
development to reject the idea of LANs at the link layer. There is a sound argument for regarding LANs as simply subnetworks within
the network layer, and in practice this is how they are treated. However this would have been unpalatable to many more people at a time
when correspondence between LLC (ISO/IEC 8802-2:1998 [B7]) and high-level data link control (HDLC) was sought, together with
the adoption of a unique network layer protocol [ITU-T X.25 (1996)]. Continuing to regard the MAC Sublayer as part of the OSI Data
Link Layer does relatively little harm (except when duplication of network layer functionality is proposed) and is convenient given the
mass of historic documentation.

IEEE
provided by a number of protocols, layered to achieve the desired result. Together the entities that support a
particular SAP compose an interface stack. Figure 7-2 provides an example, showing the use of Link
Aggregation (IEEE Std 802.1AX™-2008 [B2]).
SAP
( )
SAP Link Aggregation SAP
( ) ( )
MAC MAC
LAN LAN
Figure 7-2—An interface stack
The term port is used to refer to the interface stack for a given SAP. Often the interface stack comprises a
single protocol entity attached to a single Local Area Network (LAN), and port can be conveniently used to
refer to several aspects of the interface stack, including the physical interface connector for example. In
more complex situations—such as that in Figure 7-2, where the parts of the interface stack provided by the
MAC entities effectively compose two ports that are then used by link aggregation to provide a single port to
its user—the port has to be clearly specified in terms of the particular SAP supported.
7.5 MAC method independent protocols and shims
Protocols specified in IEEE Std 802.3™-2008 [B3], IEEE Std 802.11™-2012 [B4], and other IEEE 802
standards, can be specific to their LAN media or to the way access to that media is controlled. Other
protocols and functions within the MAC sublayer, such as link aggregation and bridging, are MAC method
independent—thus providing consistent management and interoperability across a range of media.
Definition of a service facilitates the specification of shims, i.e., protocol entities that use the same service as
they provide. Protocol shims can be inserted into an interface stack to provide aggregation (e.g.,
IEEE Std 802.1AX [B2]), security (e.g., IEEE Std 802.1AE™-2006 [B1]), or multiplexing.
7.6 MAC Service clients
The protocol entity that uses the service provided at a MAC Service access point (MSAP) is commonly
referred to as the client of the MAC Service or of the entity providing the service. Within a Bridge, the MAC
Relay Entity is a client of the Internal Sublayer Service (ISS), and the Logical Link Control (LLC) Entity is
a client of the MAC Service. The LLC Entity is specified in ISO/IEC 8802.2 and provides protocol
identification, multiplexing, and demultiplexing to and from a number of clients that use a common MSAP.
The clients of LLC are also often referred to as clients of the MAC.
NOTE—For the purposes of this standard, the terms LLC and LLC Entity include the service provided by the operation
of entities that support protocol discrimination using an EtherType, i.e., protocol discrimination based on the Type inter-
pretation of the Length/Type field as specified in IEEE Std 802a™-2003.
7.7 Stations and systems
A LAN station comprises a single media access method specific entity, operating the MAC procedures
specified in the applicable IEEE 802 standard, together with other protocol entities mandated by those
standards (e.g., an LLC Entity) or commonly used in conjunction with that entity.

IEEE
A system is a collection of hardware and software components whose intercommunication is not directly
externally observable and outside the scope of the IEEE 802 standards that specify the system behavior as a
whole. Management of a system, when supported, is typically provided through a single management entity.
A system (such as a bridge) can contain many media access method specific entities, of the same or a variety
of types, attached to different LANs. A system can therefore be said to comprise one or more LAN stations.
7.8 Connectionless connectivity
The MAC Service supported by an IEEE 802 LAN provides connectionless connectivity, i.e.,
communication between attached stations occurs without explicit prior agreement between service users.
The potential connectivity offered by a connectionless service composes a connectivity association that is
established prior to the exchange of service primitives between service users. The way in which such a
connectivity association is established depends on the particular protocols and resources that support it, and
can be as simple as making a physical attachment to a wire. However simple or complex, the establishment
of a connectivity association for connectionless data transfer involves only a two-party interaction between
the service user and the service provider (though it can result in exchanges between service providing
entities in several systems) and not a three-party user-service-user interaction as is the case for connection-
oriented communication. With the continual increase in the number of ways that IEEE 802 LAN
connectivity can be supported, it is no longer useful to regard a LAN as a definite set of physical equipment.
Instead, a LAN is defined by the connectivity association that exists between a set of MSAPs.10
10
A LAN is thus defined in terms of its external observable behavior, not by an abstraction of its internal operation.

IEEE
8. Overview of the MAC Service
The MAC Service provides a connectionless-mode service for the transparent transfer of data between MAC
Service users. It makes invisible to these MAC Service users the way that supporting communications
resources are used to achieve this transfer.
In particular, the MAC Service provides for the following:
a) Independence of the underlying MAC Sublayer and Physical Layer—the MAC Service relieves
MAC Service users from all concerns, with the exception of Quality of Service (QoS) consider-
ations, regarding the MAC technology that is available.
b) Transparency of transferred information—the MAC Service provides for the transparent transfer of
MAC Service user data. It does not restrict the content, format, or coding of the information, nor
does it ever need to interpret its structure or meaning. It may however restrict the maximum number
of octets of MAC Service user data that can be supplied in a user/provider interaction.
c) Priority selection — the MAC Service makes available to MAC Service users a means to request the
transfer of data at a specified priority.
d) Addressing — the MAC Service provides the means for the MAC Service user to identify its MSAP
and to specify the MSAP or MSAPs to which data is to be transferred. This standard uses 48-bit
MAC addresses to identify the MSAP. MAC address formats and encoding are specified in
IEEE Std 802.
e) Connectionless data transfer — the MAC Service provides a means by which MSDUs of limited
length are delimited and transparently transmitted from one source MSAP to one or more destina-
tion MSAPs in a single MAC Service access, without establishing or later releasing a connection.

IEEE
9. Model of the MAC Service
Although the MAC Service is not identified or defined in the OSI Basic Reference Model, this standard uses
the abstract model for a layer service defined in ISO/IEC 10731:1994, Clause 5, as it might apply to the
MAC Sublayer. The model defines the interactions between the MAC Service users and the MAC Service
provider that take place at the two MSAPs. Information is passed between the MAC Service user and the
MAC Service provider by service primitives that may convey parameters.
9.1 Model of a MAC connectionless-mode transmission
A defining characteristic of MAC connectionless-mode service is a preexisting connectivity association

amongst a set of MSAPs.
Only one type of object, the unitdata object, can be handed over to the MAC Service provider via an MSAP.
In Figure 9-1, MAC Service User A represents the MAC Service user that passes objects to the MAC
Service provider. MAC Service User B represents the MAC Service user that accepts objects from the MAC
Service provider.
MAC Service MAC Service

User A User B
MSAP MSAP
Association between A and B
MAC Service Provider
Figure 9-1—Model for a MAC Service Connectionless-mode Transmission
9.2 Service provided by the connectionless-mode MAC Service
In general, the MAC Service provider may perform any or all of the following actions:
a) Discard objects
b) Change the order of the objects
The MAC Service exhibits a negligible rate of the following:
c) Object duplication
d) Reordering of objects for a given priority
Awareness of the characteristics of the MAC Service provided, e.g., the rate at which objects may be
discarded, duplicated, or misordered, is part of the MAC Service user’s a priori knowledge of the
environment.

IEEE
10. Quality of connectionless-mode service
The term Quality of Service (QoS) refers to certain characteristics of a connectionless-mode transmission as
observed between the MSAPs. QoS describes aspects of a connectionless-mode transmission that are solely
attributable to the MAC Service provider; it can only be properly determined in the absence of MAC Service
user behavior (which is beyond the control of the MAC Service provider) that specifically constrains or
impedes the performance of the MAC Service.
Whether the QoS provided for each instance of the connectionless-mode transmission is the same for each
MAC Service user depends on information concerning the nature of the service made available to the MAC
Service user(s) by the MAC Service provider prior to the invocation of the service.
10.1 Determination of QoS for connectionless-mode service
A basic characteristic of a connectionless-mode service is that, unlike a connection-mode service, no

specific association similar to that provided by a connection establishment is set up between the parties
involved. Thus, characteristics of the service to be provided during the transfer are not negotiated between
the MAC Service user and the MAC Service provider.
Associated with each MAC connectionless-mode transmission, certain measures of QoS are requested by
the transmitting MAC Service user when the primitive action is initiated. The requested measures (or
parameter values and options) are based on prior knowledge by the MAC Service user of the service(s) made
available to it by the MAC Service provider. Knowledge of the characteristics and type of service provided
(i.e., the parameters, formats, and options that affect the transfer of data) is made available to a MAC
Service user through some layer management interaction prior to (any) invocation of the MAC
connectionless-mode service. Thus, the MAC Service user not only has knowledge of the parties with which
it may communicate, it also has explicit knowledge of the characteristics of the service it can expect for each
invocation of the service.
10.2 Definition of connectionless-mode QoS parameters
QoS comprises the following:
a) Service availability
b) Frame loss
c) Frame misordering
d) Frame duplication
e) Frame transit delay
f) Frame lifetime
g) Undetected frame error rate
h) Maximum SDU size
i) Frame priority
j) Throughput
These parameters are discussed in detail in 6.5 in IEEE Std 802.1Q-2011.

IEEE
11. Internal Sublayer Service
The Internal Sublayer Service (ISS) forms the basis of the MAC Service, providing elements necessary both
to the performance of data transfer between MSAPs and the provision of MAC relay in IEEE 802.1D MAC
Bridges and IEEE 802.1Q VLAN Bridges. Within an end-station, a subset of these elements provides the
MAC Service specified in Clause 13. Within an IEEE 802.1Q VLAN Bridge, these elements are augmented
to identify a VLAN as specified in 6.8 of IEEE Std 802.1Q-2011. The ISS excludes MAC-specific features
and procedures whose operation is confined to an individual LAN.
11.1 Service primitives and parameters
The ISS is specified by two unit-data primitives, an M_UNITDATA.indication and an

M_UNITDATA.request, together with the parameters of those primitives. Each M_UNITDATA indication
corresponds to the receipt of an error-free MAC frame from a LAN. A data request primitive is invoked to
transmit a frame to an individual LAN.
NOTE 1—Detailed specifications of error conditions in received frames are contained in the relevant MAC standards;
for example, Frame Check Sequence (FCS) errors, length errors, and non-integral number of octets.
M_UNITDATA.indication (
destination_address,
source_address,
mac_service_data_unit,
priority,
drop_eligible,
frame_check_sequence,
service_access_point_identifier,
connection_identifier
)
M_UNITDATA.request (
source_address,
priority,
drop_eligible,
frame_check_sequence,
service_access_point_identifier,
connection_identifier
)
The destination_address parameter is the address of an individual MSAP or a group of MSAPs. If the local
MSAP is designated by the destination address parameter of an M_UNITDATA.request primitive, the
indication primitive is not also invoked by the MAC entity (see Clause 7) to the MAC Service user. For
example, all frames transmitted to the broadcast address invoke M_UNITDATA.indication primitives at all
MSAPs in the LAN except at the MSAP that generated the request.
NOTE 2—This non-reflective behavior is a change from that previously specified in ISO/IEC 15802-1 [B8], where an
indication primitive was invoked by the MAC entity to the originating MAC service user if the local MSAP was desig-
nated by the destination_address parameter. Consequently, if the former behavior is desired, it would be necessary to
provide it locally. This change was made to bring the definition of the MAC service into line with the requirements of
MAC bridging. In an underlying MAC whose natural behavior is for such local indications to be invoked, the MAC
entity is the only point at which this reflection can be suppressed.

IEEE
The source_address parameter is the individual address of the source MSAP.
The mac_service_data_unit parameter is the service user’s data. This parameter allows the transmission of
the MAC Service user data between MAC Service users, without modification by the MAC Service
provider. The MAC Service user may transmit any integral number of octets greater than zero, up to a limit
determined by the MAC Service provider. The value of this limit is made available to the MAC Service user
by the use of management facilities or prior knowledge.
The default priority value is 0. Values 1 through 7 form an ordered sequence of user_priorities, with 1 being
the lowest value, 7 the highest, and 0 falling between 1 and 2. If the MAC Service user does not explicitly
state a value for the priority parameter, or requests a value not supported by the provider, the MAC Service
provider uses default values. The value of the priority parameter in the two primitives are related so that
a) In the request primitive, any defined value is allowed; and

b) In the indication primitive, the priority indicated is the value requested or as modified by the MAC
Service provider.
The drop_eligible parameter provides guidance to the recipient of the service request or of an indication
corresponding to the service request, and takes the values True or False. If drop_eligible is True, the
parameters of the request are discarded in preference to others with drop_eligible False that result in frames
in the same queue. The default drop_eligible value is False.
The frame_check_sequence parameter is explicitly provided with the M_UNITDATA.indication so that it

can be used in a related M_UNITDATA.request. The parameter comprises the Frame Check Sequence (FCS)
value and sufficient information to determine whether the FCS value can be used. If the
frame_check_sequence parameter is provided with an M_UNITDATA.request and the receiving and the
transmitting service providers
1) Use the same algorithm to determine the FCS; and

2) Apply that algorithm to the same fields of the frame, i.e., the FCS coverage is the same; and
3) The data that is within the coverage of the FCS remains the same;
then the transmitting service provider uses the supplied FCS value.
NOTE 3—There are two possibilities for recreating a valid FCS. Annex F of IEEE Std 802.1D-2004 discusses these pos-
sibilities in more detail.
Unlike the other parameters of the service primitives, the service_access_point_identifier and
connection_identifier are not parameters of the peer-to-peer service. The values of the
service_access_point_identifier and connection_identifier are purely local to the system within which a
given service request or service indication occurs, and are not conveyed to the communicating peer system.
The values are opaque to the user of the ISS and are not manipulated by that service user, thus permitting
independent operation of entities within the MAC sublayer as well as extending capabilities by the addition
of protocol shims. The values are not conveyed in any external protocol, including management protocols;
however, management protocols can convey externally visible data related to the SAP or connection. For
example, there is a one-to-one association between service_access_point_identifier of a Bridge Port used
by the MAC Relay Entity and the port number identifying that Bridge Port in management and control
protocols.
The service_access_point_identifier parameter always identifies the SAP at which the service indication
occurs or the service request is made, in the context of the receiving or transmitting system. In the common
case of direct support of the ISS by a specific MAC procedure, it identifies the attached individual LAN.

IEEE
When a protocol entity in the interface stack either uses or supports multiple SAPs, the
service_access_point_identifier parameter associates the service primitive with the appropriate SAP.
The connection_identifier can be null and is ignored by any specific MAC procedures except as explicitly
specified in those procedures (6.7 of IEEE Std 802.1Q-2011). The connection_identifier is used where this
standard specifically provides for efficient support of a single SAP by a number of connections, i.e., by
dynamically created connectivity associations between peer entities. For example, a Provider Instance Port
(6.10 of IEEE Std 802.1Q-2011) creates connections with peer Provider Instance Ports, and uses the
connection_identifier to associate the backbone MAC address of the peer Provider Instance Port with
Customer MAC Addresses that can be reached through that peer Provider Instance Port (26.4 of
IEEE Std 802.1Q-2011). Following an M_UNITDATA.indication at a given SAP with a given
source_address and connection_identifier, a subsequent M_UNITDATA.request at the same SAP with
that source address as its destination_address and with the same connection_identifier will result in an
M_UNITDATA.indication at the peer entity selected by the connection_identifier (in the absence of frame
loss or reconfiguration of network components). The value of a connection_identifier is significant only at
a single SAP. Any protocol entity in the interface stack that does not specify use of the
connection_identifier assigns the connection_identifier value (if any) supplied with a request from the
user of the protocol entity (or with an indication from the provider of the service used by the protocol entity)
to the connection_identifier on associated requests made (or indications generated) by the protocol entity.
NOTE 4—The ISS specification in this standard omits the frame_type and access_priority parameters that are included
in the ISS specification in IEEE Std 802.1D. The frame_type is not required as the receipt of a frame other than a user
data frame does not cause a data indication, nor are such frames transmitted by the media independent bridge functions.
The mapping of the ISS to particular access methods specified by this standard includes derivation of the access_priority
parameter (for those media that require it) from the ISS priority parameter.
11.2 Status parameters
The ISS also makes available status parameters that reflect the operational state and administrative controls
over each instance of the service provided.
The MAC_Enabled parameter is TRUE if use of the service is permitted; and is otherwise FALSE. The
value of this parameter is determined by administrative controls specific to the entity providing the service.
The MAC_Operational parameter is TRUE if the entity providing the service is capable of transmitting and
receiving frames and its use is permitted by management, i.e., MAC_Enabled is also TRUE. Its value is
otherwise FALSE. The value of this parameter is determined by the specific MAC procedures.
NOTE—These status parameters provide a common approach across MACs for handling the fact that:
a) A MAC can inherently be working or not;
b) If the MAC is working, its operational state can be administratively overridden.
11.3 Point-to-point parameters
The ISS also makes available status parameters that reflect the point-to-point status of each instance of the
service provided and provide administrative control over the use of that information.
If the operPointToPointMAC parameter is TRUE, the service is used as if it provides connectivity to at

most one other system; if FALSE, the service is used as if it can provide connectivity to a number of
systems.
The adminPointToPointMAC parameter can take one of three values. If it is

IEEE
a) ForceTrue, operPointToPointMAC is always TRUE, regardless of any indications to the contrary

generated by the service providing entity.
b) ForceFalse, operPointToPointMAC is always FALSE.
c) Auto, operPointToPointMAC is determined by the service providing entity.
The value of operPointToPointMAC is determined dynamically; i.e., it is reevaluated whenever

adminPointToPointMAC or the status of the service providing entity changes.

IEEE
12. Support of the Internal Sublayer Service
12.1 Support of the Internal Sublayer Service by specific MAC procedures
This subclause specifies support of the Internal Sublayer Service (ISS) by MAC Entities that use specific
IEEE 802 media access methods, including the mapping to the MAC protocol and procedures for each
access method, and the encoding of the parameters of the service in MAC frames. The mapping is specified
by reference to the IEEE 802 standards that specify each access method. The mapping draws attention to any
special responsibilities of Bridges attached to LANs of that type. MAC control frames, typically frames that
control some aspect of the operation of the MAC, i.e., frames that do not convey MAC user data, do not give
rise to ISS data indications and are therefore not forwarded by a Bridge to any LAN other than that on which
they originated.
Each MAC Entity examines all frames received on the LAN to which it is attached. All error-free received
user data frames give rise to M_UNITDATA indication primitives. A frame that is in error, as defined by the
relevant MAC specification, is discarded by the MAC Entity without giving rise to any M_UNITDATA
indication.
12.1.1 Support of the Internal Sublayer Service by IEEE Std 802.3-2008 (CSMA/CD)
The CSMA/CD access method is specified in IEEE Std 802.3-2008 [B3]. Clause 3 of that standard specifies
the MAC frame structure, and Clause 4 specifies the MAC method.
On receipt of an M_UNITDATA.request primitive, the local MAC Entity performs Transmit Data
Encapsulation, assembling a frame using the parameters supplied as specified below. It prepends a preamble
and a Start Frame Delimiter before handing the frame to the Transmit Media Access Management
Component in the MAC Sublayer for transmission (4.2.3 in IEEE Std 802.3-2008 [B3]).
On receipt of a MAC frame by Receive Media Access Management, the MAC frame is passed to Receive
Data Decapsulation, which validates the FCS and disassembles the frame, as specified below, into the
parameters that are supplied with an M_UNITDATA.indication primitive (4.2.4 in IEEE Std 802.3-2008
[B3]).
The destination_address parameter is encoded in the destination address field (3.2.4 in IEEE Std 802.3-
2008 [B3]).
The source_address parameter is encoded in the source address field (3.2.5 in IEEE Std 802.3-2008 [B3]).
The number of octets of data in the mac_service_data_unit parameter is either:
a) Encoded in the Length/Type field of the MAC frame if the frame makes use of the Length
interpretation of the Length/Type field (3.2.6 in IEEE Std 802.3-2008 [B3]), or
b) Determined from the length of the received MAC frame, if the frame makes use of the Type
interpretation of the Length/Type field (3.2.6 in IEEE Std 802.3-2008 [B3]).
The octets of data are encoded in the data field (3.2.7 in IEEE Std 802.3-2008 [B3]). The Length/Type field
forms the initial octets of the mac_service_data_unit parameter.
The priority and drop_eligible parameters provided in a data request primitive are not encoded in MAC
frames. The priority parameter provided in a data indication primitive shall take the value of the Default
Priority parameter for the Port through which the MAC frame was received. The default value of this
parameter is 0. This parameter may be set by management in which case the capability to set it to any of the
values 0 through 7 shall be provided.

IEEE
The frame_check_sequence parameter is encoded in the FCS field of the MAC frame (3.2.9 in
IEEE Std 802.3-2008). The FCS is computed as a function of the destination address, source address,
length, data, and PAD fields. If an M_UNITDATA.request primitive is not accompanied by this parameter, it
is calculated in accordance with 3.2.9 in IEEE Std 802.3-2008 [B3].
NOTE—Since the PAD field, if present, contributes to the FCS, this parameter needs to include at least the contribution
of the PAD field to the FCS in order for the original FCS to be preserved. (See Annex F in IEEE Std 802.1D-2004.)
No special action, above that specified for the support of use of the MAC Service by LLC, is required for the
support of the MAC ISS by the CSMA/CD access method.
The values of the MAC_Enabled and MAC_Operational parameters are determined as follows:
c) For a MAC entity that contains a Link Aggregation sublayer, the value of MAC_Enabled is directly
determined by the value of the aAggAdminState attribute (6.3.1.1.13 in IEEE Std 802.1AX-2008
[B2]), and the value of MAC_Operational is directly determined by the value of the aAggOperState
attribute (6.3.1.1.14 in IEEE Std 802.1AX-2008 [B2]).
d) Otherwise, for IEEE 802.3 MAC entities that support the medium attachment unit (MAU) managed
Object Class (30.5.1 in IEEE Std 802.3-2008 [B3]):
1) The value of MAC_Enabled is TRUE.
2) The value of MAC_Operational is TRUE if the attribute aMediaAvailable carries the value
available.
3) The value of MAC_Operational is FALSE if the attribute aMediaAvailable carries any value
other than available.
e) Otherwise:
1) The value of MAC_Enabled is TRUE.
2) The value of MAC_Operational is TRUE.
From the point of view of determining the value of operPointToPointMAC (6.6.3 in IEEE Std 802.1Q-
2011), the MAC is considered to be connected to a point-to-point LAN if any of the following conditions are
true:
f) The MAC entity concerned contains a Link Aggregation sublayer, and the set of physical MACs
associated with the Aggregator are all aggregatable; or
g) The MAC entity concerned supports auto negotiation (e.g., Clauses 28, 37, and 73 of
IEEE Std 802.3-2008 [B3]), and the auto negotiation function has determined that the LAN is to be
operated in full duplex mode; or
h) The MAC entity has been configured by management means for full duplex operation.
Otherwise, the MAC is considered to be connected to a LAN that is not point-to-point.
On receipt of an M_UNITDATA.request primitive that represents a tagged frame, the implementation is

permitted to adopt either of the following approaches with regard to the operation of Transmit Data
Encapsulation for frames whose length would, using the procedure as described earlier, be less than
68 octets:
i) Use the procedure as described in a) and b). This procedure can result in tagged frames of less than
68 octets (but at least 64 octets) being transmitted; or
j) Include additional octets before the FCS field in order for the transmitted frame length for such
frames to be 68 octets. This procedure results in a minimum tagged frame length of 68 octets.

IEEE
When a tagged frame of less than 68 octets in length is received on a CSMA/CD LAN, and is forwarded as
an untagged frame, the procedure as described in a) and b) results in additional octets being included before
the FCS field on transmission in order that the transmitted frame length meets the minimum frame size
requirements of 3.2.8 in IEEE Std 802.3-2008 [B3].
12.1.2 Support by IEEE Std 802.11-2012 (Wireless LAN)
The wireless LAN access method is specified in IEEE Std 802.11-2012 [B4]. Clause 8 of that standard
specifies frame formats, Clause 9 specifies the MAC sublayer function, and Clause 10 specifies the
mandatory MAC sublayer management function.
A Bridge to an IEEE 802.11 LAN shall connect to an IEEE 802.11 Portal, which in turn connects to an
IEEE 802.11 Distribution System. For the purposes of bridging, the service interface presented at the Portal
is identical to the service interface presented at the IEEE 802.11 MAC SAP. An instance of an 8802-11
Distribution System can be implemented from IEEE 802 LAN components. IEEE 802.11 stations (STAs)
attach to the Distribution System via an IEEE 802.11 Access Point. A bridge shall not connect to an
IEEE 802.11 Independent basic service set (BSS). For a description of the IEEE 802.11 architecture, see
Clause 4 of IEEE Std 802.11-2012 [B4].
On receipt of an M_UNITDATA.request primitive, the portal constructs a MSDU and passes it to the MAC
Data service for transmission (in accordance with the frame formats and procedures specified in
IEEE Std 802.11-2012, Clauses 5, 8, and 9 [B4]) using the parameters supplied as specified below.
On receipt of a valid MSDU (see IEEE Std 802.11-2012, Clauses 5, 8, and 9 [B4]), the portal generates an
M_UNITDATA.indication primitive with parameter values derived from the frame fields as specified
below.
When processing MSDU_from_LLC, the Type subfield of the Frame Control field specified in 8.2.4.1.3 of
IEEE Std 802.11-2012 [B4] shall be encoded as Data in MAC frames (see Table 8-1 in IEEE Std 802.11-
2012).
The destination_address parameter is encoded in MAC frames as the DA described in Table 8-19 of 8.3.2.1
of IEEE Std 802.11-2012 [B4].
The source_address parameter is encoded in MAC frames as the SA described in Table 8-19 of 8.3.2.1 of
IEEE Std 802.11-2012 [B4].
The mac_service_data_unit parameter is encoded in the Frame Body field (8.2.4.7.1 of IEEE Std 802.11-
2012 [B4]) of MAC frames. The length of the MSDU shall be ≤ 2304 octets. The length is not encoded in
MAC frames; rather, it is conveyed in the PHY headers.
The priority parameter is not encoded in MAC frames. The priority parameter provided in an
M_UNITDATA.indication primitive shall take the value of the Default Priority parameter for the port
through which the MSDU was received. The default value of this parameter is 0, it may be set by
management, in which case the capability to set it to any of the values 0 through 7 shall be provided.
The FCS field of MAC frames is calculated and encoded in accordance with 8.2.4.8 of IEEE Std 802.11-
2012 [B4].
No special action, above that specified in IEEE Std 802.11-2012 [B4], is required for the support of the
MAC ISS by the wireless LAN access method.

IEEE
12.1.3 Support by IEEE Std 802.17™-2004 (RPR)
The resilient packet ring (RPR) MAC access method is specified in IEEE Std 802.17-2004 [B5]. Clause 6 of
that standard specifies the MAC service interface and reference model. Clause 7 specifies the MAC
transmission and reception procedures. Clause 9 specifies the MAC frame structure.
On receipt of an M_UNITDATA.request primitive, the local MAC entity performs transmit data
encapsulation, which assembles a MAC frame (Clause 9 in IEEE Std 802.17-2004 [B5]) with the parameters
supplied as specified in the paragraphs that follow.
On receipt of a valid MAC frame (Clause 9 in IEEE Std 802.17-2004 [B5]), an M_UNITDATA.indication
primitive is generated, with parameter values derived from the frame fields as specified in the paragraphs
that follow.
The destination_address parameter is encoded in the da field of the MAC frame (9.2.2.3 in
IEEE Std 802.17-2004 [B5]). For request primitives from a client (e.g., MAC Relay Entity) where the
source_address parameter does not equal the MAC’s address, the destination_address parameter is encoded
in both the da and the daExtended fields of the MAC frame (9.2.2.8 in IEEE Std 802.17-2004).
The source_address parameter is encoded in the sa field of the MAC frame (9.2.2.4 in IEEE Std 802.17-
2004 [B5]) when supplied in the request primitive and when the source_address is equal to the MAC’s
address. When the source_address is supplied in the request primitive, and when the source_address is not
equal to the MAC’s address, then the source_address is encoded in the saExtended field of the MAC frame
(9.2.2.9 in IEEE Std 802.17-2004).
The mac_service_data_unit parameter is the service user data that includes the protocol type and is
encoded in the protocolType and serviceDataUnit fields of the MAC frame (9.2.2.10 and 9.2.2.11 in
IEEE Std 802.17-2004 [B5]).
The priority parameter provided in the data request primitive is encoded into the service class (sc) subfield
of the baseControl field (9.6.4 in IEEE Std 802.17-2004 [B5]) of the MAC frame. This encoding is done in
accordance with the priority to MAC service class mapping shown in Table 12-1.
Table 12-1—Priority to MAC service class mapping
Priority MAC service class
0 classC
1 classC
2 classC
3 classC
4 classB
5 classB
6 classA
7 classA

IEEE
In the case of the indication primitive, the priority parameter is directly derived from the sc subfield of the
baseControl field of the MAC frame. The mapping between the service class and the priority parameter of
the indication primitive is provided in Table 12-2.
Table 12-2—MAC service class to priority mapping
MAC service class Priority
classC 0
classB 4
classA 6
The frame_check_sequence parameter found in the data request primitive is encoded in the fcs field of the
MAC frame (9.2.2.12 in IEEE Std 802.17-2004 [B5]). The fcs is calculated as a 32-bit CRC starting from
the first byte following the header checksum field (hec) (9.2.2.7 in IEEE Std 802.17-2004) to the end of the
payload (9.2.2.11 of IEEE Std 802.17-2004) in accordance with E.2 in IEEE Std 802.17-2004. If an
M_UNITDATA.request primitive is not accompanied by this parameter, it is calculated in accordance with
E.2 in IEEE Std 802.17-2004.
No special action, above that specified in IEEE Std 802.17-2004 [B5], is required for the support of the
MAC ISS by the RPR access method.
The IEEE 802.17 MAC service interface supports a number of optional parameters that are specific to the
IEEE 802.17 MAC. These parameters take on default values in M_UNITDATA.request primitive during
transmission, and they are ignored by the MAC Relay on reception. The default values and procedures for
handling RPR specific parameters are defined in 6.4.1, Clause 7, and F.3.1 in IEEE Std 802.17-2004 [B5].
12.1.4 Support by IEEE 802.20™ Mobile Broadband Wireless Access Method (MBWA)
12.1.4.1 Support by Wideband Mode of IEEE Std 802.20-2008 (MBWA)
The Mobile Broadband Wireless Access Method for the IEEE 802.20 Wideband Mode is specified in 5.4
and Clause 6 through Clause 17 of IEEE Std 802.20-2008 [B6]. Clause 8 of the standard specifies the
Wideband Mode Lower MAC Layer Frame structure and protocol procedures. Clause 7 specifies the Radio
Link Sublayer protocol, and Clause 6 defines the Services Sublayer of the Wideband Mode. Clause 11
defines the Connection Control Plane that controls the state of the air-link by managing the states of
individual Lower MAC Layer protocols, and by providing individual Lower MAC Layer protocols with
operating parameters.
The Basic Packet Consolidation Protocol (8.2 in IEEE Std 802.20-2008 [B6]) provides packet consolidation
on the transmit side and provides packet de-multiplexing on the receive side. It provides an interface for the
Radio Link Sublayer to transport user information from the Services Sublayer.
For packets to be transmitted over the air interface (wireless medium) from either the Access Node (AN) or
Access Terminal (AT), the Lower MAC Sublayer shall accept Radio Link Sublayer data and control packets
and shall generate Lower MAC Sublayer control packets of its own. For packets leaving the air interface
(wireless medium) for the AN or AT, the Lower MAC Sublayer shall de-multiplex the received packets and
shall deliver the payload to the Radio Link Sublayer. The Radio Link Sublayer shall deliver the payload to
the Services Sublayer, which includes support for different IEEE 802.3 frame-based protocols.

IEEE
12.1.4.1.1 Support for Internal Sublayer Service under Wideband Mode of IEEE Std 802.20
The destination_address, source_address, mac_service_data_unit, and priority parameters of the

M_UNITDATA primitive are encoded as described in 6.6.1 in IEEE Std 802.1Q-2011.
The value of operPointToPointMAC (6.6.3 in IEEE Std 802.1Q-2011) shall be TRUE.
The value of MAC_Enabled shall be determined by the procedure described in 6.6.2 in IEEE Std 802.1Q-
2011.
After the IEEE 802.20 AT has registered with the AN, authenticated, and performed capabilities negotiation,
and after the stream is established to carry IEEE 802 frames, then the value of the MAC_Operational
parameter shall be determined by the procedure described in 6.6.2 in IEEE Std 802.1Q-2011. Beforehand,
the value of MAC_Operational shall be FALSE.
Frame size limits are determined by IEEE Std 802.3-2008 [B3].
12.1.4.2 Support by 625k-MC mode of IEEE Std 802.20-2008 (MBWA)
The Mobile Broadband Wireless Access Method for 625k-MC mode is specified in 5.5, Clause 18 through
Clause 31, and Annex A of IEEE Std 802.20-2008 [B6]. Clause 19 of the standard specifies 625k-MC Mode
MAC Frame structure. Clause 23 specifies the MAC Protocol Sublayer function to implement the 625k-MC
mode MAC service. Clause 25 specifies the L3 protocol, and Clause 26 defines all the primitives used in
625k-MC Mode.
The L3 protocol layer is made up of components with distinct roles in supporting a connection across the air
interface. The L3 Connection Management (CM) module provides an application level interface to the
higher layer. The L3 protocol creates logical connections to transport the higher layer L4 data packets. The
L3 Registration Management (RM) module takes the L4 data packets provided by the higher layer (through
L3 CM) and converts them into a form that can be sent over the air interface. On the receiving side, L3 RM
converts packets received from the air interface back into network packets before giving them to L3 CM.
Clause 26 defines the higher layer to L3 CM Interface Primitives for the SAP that shall be provided by L3
CM for the use of the higher layer. Clause 26 defines L3 CM to L4 Interface Primitives for the SAP
provided by the higher layer for the use of L3 CM.
For packets entering air interface (wireless medium) from either base station (BS) network or End User
Device (EUD), L3 shall accept L4 data and L4 control packets and shall generate L3 control packets of its
own, and shall then send them to L2 RLC. For packets leaving air interface (wireless medium) for BS
network or EUD, L3 shall accept byte streams from L2 RLC, shall determine whether the packet is a data
packet, an L3 control packet, or an L4 control packet, and shall route the L4 control and data packets to the
higher layer.
12.1.4.2.1 Support for ISS under 625k-MC mode of IEEE Std 802.20-2008
The destination_address, source_address, mac_service_data_unit, and priority parameters of the

M_UNITDATA primitive are encoded as described in 6.6.1 in IEEE Std 802.1Q-2011 and presented as an
ISS-supported IEEE 802.3 MAC to the higher layer. The higher layer triggers the L3 protocol of 625k-MC.
The L3 CM module state machine shall respond to requests from the higher layer for virtual connections
across the air interface and requests registrations from the L3 RM to allow the virtual connections to use
physical channels (streams).
The value of operPointToPointMAC (6.6.3 in IEEE Std 802.1Q-2011) shall be TRUE.

IEEE
The value of MAC_Enabled shall be determined by the procedure described in 6.6.2 in IEEE Std 802.1Q-
2011.
Initially, the value of MAC_Operational shall be FALSE. After the user terminal (UT) has registered with
the BS, authenticated, and performed capabilities negotiation, and after the stream is established to carry
IEEE 802 frames, then the value of the MAC_Operational parameter shall be determined by the procedure
described in 6.6.2 in IEEE Std 802.1Q-2011. Frame size limits are determined by IEEE Std 802.3-2008
[B3].

IEEE
13. MAC Service
13.1 Function
The MAC connectionless-mode transmission service (the MAC Service) is provided using a subset of the
elements of the ISS (Clause 11). The primitives defined in this clause can be used to transmit an
independent, self-contained MSDU from one MSAP to another MSAP in a single service access. It is self-
contained in that all of the information required to deliver the MSDU is presented to the MAC Service
provider in a single service access; thus no initial establishment or subsequent release of a connection is
required.
An MSDU transmitted using MAC connectionless-mode transmission is not considered by the MAC
Service provider to be related in any way to any previously transmitted MSDU. Although the MAC Service
maintains the integrity of individual MSDUs, it does not necessarily deliver them to the receiving MAC
Service user in the order in which they are presented by the transmitting MAC Service user, for example in
cases where they have different priorities.
The MAC Service provider is not required to maintain state information for flow control between specific
combinations of MSAPs.
13.2 Service primitives and parameters
Two unit-data primitives are specified for the connectionless-mode data transmission service, an
MA_UNITDATA.indication and an MA_UNITDATA.request, together with the parameters of those
primitives. Each MA_UNITDATA indication corresponds to the receipt of an error-free MAC frame from a
LAN. A data request primitive is invoked to transmit a frame to an individual LAN.
NOTE 1—Detailed specifications of error conditions in received frames are contained in the relevant MAC standards;
for example, FCS errors, length errors, and non-integral number of octets.
MA_UNITDATA.indication (
source_address,
priority
)
MA_UNITDATA.request (
source_address,
priority
)
The destination_address parameter is the address of an individual MSAP or a group of MSAPs. The
source_address parameter is the individual address of the source MSAP.
The mac_service_data_unit parameter is the service user data. The default priority value is 0. Values 1
through 7 form an ordered sequence of user_priorities, with 1 being the lowest value, 7 the highest, and 0
falling between 1 and 2.
NOTE 2—The specification in this standard differs from that in IEEE Std 802.1D as it omits the frame_type and
access_priority parameters. The frame_type is not required as the receipt of a frame other than a user data frame does not

IEEE
cause a data indication. The mapping of these primitives to particular access methods specified by this standard includes
derivation of the access_priority parameter (for those media that require it) from the priority parameter specified here.
NOTE 3—The remaining parameters associated with the M_UNITDATA.request and M_UNITDATA.indication primi-
tives (frame_check_sequence, drop_eligible, service_access_point_identifier, and connection_identifier) are unspeci-
fied.
13.3 Status parameters
The connectionless-mode transmission service also makes available status parameters that reflect the
operational state and administrative controls over each instance of the service provided.
The MAC_Enabled parameter is TRUE if use of the service is permitted, and is otherwise FALSE. The
value of this parameter is determined by administrative controls specific to the entity providing the service.
The MAC_Operational parameter is TRUE if the entity providing the service is capable of transmitting and
receiving frames and its use is permitted by management, i.e., MAC_Enabled is also TRUE. Its value is
otherwise FALSE. The value of this parameter is determined by the specific MAC procedures.
NOTE—These status parameters provide a common approach across MACs for handling the fact that:
a) A MAC can inherently be working or not;
b) If the MAC is working, its operational state can be administratively overridden.
13.4 Sequence of primitives
The sequence of primitives in a successful MAC Sublayer connectionless-mode transmission is defined in

the time sequence diagram in Figure 13-1.
MA_UNITDATA.request
MA_UNITDATA.indication
Figure 13-1—Sequence of primitives

IEEE
Annex A
(informative)
Bibliography
[B1] IEEE Std 802.1AE™-2006, IEEE Standard for Local and metropolitan area networks—Media Access
Control (MAC) Security.11, 12
[B2] IEEE Std 802.1AX™-2008, IEEE Standard for Local and Metropolitan Area Networks—Link
Aggregation.
[B3] IEEE Std 802.3™-2008, IEEE Standard for Information technology—Telecommunications and
information exchange between systems—Local and metropolitan area networks—Specific requirements—
Part 3: Carrier Sense Multiple Access with Collision Detection (CSMA/CD) Access Method and Physical
Layer Specifications.
Part 11: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Specifications.
Part 17: Resilient packet ring (RPR) access method and physical layer specifications.
[B6] IEEE Std 802.20™-2008, IEEE Standard for Local and metropolitan area networks—Part 20: Air
Interface for Mobile Broadband Wireless Access Systems Supporting Vehicular Mobility—Physical and
Media Access Control Layer Specification.
[B7] ISO/IEC 8802-2:1998, Information technology—Telecommunications and information exchange

between systems—Local and metropolitan area networks—Specific requirements—Part 2: Logical link
control.13
[B8] ISO/IEC 15802-1, Information technology—Telecommunications and information exchange between

systems—Local and metropolitan area networks—Common specifications—Part 1: Medium Access
Control (MAC) service definition.
11
IEEE publications are available from The Institute of Electrical and Electronics Engineers (http://standards.ieee.org/).
12The IEEE standards or products referred to in this annex are trademarks of The Institute of Electrical and Electronics Engineers, Inc.
13
ISO/IEC publications are available from the ISO Central Secretariat (http://www.iso.org/). ISO publications are also available in the
United States from the American National Standards Institute (http://www.ansi.org/).

Media Access Control (MAC) Service: IEEE Standard For Local and Metropolitan Area Networks

Uploaded by

Copyright:

Available Formats

Media Access Control (MAC) Service: IEEE Standard For Local and Metropolitan Area Networks

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Media Access Control (MAC) Service: IEEE Standard For Local and Metropolitan Area Networks

Uploaded by

Copyright:

Available Formats

IEEE Standard for

Local and metropolitan area networks—

Media Access Control (MAC) Service

IEEE Computer Society

IEEE Standard for

Media Access Control (MAC) Service

Approved 30 August 2012

The Institute of Electrical and Electronics Engineers, Inc.

Copyright © 2012 by The Institute of Electrical and Electronics Engineers, Inc.

Print: ISBN 978-0-7381-7304-7 STD97279

Comments on standards should be submitted to the following address:

Secretary, IEEE-SA Standards Board

Laws and regulations

Updating of IEEE documents

iv Copyright © 2012 IEEE. All rights reserved.

Copyright © 2012 IEEE. All rights reserved. v

Tony Jeffree, Chair

vi Copyright © 2012 IEEE. All rights reserved.

Copyright © 2012 IEEE. All rights reserved. vii

Richard H. Hulett, Chair

Richard DeBlasio, DOE Representative

viii Copyright © 2012 IEEE. All rights reserved.

Secretary, IEEE-SA Standards Board

Copyright © 2012 IEEE. All rights reserved. ix

2. Normative references ........................................................................................................................... 2

3.1 Basic reference model definitions................................................................................................ 3

4. Acronyms and abbreviations ............................................................................................................... 4

6.1 General considerations................................................................................................................. 6

7. Basic architectural concepts and terms ................................................................................................ 7

7.1 Protocol entities, peers, layers, services, and clients ................................................................... 7

8. Overview of the MAC Service .......................................................................................................... 11

9. Model of the MAC Service................................................................................................................ 12

9.1 Model of a MAC connectionless-mode transmission................................................................ 12

10. Quality of connectionless-mode service ............................................................................................ 13

10.1 Determination of QoS for connectionless-mode service ........................................................... 13

11. Internal Sublayer Service................................................................................................................... 14

11.1 Service primitives and parameters ............................................................................................. 14

12. Support of the Internal Sublayer Service ........................................................................................... 18

12.1 Support of the Internal Sublayer Service by specific MAC procedures.................................... 18

Copyright © 2012 IEEE. All rights reserved. xi

13.1 Function ..................................................................................................................................... 25

Annex A (informative) Bibliography ............................................................................................................ 27

xii Copyright © 2012 IEEE. All rights reserved.

Copyright © 2012 IEEE. All rights reserved. xiii

xiv Copyright © 2012 IEEE. All rights reserved.

Media Access Control (MAC) Service

a) Their semantics, primitive actions, and events; and

Copyright © 2012 IEEE. All rights reserved. 1

ISO/IEC 7498-1, Information technology—Open Systems Interconnection—Basic Reference Model: The

ISO/IEC 7498-3, Information technology—Open Systems Interconnection—Basic Reference Model:

ISO/IEC 10731, Information technology—Open Systems Interconnection—Basic Reference Model—

2 Copyright © 2012 IEEE. All rights reserved.

3.1 Basic reference model definitions

3.2 Service conventions definitions

4IEEE Standards Dictionary Online subscription is available at:

Copyright © 2012 IEEE. All rights reserved. 3

4. Acronyms and abbreviations

ISS Internal Sublayer Service

LAN Local Area Network