802 1Qbp-2014

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

Virtual Bridged Local Area Networks—
Amendment 22: Equal Cost Multiple Path (ECMP)
IEEE Computer Society
Sponsored by the
LAN/MAN Standards Committee
IEEE
3 Park Avenue IEEE Std 802.1Qbp™-2014
New York, NY 10016-5997 (Amendment to
USA IEEE Std 802.1Q™-2011)
7 April 2014
Authorized licensed use limited to: IEEE 802 attendee. Downloaded on September 22,2014 at 15:15:45 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 802.1Qbp™-2014
(Amendment to
IEEE Std 802.1Q™-2011)
IEEE Standard for


Sponsor
LAN/MAN Standards Committee
of the
IEEE Computer Society
Approved 27 March 2014

IEEE-SA Standards Board
Abstract: Routing algorithms and relay behavior supporting equal cost multipath forwarding in
shortest path bridged VLANs are specified in this amendment to IEEE Std 802.1Q.
Keywords: amendment, Bridged Local Area Networks, ECMP, Equal Cost Multiple Paths, IEEE
802.1Q™, IEEE 802.1Qbp™, LANs, local area networks, MAC Bridges, MANs, metropolitan area
networks, Shortest Path Bridging, Virtual Bridged Local Area Networks
The Institute of Electrical and Electronics Engineers, Inc.

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

All rights reserved. Published 7 April 2014. Printed in the United States of America.
IEEE and 802 are registered trademarks in the U.S. Patent & Trademark Office, owned by The Institute of Electrical and Electronics
Engineers, Incorporated.
PDF: ISBN 978-0-7381-9001-3 STD98585

Print: ISBN 978-0-7381-9002-0 STDPD98585
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.
Important Notices and Disclaimers Concerning IEEE Standards Documents
IEEE documents are made available for use subject to important notices and legal disclaimers. These notices
and disclaimers, or a reference to this page, appear in all standards and may be found under the heading
“Important Notice” or “Important Notices and Disclaimers Concerning IEEE Standards Documents.”
Notice and Disclaimer of Liability Concerning the Use of IEEE Standards

Documents
IEEE Standards documents (standards, recommended practices, and guides), both full-use and trial-use, are
developed within IEEE Societies and the Standards Coordinating Committees of the IEEE Standards
Association (“IEEE-SA”) Standards Board. IEEE (“the Institute”) develops its standards through a
consensus development process, approved by the American National Standards Institute (“ANSI”), which
brings together volunteers representing varied viewpoints and interests to achieve the final product.
Volunteers are not necessarily members of the Institute and participate without compensation from IEEE.
While IEEE administers the process and establishes rules to promote fairness in the consensus development
process, IEEE does not independently evaluate, test, or verify the accuracy of any of the information or the
soundness of any judgments contained in its standards.
IEEE does not warrant or represent the accuracy or content of the material contained in its standards, and
expressly disclaims all warranties (express, implied and statutory) not included in this or any other
document relating to the standard, including, but not limited to, the warranties of: merchantability; fitness
for a particular purpose; non-infringement; and quality, accuracy, effectiveness, currency, or completeness of
material. In addition, IEEE disclaims any and all conditions relating to: results; and workmanlike effort.
IEEE standards documents are supplied “AS IS” and “WITH ALL FAULTS.”
Use of an IEEE standard is wholly voluntary. The existence of an IEEE standard does not imply that there
are no other ways to produce, test, measure, purchase, market, or provide other goods and services related to
the scope of the IEEE standard. Furthermore, the viewpoint expressed at the time a standard is approved and
issued is subject to change brought about through developments in the state of the art and comments
received from users of the standard.
In publishing and making its standards available, IEEE is not suggesting or rendering professional or other
services for, or on behalf of, any person or entity nor is IEEE undertaking to perform any duty owed by any
other person or entity to another. Any person utilizing any IEEE Standards document, should rely upon his
or her own independent judgment in the exercise of reasonable care in any given circumstances or, as
appropriate, seek the advice of a competent professional in determining the appropriateness of a given IEEE
standard.
IN NO EVENT SHALL IEEE BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL,
EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO:
PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR
BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY,
WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR
OTHERWISE) ARISING IN ANY WAY OUT OF THE PUBLICATION, USE OF, OR RELIANCE UPON
ANY STANDARD, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE AND
REGARDLESS OF WHETHER SUCH DAMAGE WAS FORESEEABLE.
Copyright © 2014 IEEE. All rights reserved. iii
Translations
The IEEE consensus development process involves the review of documents in English only. In the event
that an IEEE standard is translated, only the English version published by IEEE should be considered the
approved IEEE standard.
Official statements
A statement, written or oral, that is not processed in accordance with the IEEE-SA Standards Board
Operations Manual shall not be considered or inferred to be the official position of IEEE or any of its
committees and shall not be considered to be, or be relied upon as, a formal position of IEEE. At lectures,
symposia, seminars, or educational courses, an individual presenting information on IEEE standards shall
make it clear that 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 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. For the same reason, IEEE does not
respond to interpretation requests. Any person who would like to participate in revisions to an IEEE
standard is welcome to join the relevant IEEE working group.
Comments on standards should be submitted to the following address:
Secretary, IEEE-SA Standards Board

445 Hoes Lane
Piscataway, NJ 08854 USA
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
IEEE draft and approved standards are copyrighted by IEEE under U.S. and international copyright laws.
They are made available by IEEE and are adopted for a wide variety of both public and private uses. These
include both use, by reference, in laws and regulations, and use in private self-regulation, standardization,
and the promotion of engineering practices and methods. By making these documents available for use and
adoption by public authorities and private users, IEEE does not waive any rights in copyright to the
documents.
iv Copyright © 2014 IEEE. All rights reserved.
Photocopies
Subject to payment of the appropriate fee, IEEE will grant users a limited, non-exclusive license to
photocopy portions of any individual standard for company or organizational internal use or individual, non-
commercial use only. To arrange for payment of licensing fees, please contact Copyright Clearance Center,
Customer Service, 222 Rosewood Drive, Danvers, MA 01923 USA; +1 978 750 8400. Permission to
photocopy portions of any individual standard for educational classroom use can also be obtained through
the Copyright Clearance Center.
Updating of IEEE Standards documents
Users of IEEE Standards documents should be aware that these documents may be superseded at any time
by the issuance of new editions or may be amended from time to time through the issuance of amendments,
corrigenda, or errata. An official IEEE document at any point in time consists of the current edition of the
document together with any amendments, corrigenda, or errata then in effect.
Every IEEE standard is subjected to review at least every 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 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://
ieeexplore.ieee.org/xpl/standards.jsp or contact IEEE at the address listed previously. For more information
about the IEEE SA or IEEE’s standards development process, visit the IEEE-SA Website at http://
standards.ieee.org.
Errata
Errata, if any, for all IEEE standards can be accessed on the IEEE-SA Website 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.
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 © 2014 IEEE. All rights reserved. v
Participants
At the time this amendment was submitted to the IEEE-SA Standards Board for approval, the IEEE 802.1
Working Group had the following membership:
Tony Jeffree, Chair

Glenn Parsons, Vice Chair
Stephen Haddock, Chair, Interworking Task Group
Ben Mack-Crane, Editor
Ting Ao Craig Gunther David Olsen

Christian Boiger Hitoshi Hayakawa Donald Pannell
Paul Bottorff Jeremy Hitt Karen Randall
Weiying Cheng Rahil Hussain Dan Romascanu
Diego Crupnicoff Mirko Jakovljevic Jessy Rouyer
Rodney Cummings Markus Jochim Panagiotis Saltsidis
Patrick Diamond Michael Johas Teener Rick Schell
Aboubacar Kader Diarra Hal Keen Michael Seaman
Janos Farkas Marcel Kiessling Daniel Sexton
Norman Finn Philippe Klein Johannes Specht
Andre Fredette Oliver Kleineberg Kevin Stanton
Geoffrey Garner Jeff Lynch Wilfried Steiner
Anoop Ghanwani James McIntosh Patricia Thaler
Franz Goetz John Messenger Jeremy Touve
Mark Gravel Anatoly Moldovansky Albert Tretter
Eric Gray Eric Multanen Karl Weber
Robert M. Grow Henry Muyshondt Yuehua Wei
The following members of the individual balloting committee voted on this standard. Balloters may have
voted for approval, disapproval, or abstention.
Wole Akpose Werner Hoelzl Robert Robinson
Thomas Alexander Noriyuki Ikeuchi Dan Romascanu
Richard Alfvin Akio Iso Jessy Rouyer
Butch Anton Atsushi Ito Peter Saunderson
Michael Bahr Raj Jain Michael Seaman
Nancy Bravin Tony Jeffree Shusaku Shimada
William Byrd Shinkyo Kaku Manikantan Srinivasan
Juan Carreon Piotr Karocki Thomas Starai
Keith Chow Stuart Kerry Walter Struppler
Charles Cook Bruce Kraemer Gary Stuebing
Wael Diab Geoff Ladwig Chandrasekaran Subramaniam
Patrick Diamond Shen Loh Patrik Sundstrom
Sourav Dutta Greg Luri Joseph Tardo
Donald Fedyk Thomas Mack-Crane Patricia Thaler
Yukihiro Fujimoto Elvis Maculuba Karl Weber
Gregory Gillooly Michael Newman Hung-Yu Wei
Eric Gray Nick S.A Nikjoo Yuehua Wei
Randall Groves Satoshi Obara Oren Yuen
Stephen Haddock Maximilian Riegel Daidi Zhong
vi Copyright © 2014 IEEE. All rights reserved.
When the IEEE-SA Standards Board approved this amendment on 27 March 2014, it had the following
membership:
John Kulick, Chair
Jon Walter Rosdahl, Vice Chair
Richard H. Hulett, Past Chair
Konstantinos Karachalios, Secretary
Peter Balma Michael Janezic Ron Peterson

Farooq Bari Jeffrey Katz Adrian Stephens
Ted Burse Joseph L. Koepfinger* Peter Sutherland
Clint Chaplain David J. Law Yatin Trivedi
Stephen Dukes Hung Ling Phil Winston
Jean-Phillippe Faure Oleg Logvinov Don Wright
Gary Hoffman Ted Olsen Yu Yuan
Glenn Parsons
*Member Emeritus
Also included are the following nonvoting IEEE-SA Standards Board liaisons:
Richard DeBlasio, DOE Representative

Michael Janezic, NIST Representative
Catherine Berger
Senior Program Manager, IEEE-SA Content Publishing
Kathryn Bennett
Program Manager, IEEE-SA Technical Community
Copyright © 2014 IEEE. All rights reserved. vii
Introduction
This introduction is not part of IEEE Std 802.1Qbp-2014, IEEE Standard for Local and metropolitan area networks—
Media Access Control (MAC) Bridges and Virtual Bridged Local Area Networks—Amendment 22: Equal Cost Multiple
Path (ECMP).
This amendment to IEEE Std 802.1Q-2011 specifies extensions to Shortest Path Bridging MAC Mode
(SPBM) to support utilizing multiple next hop choices for frames within a single service. A new tag is
defined to carry a flow hash value and an ECMP algorithm uses the flow hash value in selecting a next hop
port from among a set of equal cost alternatives so that frames belonging to the same data flow take the same
path.
viii Copyright © 2014 IEEE. All rights reserved.
Contents
1.Overview....................................................................................................................................................... 2
1.3 Introduction.............................................................................................................................. 2
3.Definitions .................................................................................................................................................... 3
4.Abbreviations................................................................................................................................................ 4
5.Conformance................................................................................................................................................. 5
5.4 VLAN-aware Bridge component requirements ....................................................................... 5
5.6 S-VLAN component conformance .......................................................................................... 6
5.8 B-component conformance...................................................................................................... 6
6.Support of the MAC Service ........................................................................................................................ 7

6.5 Quality of service maintenance................................................................................................ 7
6.8 Enhanced Internal Sublayer Service ........................................................................................ 7
8.Principles of bridge operation....................................................................................................................... 9

8.6 The Forwarding Process .......................................................................................................... 9
8.8 The Filtering Database............................................................................................................. 9
12.Bridge management ...................................................................................................................................11

12.6 Forwarding process.................................................................................................................11
12.14 CFM entities .......................................................................................................................... 11
12.16 Backbone Edge Bridge management ..................................................................................... 13
12.25 Shortest Path Bridging managed objects ............................................................................... 14
17.Management Information Base (MIB) ..................................................................................................... 20

17.2 Structure of the MIB .............................................................................................................. 20
17.3 Relationship to other MIBs.................................................................................................... 21
17.4 Security considerations .......................................................................................................... 22
17.7 MIB modules ......................................................................................................................... 22
19.Connectivity Fault Management Entity operation.................................................................................... 71

19.3 MIP Half Function ................................................................................................................. 71
19.4 Maintenance Point addressing ............................................................................................... 71
20.Connectivity Fault Management protocols............................................................................................... 73

20.1 Continuity Check protocol..................................................................................................... 73
20.2 Loopback protocol ................................................................................................................. 73
20.3 Linktrace protocol.................................................................................................................. 74
20.4 Connectivity Fault Management state machines ................................................................... 76
20.10 MEP Continuity Check Initiator variables............................................................................. 77
20.11 MEP Continuity Check Initiator procedures ......................................................................... 78
20.12 MEP Continuity Check Initiator state machine ..................................................................... 79
20.17 MEP Continuity Check Receiver procedures ........................................................................ 79
20.19 Remote MEP variables .......................................................................................................... 79
20.20 Remote MEP state machine ................................................................................................... 81
20.28 MP Loopback Responder procedures .................................................................................... 81
Copyright © 2014 IEEE. All rights reserved. ix
20.31 MEP Loopback Initiator transmit procedures........................................................................ 82
20.42 MEP Linktrace Initiator procedures ...................................................................................... 83
20.47 LTM Receiver procedures ..................................................................................................... 84
22.Connectivity Fault Management in systems ............................................................................................. 86

22.2 Maintenance Entity creation .................................................................................................. 86
27.Shortest Path Bridging (SPB) ................................................................................................................... 88

27.1 Protocol design requirements................................................................................................. 90
27.8 Calculating SPT connectivity ................................................................................................ 91
27.15 SPBM Group Addressing ...................................................................................................... 92
27.17 Equal cost shortest paths, ECTs, and load spreading ............................................................ 94
27.18 Connectivity Fault Management for SPBM .......................................................................... 94
28.ISIS-SPB Link State Protocol................................................................................................................... 98

28.5 Symmetric shortest path tie breaking..................................................................................... 98
28.8 Predefined ECT Algorithm details ........................................................................................ 98
28.12 ISIS-SPB TLVs...................................................................................................................... 98
44.Equal Cost Multiple Paths ...................................................................................................................... 102

44.1 SPBM ECMP ....................................................................................................................... 102
44.2 Support for Flow Filtering ................................................................................................... 105
Annex A (normative)PICS proforma—Bridge implementations ................................................................ 112
x Copyright © 2014 IEEE. All rights reserved.
List of figures
Figure 12-3 SPB Management objects ................................................................................................ 15

Figure 19-3 MIP Half Function ........................................................................................................... 71
Figure 20-1 MEP state machines—overview and relationships.......................................................... 76
Figure 20-2 MEP Continuity Check Initiator state machine ............................................................... 79
Figure 20-5 Remote MEP state machine ............................................................................................. 81
Figure 22-9 Creating MEPs and MIPs................................................................................................. 87
Figure 27-2 SPBM Group MAC Address—general format ................................................................ 93
Figure 27-3 SPBM Group MAC Addresses—source rooted SPTused by this standard ..................... 93
Figure 27-4 SPBM Group MAC Addresses—shared tree................................................................... 93
Figure 27-5 SPBM MEP placement in a CBP ..................................................................................... 96
Figure 28-6 ECMP ECT-ALGORITHM sub-TLV ............................................................................. 99
Figure 28-7 SPBM Service Identifier and Unicast Address sub-TLV .............................................. 100
Figure 44-8 Flow FilteringTCI format............................................................................................... 106
Figure 44-9 SPBM VID MEP and ECMP path MEP placement in a CBP ....................................... 110
Copyright © 2014 IEEE. All rights reserved. xi
List of tables
Table 17-1 Structure of the MIB modules .............................................................................................. 20

Table 17-25 IEEE8021-SPB MIB structure and relationship to this standard.......................................... 20
Table 17-27 IEEE8021-ECMP-MIB structure and relationship to this standard...................................... 21
Table 22-1 MEP creation ........................................................................................................................ 86
Table 44-2 ECMP ECT-ALGORITHM values .................................................................................... 105
Table 44-3 F-TAG EtherType............................................................................................................... 106
xii Copyright © 2014 IEEE. All rights reserved.
IEEE Standard for

[This amendment is based on IEEE Std 802.1Q™-2011 as amended by IEEE Std 802.1Qbe™, IEEE Std
802.1Qbc™, IEEE Std 802.1Qbb™, IEEE Std 802.1Qaz™, IEEE Std 802.1Qbf™, IEEE Std 802.1aq™, and
IEEE Std 802.1Qbg™.]
NOTE—The editing instructions contained in this amendment define how to merge the material contained therein into
the existing base standard and its amendments to form the comprehensive standard.
The editing instructions are shown in bold italic. Four editing instructions are used: change, delete, insert, and replace.
Change is used to make corrections in existing text or tables. The editing instruction specifies the location of the change
and describes what is being changed by using strikethrough (to remove old material) and underscore (to add new
material). Delete removes existing material. Insert adds new material without disturbing the existing material. Deletions
and insertions may require renumbering. If so, renumbering instructions are given in the editing instruction. Replace is
used to make changes in figures or equations by removing the existing figure or equation and replacing it with a new
one. Editing instructions, change markings, and this NOTE will not be carried over into future editions because the
changes will be incorporated into the base standard.
IIMPORTANT NOTICE: IEEE Standards documents are not intended to ensure safety, security, 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 applica-
ble 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/disclaim-
ers.html.
Copyright © 2014 IEEE. All rights reserved. 1
IEEE LOCAL AND METROPOLITAN AREA NETWORKS
Std 802.1Qbp-2014
1. Overview
1.3 Introduction
Change the item following the paragraph beginning “This standard specifies shortest path
bridging” that begins “Requires that active topologies” as shown:
bj) Requires that active topologies calculated by spanning tree protocols and Shortest Path Tree (SPT)
protocols be stable, predictable, and reproducible to , reverse path congruent and unicast-multicast
congruent to: permit learning of station location from the source addresses of all frames, simplify the
detection and management of faults, and maintain the characteristics of the MAC Service provided.
Insert the following item and note after the item above, renumbering the list accordingly and
numbering the NOTE appropriately:
bk) Requires, except in the case of SPB using ECMP, active topologies that are reverse path congruent
and unicast-multicast congruent to permit learning of station location from the source addresses of
all frames and simplify the detection and management of faults.
NOTE 5—Equal Cost Multiple Paths operation does not provide (nor does this standard attempt to define for ECMP
VLANs) reverse path congruence and unicast-multicast congruence as these concepts cease to have utility in an ECMP
context.
Insert the following items at the end of the list, numbering appropriately:
bl) Specifies load spreading by distributing unicast traffic over the set of available equal cost paths and
assigning multicast traffic flows to a variety of trees.
bm) Specifies a Flow Filtering Tag containing a flow hash used in unicast ECMP traffic distribution and
a time-to-live (TTL) field used to mitigate the effects of traffic loops resulting from transient
conditions or control software errors or faults.
2 Copyright © 2014 IEEE. All rights reserved.
AMENDMENT 22: EQUAL COST MULTIPLE PATHS (ECMP) IEEE
Std 802.1Qbp-2014
3. Definitions
Insert the following definitions into Clause 3 in alphabetical order, number them appropriately,
and renumber the remaining definitions in Clause 3 accordingly:
3.1 ECMP path MA: A maintenance association that monitors a set, which can be complete, of equal
connectivity paths between two specific end points as constructed by ECMP.
3.2 Equal Cost Multiple Paths (ECMP): ECMP enables the use of multiple possible next hop choices for
frames within a single service in Shortest Path Bridging MAC Mode (SPBM) networks.
3.3 flow filtering tag (F-TAG): A tag with a Tag Protocol Identification value allocated for “IEEE 802.1Q
Flow Filtering Tag EtherType.”
3.4 flow hash: An arbitrary value that serves to distinguish flows that may be subject to different treatment
in a bridged network, for example, flows subject to independent treatment by ECMP.
3.5 SPBM MA: A maintenance association for monitoring and diagnosing connectivity associated with a
VID assigned to the SPBM MSTID. There are three types of SPBM MA—SPBM VID MAs, SPBM path
MAs, and SPBM group MAs (27.18.1).
3.6 SPBM VID: A VID associated with the SPBM-MSTID value of the Multiple Spanning Tree Instance
Identifier (MSTID) in the MST Configuration Table.
Std 802.1Qbp-2014
4. Abbreviations
Add the following abbreviations to Clause 4 in the appropriate location:

ECMP Equal Cost Multiple Paths
F-TAG flow filtering tag
Std 802.1Qbp-2014
5. Conformance
5.4 VLAN-aware Bridge component requirements
Change 5.4.5 as shown:
5.4.5 Shortest Path Bridging operation (optional)
A VLAN-aware Bridge implementation that conforms to the provisions of this standard for SPB in
Clause 27 shall:
a) Support SPB, in either VID mode (SPBV) or MAC mode (SPBM), as specified in Clause 27;
b) Support the IS-IS Link State Protocol with procedures to ensure Loop Prevention as specified in
Clause 28 to provide SPT computation for shortest path bridging;
c) Encode, decode, and validate SPT BPDUs for the Agreement Protocol (13.17) and support
Agreement Protocol logic in IS-IS as specified in Clause 28;
d) Support at least three FIDs;
e) Support the management functionality specified in Clause 12.
A VLAN-aware Bridge implementation in conformance to the provisions of this standard for SPB in
Clause 27 may:
f) Support both SPB VID mode (SPBV) and SPB MAC mode (SPBM);
g) Support the SPB Management Information Base (MIB) module defined in 17.7.19;
h) Support both the VID Translation Table and Egress VID translation table (6.9) on SPBV Boundary
Ports.;
i) Support the CFM modifications for SPBM as specified in Clause 20 and summarized in 27.18;
j) Support Equal Cost Multiple Paths operation of SPBM (5.4.5.1);
k) Support Equal Cost Multiple Paths operation of SPBM with flow filtering (5.4.5.2).
5.4.5.1 SPBM Equal Cost Multiple Paths operation (optional)
An SPBM capable VLAN-aware bridge implementation that conforms to the provisions of this standard for
ECMP in 44.1 shall:
a) Support SPBM ECMP as specified in 44.1;

b) Support the management functionality specified in Clause 12.
ECMP may:
c) Support the IEEE8021-ECMP-MIB module objects ieee8021EcmpEctStaticTable and

ieee8021EcmpTopSrvTable defined in 17.7.21.
5.4.5.2 SPBM Equal Cost Multiple Paths operation with flow filtering (optional)
ECMP with flow filtering shall:
a) Support SPBM ECMP as specified in 44.1;

b) Support flow filtering as specified in 44.2, including inserting, modifying, and removing F-TAGs
from relayed frames as required by the applicable values in the Flow Filtering Control Table for each
port;
Std 802.1Qbp-2014
c) Support the management functionality specified in Clause 12.
ECMP with flow filtering may:
d) Support the CFM modifications for ECMP using flow filtering as specified in Clause 20 and
summarized in 44.2.5;
e) Support the IEEE8021-ECMP-MIB module defined in 17.7.21.
5.6 S-VLAN component conformance
Insert new subclause 5.6.4 after 5.6.3:
5.6.4 S-VLAN component requirements for ECMP with flow filtering
An S-VLAN component implementation that conforms to the provisions of this standard for ECMP with
flow filtering shall
a) Support F-TAG processing as specified in 44.2.2 on each PNP.
5.8 B-component conformance
Insert new subclause 5.8.4 after 5.8.3:
5.8.4 B-component requirements for ECMP with flow filtering
A B-component implementation that conforms to the provisions of this standard for ECMP with flow
filtering shall
a) Support F-TAG processing as specified in 44.2.2 on each CBP and PNP.
Std 802.1Qbp-2014
6. Support of the MAC Service
6.5 Quality of service maintenance
6.5.3 Frame misordering
The MAC Service (9.2 of ISO/IEC 15802-1) permits a negligible rate of reordering of frames with a given
priority for a given combination of destination address and, source address and flow hash, if present,
transmitted on a given VLAN. MA_UNITDATA.indication service primitives corresponding to
MA_UNITDATA.request primitives, with the same requested priority and for the same combination of
VLAN classification, destination address, and source address and flow hash, if present, are received in the
same order as the request primitives were processed.
NOTE 1—The operation of the Forwarding Process in Bridges (8.6) is such that the frame-ordering characteristics of the
MAC Service are preserved.
Where Bridges in a network are capable of connecting the individual MACs in such a way that multiple
paths between any source station–destination station pairs exist, the operation of a protocol is required to
ensure that a single path is used for every sequence of frames whose order must be maintained.
NOTE 2—Where STP is in use (see Clause 8 of IEEE Std 802.1D, 1998 Edition), frame misordering cannot occur
during normal operation. When a protocol that is capable of rapid reconfiguration after network component failure, such
as RSTP, MSTP, or SPB is used, there is an increased probability that frames that are in transit through the network will
be misordered, because a Bridge can buffer frames awaiting transmission through its Ports. The probability of
misordering occurring as a result of such an event is dependent on implementation choices and is associated with
reconfiguration events. Some known LAN protocols, for example, LLC Type 2, are sensitive to frame misordering and
duplication; in order to allow Bridges that support RSTP to be used in environments where sensitive protocols are in use,
the forceVersion parameter (13.7.2) can be used to force a Bridge that supports RSTP to operate in an STP-compatible
manner. A more detailed discussion of misordering in RSTP can be found in K.3 of IEEE Std 802.1D-2004.
6.8 Enhanced Internal Sublayer Service
6.8.1 Service primitives
The unit-data primitives that define this service are
EM_UNITDATA.indication (
destination_address,
source_address,
mac_service_data_unit,
priority,
drop_eligible,
vlan_identifier,
frame_check_sequence,
service_access_point_identifier,
connection_identifier,
flow_hash,
time_to_live
)
Std 802.1Qbp-2014
EM_UNITDATA.request (
destination_address,
source_address,
mac_service_data_unit,
priority,
drop_eligible,
vlan_identifier,
frame_check_sequence,
service_access_point_identifier,
connection_identifier,
flow_hash,
time_to_live
)
The destination_address, source_address, mac_service_data_unit, priority, drop_eligible,

service_access_point_identifier, connection_identifier, and frame_check_sequence parameters are as
defined for the ISS.
NOTE 1—Some of the functions supporting the EISS may result in changes to the mac_service_data_unit or other
parameters used to construct a frame. The original FCS associated with a frame is invalidated if there are changes to any
fields of the frame, if fields are added or removed, or if bit ordering or other aspects of the frame encoding have changed.
An invalid FCS is signaled in the EISS by an unspecified value in the frame_check_sequence parameter. This signals the
need for the FCS to be regenerated according to the normal procedures for the transmitting MAC. The options for
regenerating the FCS under these circumstances are discussed in Annex F of IEEE Std 802.1D-2004.
The vlan_identifier parameter carries the VLAN identifier (VID).
The flow_hash parameter is either null or carries a value that may be used by the forwarding process in
selecting a single forwarding port from a set of available forwarding ports (8.6.3). Transmission order is
maintained for all frames from a source to a destination with the same flow hash value. A flow hash value
may be retrieved from an F-TAG or otherwise derived from the contents of a service primitive (44.2.2). A
flow hash is not required by the MAC Relay Entity, and successful filtering can be provided without this
additional information; however, it is required for flow filtering services supported by SPBM with ECMP.
Any protocol entity in the interface stack that does not specify use of the flow_hash assigns the flow_hash
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 flow_hash on associated requests made (or
indications generated) by the protocol entity.
The time_to_live parameter is either null or carries a value that may be used to filter frames that have
reached their limit of permitted network hops. A time_to_live value may be retrieved from an F-TAG in the
mac_service_data_unit and processed as described in 44.2.2. Any protocol entity in the interface stack that
does not specify use of the time_to_live assigns the time_to_live 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 time_to_live on associated requests made (or indications generated) by the protocol entity.
Std 802.1Qbp-2014
8. Principles of bridge operation
8.6 The Forwarding Process
8.6.3 Frame filtering
Change the initial text in 8.6.3 as shown:
The Forwarding Process takes filtering decisions, i.e., reduces the set of potential transmission Ports (8.6.1),
for each received frame on the basis of
a) Destination MAC Address;

b) VID;
c) Flow hash;
d) The information contained in the Filtering Database for that MAC Address and VID;
e) The default Group filtering behavior for the potential transmission Port (8.8.6);
in accordance with the definition of the Filtering Database entry types (8.8.1, 8.8.3, and 8.8.4). The required
behavior is summarized in 8.8.6, 8.8.9, Table 8-7, Table 8-8, and Table 8-9. Flow hash is only applicable on
Bridges supporting flow filtering (44.2).
8.6.6 Queuing frames
Change the initial text in 8.6.6 as shown:
The Forwarding Process provides storage for queued frames, awaiting an opportunity to submit these for
transmission. The order of frames received on the same Bridge Port shall be preserved for
a) unicast frames with a given VID, priority, flow hash, and destination address and source address
combination;
b) multicast frames with a given VID, priority, flow hash, and destination address.
Flow hash is only applicable on Bridges supporting flow filtering (44.2).
8.8 The Filtering Database
8.8.3 Dynamic Filtering Entries
A Dynamic Filtering Entry specifies
a) An individual MAC Address;

b) The FID, an identifier assigned by the MAC Bridge (8.8.8) to identify a set of VIDs for which no
more than one Dynamic Filtering Entry can exist for any individual MAC Address;
NOTE 1—An FID identifies a set of VIDs among which Shared VLAN Learning (3.165) takes place. Any pair of FIDs
identifies two sets of VIDs between which Independent VLAN Learning (3.75) takes place. The allocation of FIDs by a
Bridge is described in 8.8.8.
c) A Port Map specifying forwarding for the destination MAC Address and FID to a single Port or, in
the case of ECMP with flow filtering (44.1, 44.2), to a set of Ports from which one must be selected.
Std 802.1Qbp-2014
NOTE 2—This is equivalent to specifying a single port number; hence, this specification is directly equivalent to the
specification of dynamic entries in IEEE Std 802.1D-1993 [B9].
The Port Map may contain a connection_identifier (8.8.12) for each outbound Port.
Dynamic Filtering Entries can be created, updated, and removed by the Learning Process (8.7). They shall
be automatically removed after a specified time, the Ageing Time (8.7.3), has elapsed since the entry was
created or last updated.
Dynamic Filtering Entries can also be created and updated by SPB (Clause 27). ISIS-SPB (Clause 28)
refreshes these entries, so they are not aged out by the normal operation of the Learning Process. These
entries are used by SPBM (Clause 27) to support both unicast loop mitigation (6.5.4.2) and multicast loop
prevention (6.5.4.1) for active topology enforcement (8.6.1), as well as to locate end stations. Entries
indicating a set of potential forwarding ports from which one must be selected are used by ECMP with flow
filtering. These entries are updated SPBV updates Dynamic Filtering Entries by the normal Learning
Process for SPBV, but they maycould also be controlled by ISIS-SPB. This allows entries for the higher
layer entities in a bridge (see Figure 8-11) to be populated rapidly after any topology change.
No more than one Dynamic Filtering Entry shall be created in the Filtering Database for a given
combination of MAC Address and FID. Dynamic Filtering Entries cannot be created or updated by
management.
NOTE 3—Dynamic Filtering Entries may be read by management (Clause 12). The FID is represented in the
management Read operation by any one of the VIDs that it represents. For a given VID, the set of VIDs that share the
same FID may also be determined by management.
Std 802.1Qbp-2014
12. Bridge management
12.6 Forwarding process
12.6.1 The Port Counters
12.6.1.1 Read forwarding port counters
12.6.1.1.3 Outputs
Insert item i) at the end of 12.6.1.1.3:

i) If flow filtering is supported (44.2), Discard TTL Expired—count of frames discarded because they
were received with the TTL field expired.
12.14 CFM entities
12.14.5 Maintenance Domain managed object
12.14.5.3 Create Maintenance Association managed object
12.14.5.3.2 Inputs
Change item c) in 12.14.5.3.2 as shown:

c) The list of VIDs, the I-SID, the TE-SID, or the SEG-ID monitored by this MA, or 0, if the MA is not
attached to any VID, I-SID, TE-SID, or SEG-ID. In the case that a list of VIDs is specified, the first
VID in the list is the MA’s Primary VID (default none). The specification of I-SID is allowed only in
the case of I- or B- components. The TE-SID is allowed only in the case that PBB-TE or SPBM is
supported. The SEG-ID is allowed only in the case that IPS is supported.
Change item a)7) in 12.14.5.3.3 as shown:
12.14.5.3.3 Outputs
7) Operation rejected because the TE-SID value specified does not correspond to a valid TESI or
set of SPBM path endpoints;
12.14.7 Maintenance association End Point managed object
12.14.7.1 Read Maintenance association End Point managed object
12.14.7.1.3 Outputs
Insert the following sentence at the end of item d) in 12.14.7.1.3:

In the case of an SPB associated MEP, the Primary VID is not writable but is always associated with the
value of the SPVID for the node on which the MEP is configured (for SPBV) or the Base VID (for SPBM).
Insert a new item at the end of the list in 12.14.7.1.3 as shown, numbering as appropriate:
al) (writable) Only applicable for ECMP path MEPs, a list of flow hash values to be used in a path
testing cycle (20.10.5).
Std 802.1Qbp-2014
12.14.7.3 Transmit Loopback Messages
Change 12.14.7.3.2 as shown:
12.14.7.3.2 Inputs
a) A reference to a particular Maintenance association End Point managed object (12.14.7);

b) An indication of the destinationtarget MAC address for LBMs transmitted by the MEP (20.31.1):
1) The MEPID of a MEP in that MA; or
2) An Individual destination MAC address; or
3) For PBB-TE and SPBM VID MEPs, an Individual MAC address to be used as the MIP MAC
address in a PBB-TE MIP TLV;
c) The number of LBMs to be transmitted (default 1);
d) An arbitrary amount of data to be included in a Data TLV, along with an indication whether the Data
TLV is to be included (20.31.1) (default no Data TLV); and
e) The priority and drop_eligible parameters to be used in the transmitted LBMs [default is CCM
priority item h) in 12.14.7.1.3, drop_eligible false];
f) In the case of a PBB-TE MEP, the Reverse VID to be used in the associated PBB-TE MIP TLV
(21.7.5). The parameter is not required in the case of PBB-TE MEPs associated with point-to-point
TESIs or if the b2)b3) entry is a MAC address corresponding to an entry in the ESP-DA field of any
of the MA’s ESPs;
g) In the case of an SPBM VID MEP, an individual or group MAC address to be used as the
destination_address for the LBM primitive. If no value is provided the group MAC address for the
SPBM default I-SID (Table 9-3, Figure 27-3) is used; and
h) In the case of ECMP with flow filtering, a flow hash value if the destination address is an individual
address.
12.14.7.4 Transmit Linktrace Message
12.14.7.4.2 Inputs
a) A reference to a particular Maintenance association End Point managed object (12.14.7);

b) The Flags field for LTMs transmitted by the MEP (20.42.1);
c) An indication of the Target MAC Address field to be transmitted, either:
1) The MEPID of another MEP in the same MA; or
2) An Individual destination MAC address;
d) An initial value for the LTM TTL field (21.8.4). Default value, if not specified, is 64;
e) In the case of a PBB-TE MEP, the Reverse VID to be used in the associated PBB-TE MIP TLV
(21.7.5). The parameter is not required in the case of PBB-TE MEPs associated with point-to-point
TESIs;
f) In the case of an SPBM VID MEP, an individual or group MAC address to be used as the
destination_address for the LTM primitive. If no value is provided the group MAC address for the
SPBM default I-SID (Table 9-3, Figure 27-3) is used;
g) In the case of ECMP with flow filtering, a flow hash value if the destination address is an Individual
address.
Std 802.1Qbp-2014
12.14.7.6 Read MEP Database
12.14.7.6.3 Outputs
Change item e) in 12.14.7.6.3 as shown:

e) A Boolean value indicating the state of the RDI bit in the last received CCM (true for RDI = 1), or
false, if none has been received (20.19.2). In the case of an ECMP path MEP, an array of Boolean
values indicating the value of rMEPlastRDI[i] for i=0..(Npaths-1) indicating the RDI values in the
last CCMs received in each path test cycle period. These values are true for any RDI = 1 or false if
all RDI = 0 or if no CCM has ever been received (20.19.2);
12.16 Backbone Edge Bridge management
12.16.5 CBP Configuration managed object
The CBP Configuration managed object includes the following:
a) A Backbone Service Instance table (6.11)

b) A Flow Filtering Control Table (44.2.2)
Item b) is only applicable on BEBs supporting ECMP with flow filtering.
The management operations that can be performed are as follows:
c) Read Backbone Service Instance table entry (12.16.5.1)

d) Set Backbone Service Instance table entry (12.16.5.2)
e) TESI assignment managed object (12.16.5.3)
f) Read Flow Filtering Control Table entry (12.16.5.4)
g) Set Flow Filtering Control Table entry (12.16.5.5)
12.16.5.2 Set Backbone Service Instance table entry
12.16.5.2.3 Outputs
a) Operation status—this takes one of the following values:

1) Operation rejected because the ComponentID and Port Number do not identify a valid CBP.
2) Operation rejected because the B-VID is assigned to ECMP with flow filtering (12.25.4.1,
Table 44-1) and the Bridge does not support flow filtering.
3) Operation accepted.
Insert 12.16.5.4 and 12.16.5.5 after 12.16.5.3:
12.16.5.4 Read Flow Filtering Control Table entry
12.16.5.4.1 Purpose
BEBs supporting ECMP with flow filtering shall implement the read Flow Filtering Control Table entry
function to allow reading the Flow Filtering Control Table entries in the CBP configuration managed object.
Std 802.1Qbp-2014
12.16.5.4.2 Inputs
a) ComponentID—the number identifying the bridge component associated with this port.
b) Port Number —that component’s Port Number for the Bridge Port.
c) VID —identifying a B-VID.
12.16.5.4.3 Outputs

1) Operation rejected because the ComponentID and Port Number do not identify a valid CBP;
2) Operation rejected because the CBP does not support F-TAG processing;
b) ComponentID—the number identifying the bridge component associated with this port.
c) Port Number—that component’s Port Number for the Bridge Port.
d) VID—the identifier of a B-VLAN.
e) Flow Filtering—indicates whether or not flow filtering behavior is enabled on the port for the VID
(enabled/disabled).
f) Flow Hash Generation—indicates whether or not flow hash generation is enabled on the port for the
VID (enabled/disabled).
g) TTL Value—the initial TTL value for frames entering the flow filtering SPT Domain (1..63).
12.16.5.5 Set Flow Filtering Control Table entry
12.16.5.5.1 Purpose
BEBs supporting ECMP with flow filtering shall implement the set Flow Filtering Control Table entry
function to allow configuration of the initial TTL value for frames entering an SPT Domain. This
information is persistent over power-up or reboot.
12.16.5.5.2 Inputs
a) ComponentID—the number identifying the bridge component associated with this port.
b) Port Number—that component’s Port Number for the Bridge Port.
c) VID—12-bit VID.
d) TTL Value—the initial TTL value for frames entering the SPT Domain, Integer in range 1–63. The
default value is 8.
NOTE—The Flow Filtering and Flow Hash Generation fields in the Flow Filtering Control Table are controlled by
ISIS-SPB (28.8.2) and therefore are not settable by management.
12.16.5.5.3 Outputs

1) Operation rejected because the ComponentID and Port Number do not identify a valid CBP;
2) Operation rejected because the CBP does not support F-TAG processing;
12.25 Shortest Path Bridging managed objects
Change 12.25 as shown, replacing Figure 12-3:
The Shortest Path Bridging managed objects model operations that create, modify, delete, or enquire about
the configuration and the operation of an SPT Bridge and the region in which it is operating. These managed
Std 802.1Qbp-2014
objects model only behaviors unique to Shortest Path Bridging. Figure 12-3 illustrates the hierarchical
relationships among the various SPB managed objects.
SPB System MO (Other ISIS Instances)

SPB System MO (Single ISIS Instance) (12.25.1)
SPB MTID Static MO ( MTID = 0) SPB Topology

(12.25.2) Instance
Dynamic MO
SPB Topology ( MTID = 0 )
Node Table MO (12.25.9) (12.25.3)
SPB Topology SPB Topology Dynamic Topology
Edge Table ECT Table Digest Information
(12.25.11) (12.25.10)
SPBM Topology SPBV Topology For all MTID in an

Service Table MO Service Table MO Instance
(12.25.12) (12.25.13)
SPB Adjacency SPB ECT Static MCID Not shown

Static Entry MO Entry MO Configures an
(12.25.6) (12.25.4) SPT Domain.
SPB Adjacency SPB ECT Dynamic SPB Objects
Dynamic Entry MO Entry MO operate within the
(12.25.7) (12.25.5) SPB Domain
Per Port Per Algorithm
SPBM BSI ECMP ECT

Static Entry MO Static Entry MO
(12.25.8) (12.25.14)
Per Service Per Tie-Break
Endpoint Mask
Per MTID
Figure 12-3—SPB Management objects
IS-IS provides a logical topology instance and within each instance the SPT Domain defines a set of
managed objects. The following are the managed objects in an SPT Bridge:
a) The SPB System managed object (12.25.1).

b) The SPB MTID (Clause 3) Static managed object (12.25.2).
c) The SPB Topology Instance Dynamic managed object (12.25.3).
d) The SPB ECT Static Entry managed object (12.25.4).
e) The SPB ECT Dynamic Entry managed object (12.25.5).
f) The SPB Adjacency Static Entry managed object (12.25.6).
g) The SPB Adjacency Dynamic Entry managed object (12.25.7).
h) The SPBM BSI Static Entry managed object (12.25.8).
i) The SPB Topology Node Table managed object (12.25.9).
j) The SPB Topology ECT Table managed object (12.25.10).
k) The SPB Topology Edge Table managed object (12.25.11).
Std 802.1Qbp-2014
l) The SPBM Topology Service Table managed object (12.25.12).

m) The SPBV Topology Service Table managed object (12.25.13).
n) The ECMP ECT Static Entry managed object (12.25.14).
12.25.1 The SPB System managed object
12.25.1.3 Read SPB System managed object
12.25.1.3.3 Outputs
Change item e) in 12.25.1.3.3 as shown:

e) The Bridge Priority (13.26.313.26.2). The value used by SPB is set in the CIST Bridge Protocol
Parameters (12.8.1.3).
12.25.4 The SPB ECT Static Entry managed object
12.25.4.1 Create SPB ECT Static Entry managed object
12.25.4.1.2 Inputs

a) A Topology Index value that uniquely identifies a topology instance.
b) A Base VID. This VID must have been assigned either to the reserved MSTID value 0xFFC for SPT
bridges in SPBM operation, or to the reserved MSTID value 0xFFD for SPBV (27.4) in the FID to
MSTI Allocation table (12.12.2.2).
c) The identifier of the Equal Cost Tree algorithm (ECT-ALGORITHM) to be used for this Base VID
(Table 28-1, Table 44-1). The Default is the LowPATHID 00-80-C2-01. (28.8).
d) The pre-configured value of the SPVID assigned to this bridge if operating in SPBV mode. This
input is ignored if auto-allocated is selected [item c) in 12.25.1.2.2]. This VID value must have been
assigned to the reserved MSTID value 0xFFF (27.4) in the FID to MSTI Allocation Managed Object
(12.12.2.2).
Insert new subclause 12.25.8 after 12.25.7, renumbering subsequent subclauses accordingly:
12.25.8 The SPBM BSI Static Entry managed object
There is one SPBM BSI Static Entry managed object for each I-SID assigned to an SPBM VID on a CBP. It
contains the SPBM configuration parameters for an I-SID. It is persistent over reboot. The management
operations that can be performed on the SPBM BSI Static Entry managed object are as follows:
a) Write SPBM BSI Static Entry managed object (12.25.8.1).

b) Read SPBM BSI Static Entry managed object (12.25.8.2).
12.25.8.1 Write SPBM BSI Static Entry managed object
12.25.8.1.1 Purpose
To configure an SPBM BSI Static Entry managed object for an I-SID assigned to an SPBM VID on a CBP.
12.25.8.1.2 Inputs
a) A Topology Index value which uniquely identifies a topology instance.

b) The system interface index of a Customer Backbone Port.
Std 802.1Qbp-2014
c) The I-SID identifying the backbone service instance.

d) A B-VID associated with this I-SID. There may be more than one object for a given I-SID, allowing
it to be associated with multiple B-VIDs. This B-VID may differ from the B-VID specified in
12.16.5.2 that governs the VID assigned to the I-SID at the CBP; for example, to allow changing
ISIS-SPB parameters when moving an I-SID from one B-VID to another. The B-VID to I-SID
association in this managed object is advertised in ISIS-SPB so that forwarding state for the
association is installed throughout the SPT domain, in addition to CBP state installed by 12.16.5.2. It
is only the B-VID defined in 12.16.5.2 on which a CBP transmits; however, a CBP must receive
from any B-VID with which its I-SID has an association.
e) Multicast transmit indication bit [item e) in 28.12.10].
f) Multicast receive indication bit [item f) in 28.12.10].
g) Shared tree transmit indication bit [item g) in 28.12.10].
h) Tie-Break Mask value [item h) in 28.12.10].
12.25.8.1.3 Outputs
a) Operation status. This takes one of the following values:

1) Operation rejected because the Topology Index value is not defined;
2) Operation rejected because the identified port does not exist or is not a CBP;
3) Operation rejected because the I-SID is not assigned to an SPBM VID;
12.25.8.2 Read SPBM BSI Static Entry managed object
12.25.8.2.1 Purpose
To read back the parameters of an SPBM BSI Static Entry managed object for an I-SID assigned to an
SPBM VID on a CBP.
12.25.8.2.2 Inputs

b) The system interface index of a Customer Backbone Port. The value of zero is a wildcard indicating
information, for any interface on which SPB operation is enabled, is requested.
c) An I-SID identifying a backbone service instance. The value 0xFFFFFF is a wildcard indicating that
information on all I-SIDs on the specified port(s) is requested.
d) A B-VID associated with this I-SID. The value 4095 is a wildcard indicating that information for
any B-VID associated with the specified I-SID(s) is requested.
12.25.8.2.3 Outputs
a) a) Operation status—this takes one of the following values:

2) Operation rejected because the identified port does not exist or is not a CBP;
3) Operation rejected because the I-SID is not assigned to an SPBM VID;
b) The Topology Index value that uniquely identifies this topology instance.
c) The system interface index of the port.
d) The I-SID identifying a backbone service instance.
e) The B-VID associated with this I-SID.
f) Multicast transmit indication bit [item e) in 28.12.10].
g) Multicast receive indication bit [item f) in 28.12.10].
h) Shared tree transmit indication bit [item g) in 28.12.10].
i) Tie-Break Mask value [item h) in 28.12.10].
Std 802.1Qbp-2014
If item b) in 12.25.8.2.2 is configured with the value 0, a list indexed by the CBP ports on the system
containing items a) to i) [with the exception of item a2)].
12.25.12 The SPBM Topology Service Table managed object
12.25.12.1 Read SPBM Topology Service Table managed object
Change 12.25.12.1.3 (renumbered from 12.25.11.1.3) as shown:
12.25.12.1.3 Outputs
A list, which may be empty, comprising one entry for each I-SID assigned to a Base VID within the SPT
Region of which the local IS-IS instance is aware. Each entry contains the following information about the I-
SID:
a) The Topology Index value that uniquely identifies this topology instance.
b) The SPB System Identifier of the SPT bridges operating in SPBM mode hosting an I-SID instance.
c) The I-SID value.
d) The Base VID associated with this I-SID (and hence the ECT-ALGORITHM applied to this
service).
e) The B-MAC address associated with this I-SID. If multiple I-SID instances are configured on a
single bridge but are reachable by different B-MAC addresses, a separate record is returned for each
B-MAC address associated with that I-SID.
f) The I-SID instance service characteristic; transmit-only, receive-only, or both [item e) and item f) in
28.12.10; item e) and item f) in 12.25.8.1].
g) If ECMP is supported, the shared tree transmit indication [item g) in 28.12.10; item g) in
12.25.8.1.2].
h) If ECMP is supported, the Tie-Break Mask value [item h) in 28.12.10; item h) in 12.25.8.1.2].
NOTE—In general, an I-SID will be assigned to a single Base VID. During the administratively mediated migration of
traffic from one ECT-ALGORITHM to a new one, an I-SID may be assigned to two Base VIDs for the duration of the
transition in order to achieve loss-less migration (28.9.2).
Insert new subclause 12.25.14 after 12.25.12 (renumbered 12.25.13):
12.25.14 The ECMP ECT Static Entry managed object
There is one ECMP ECT Static Entry managed object per Tie-Break Mask. It contains the Bridge Priority to
be used for shared tree root selection for that Tie-Break Mask value. It is persistent over reboot. The
management operations that can be performed on the ECMP ECT Static Entry managed object are as
follows:
a) Write ECMP ECT Static Entry managed object (12.25.14.1).

b) Read ECMP ECT Static Entry managed object (12.25.14.2).
12.25.14.1 Write ECMP ECT Static Entry managed object
12.25.14.1.1 Purpose
To configure a different Bridge Priority to be used solely for shared tree root selection for a given Tie-Break
Mask (28.12.6.1, 28.8.2).
Std 802.1Qbp-2014
12.25.14.1.2 Inputs
a) A Topology Index value which uniquely identifies a topology instance.

b) A Tie-Break Mask value [item d) in 28.12.6.1].
c) Bridge Priority [item e) in 28.12.6.1].
12.25.14.1.3 Outputs
a) Operation status. This takes one of the following values:

12.25.14.2 Read ECMP ECT Static Entry managed object
12.25.14.2.1 Purpose
To read back the Bridge Priority for a given Tie-Break Mask.
12.25.14.2.2 Inputs

b) A Tie-Break Mask value [item d) in 28.12.6.1].
12.25.14.2.3 Outputs
a) a) Operation status—this takes one of the following values:

b) The Topology Index value that uniquely identifies this topology instance.
c) The Tie-Break Mask value [item d) in 28.12.6.1].
d) The Bridge Priority [item e) in 28.12.6.1].
Std 802.1Qbp-2014
17. Management Information Base (MIB)
17.2 Structure of the MIB
Insert the following row at the end of Table 17-1:
Table 17-1—Structure of the MIB modules
Defining IEEE
Module Subclause Reference Notes
standard
IEEE8021-ECMP-MIB 17.7.21 802.1Qbp 44, 28 Initial version in IEEE Std

802.1Qbp
17.2.19 Structure of the IEEE8021-SPB-MIB
Insert the following rows at the end of Table 17-25:
Table 17-25—IEEE8021-SPB MIB structure and relationship to this standard
Clause 17 MIB table/object Reference
ieee8021SpbmBsiStaticTable 12.25.8, 28.12.10
ieee8021SpbmBsiStaticTableEntry 12.25.8
ieee8021SpbmBsiStaticEntryIsid 12.25.8.1, 12.25.8.2
ieee8021SpbmBsiStaticEntryBaseVid 12.25.8.1, 12.25.8.2
ieee8021SpbmBsiStaticEntryTBit 12.25.8.1, 12.25.8.2
ieee8021SpbmBsiStaticEntryRBit 12.25.8.1, 12.25.8.2

ieee8021SpbmBsiStaticEntryTsBit 12.25.8.1, 12.25.8.2
ieee8021SpbmBsiStaticEntryTieBreakMask 12.25.8.1, 12.25.8.2
ieee8021SpbmBsiStaticEntryRowStatus
dot1agCfmMepSpbmTable 12.14.7, 27.18
dot1agCfmMepSpbmEntry 12.14.7
dot1agCfmMepTransmitLbmSpbmDA 12.14.7.3
dot1agCfmMepTransmitLtmSpbmDA 12.14.7.4
dot1agCfmMepSpbmEspTable 12.14.5.3.2, 27.18.1
dot1agCfmMepSpbmEspEntry 12.14.5.3.2
dot1agCfmMepSpbmEspIndex 12.14.5.3.2
dot1agCfmMepSpbmEspEsp 12.14.5.3.2
dot1agCfmMepSpbmEspRowStatus
Std 802.1Qbp-2014
Insert 17.2.21 after 17.2.20:
17.2.21 Structure of the IEEE8021-ECMP-MIB
The IEEE8021-ECMP-MIB provides for configuration of flow filtering (44.2) on ports (CBPs and PNPs)
and the configuration of ISIS-SPB advertisements specific to the ECMP ECT Algorithm (44.1.2). It also
allows reading of FDB state and statistics related to ECMP and flow filtering. Table 17-27 indicates the
relationship between the SMIv2 objects defined in the MIB module (17.7.21) and managed objects defined
in Clause 12.
Table 17-27—IEEE8021-ECMP-MIB structure and relationship to this standard
Clause 17 MIB table/object Reference
ieee8021QBridgeEcmpFdbTable 12.7.7.3, 8.8.3
(AUGMENTS ieee8021QBridgeTpFdbEntry)
ieee8021QBridgeEcmpFdbPortList
ieee8021EcmpFlowFilterCtlTable 12.16.5.4, 12.16.5.5, 44.2.2
ieee8021EcmpFlowFilterCtlVid
ieee8021EcmpFlowFilterCtlEnabled
ieee8021EcmpFlowFilterCtlHashGen
ieee8021EcmpFlowFilterCtlTtl
ieee8021EcmpEctStaticTable 12.25.14, 28.12.6.1

ieee8021EcmpEctStaticEntryTieBreakMask
ieee8021EcmpEctStaticEntryBridgePriority
ieee8021EcmpEctStaticEntryRowStatus
ieee8021EcmpTopSrvTable 12.25.12.1.3, 28.12.10
(AUGMENTS ieee8021SpbmTopSrvTableEntry)
ieee8021EcmpTopSrvEntryTsBit
ieee8021EcmpTopSrvEntryTieBreakMask
ieee8021QBridgePortVlanTtlStatisticsTable 12.6.1.1.3, 44.2.2.1
(AUGMENTS ieee8021QBridgePortVlanStatisticsEntry)
ieee8021QBridgeTpVlanPortTtlDiscards
17.3 Relationship to other MIBs
Insert 17.3.21 after 17.3.20:
17.3.21 Relationship of the of the IEEE8021-ECMP-MIB to other MIB modules
The IEEE8021-ECMP-MIB extends SPBM functionality and therefore is closely related to the IEEE8021-
SPB-MIB and IEEE8021-PBB-MIB. For example it includes configuration for an optional ISIS-SPB
Std 802.1Qbp-2014
sub-TLV for the ECMP ECT Algorithm (28.12.6.1) and configuration for flow filtering on PNPs and CBPs
(44.2.2).
Because it provides control functions related to VIDs, it depends on the Q-BRIDGE-MIB. It also augments
tables defined in the IEEE8021-Q-BRIDGE-MIB (adding the ability to read the FDB Port Map for an
individual address and adding TTL discard statistics). It also imports items from the SNMPv2-SMI,
SNMPv2-TC, and IEEE8021-TC-MIB, and requires SNMPv2-CONF for conformance.
17.4 Security considerations
17.4.19 Security considerations of the IEEE8021-SPB MIB
Insert the following two items at the end of the second list, after
ieee8021SpbMTidStaticEntryMtidOverload:
ieee8021SpbmBsiStaticTable
dot1agCfmMepSpbmEspTable
Insert 17.4.21 after 17.4.20:
17.4.21 Security considerations of the IEEE8021-ECMP-MIB
There are a number of management objects defined in this MIB module with a MAX-ACCESS clause of
read-write and/or read-create. Such objects may be considered sensitive or vulnerable in some network
environments. The support for SET operations in a non-secure environment without proper protection can
have a negative effect on network operations. These objects and their sensitivity/vulnerability are described
next.
The following objects in the IEEE8021-ECMP-MIB could be manipulated to interfere with the operation of
ECMP networks. These could, for example, be used to misconfigure the network to cause loss of
connectivity or undesirable path selection. The following are vulnerable writable objects from the
IEEE8021-ECMP-MIB:
ieee8021EcmpEctStaticEntryBridgePriority
17.7 MIB modules
17.7.1 Definitions for the IEEE8021-TC MIB module
Delete the entire text of 17.7.1, and insert the following text:
IEEE8021-TC-MIB DEFINITIONS ::= BEGIN
-- =============================================================
-- TEXTUAL-CONVENTIONs MIB for IEEE 802.1
-- =============================================================
IMPORTS
MODULE-IDENTITY, Unsigned32, org
FROM SNMPv2-SMI -- RFC 2578
Std 802.1Qbp-2014
TEXTUAL-CONVENTION
FROM SNMPv2-TC; -- RFC 2579
ieee8021TcMib MODULE-IDENTITY
LAST-UPDATED "201302050000Z" -- February 5, 2013
ORGANIZATION "IEEE 802.1 Working Group"
CONTACT-INFO
" WG-URL: http://grouper.ieee.org/groups/802/1/index.html
WG-EMail: stds-802-1@ieee.org
Contact: David Levi

Postal: C/O IEEE 802.1 Working Group
IEEE Standards Association
445 Hoes Lane
P.O. Box 1331
Piscataway
NJ 08855-1331
USA
E-mail: STDS-802-1-L@LISTSERV.IEEE.ORG
Contact: Kevin Nolish

445 Hoes Lane
P.O. Box 1331
Piscataway
NJ 08855-1331
USA
E-mail: STDS-802-1-L@LISTSERV.IEEE.ORG"
DESCRIPTION
"Textual conventions used throughout the various IEEE 802.1 MIB
modules.
Unless otherwise indicated, the references in this MIB

module are to IEEE 802.1Q-2011.
Copyright (C) IEEE.

This version of this MIB module is part of IEEE802.1Q;
see the draft itself for full legal notices."
REVISION "201302050000Z" -- February 5, 2013

DESCRIPTION
"Added new identifier types for new SPBM MA types"
DESCRIPTION
"Modified IEEE8021BridgePortType textual convention to
include stationFacingBridgePort,
uplinkAccessPort, and uplinkRelayPort types."
REVISION "201108230000Z" -- August 23, 2011
DESCRIPTION
"Modified textual conventions to support the IEEE 802.1
MIBs for PBB-TE Infrastructure Protection Switching."
REVISION "201104060000Z" -- April 6, 2011
DESCRIPTION
"Modified textual conventions to support Remote Customer
Service Interfaces."
DESCRIPTION
"Minor edits to contact information etc. as part of
Std 802.1Qbp-2014
2011 revision of IEEE Std 802.1Q."
REVISION "200811180000Z" -- November 18, 2008

DESCRIPTION
"Added textual conventions needed to support the IEEE 802.1
MIBs for PBB-TE. Additionally, some textual conventions were
modified for the same reason."
REVISION "200810150000Z" -- October 15, 2008

DESCRIPTION
"Initial version."
::= { org ieee(111) standards-association-numbers-series-standards(2)
lan-man-stds(802) ieee802dot1(1) 1 1 }
ieee802dot1mibs OBJECT IDENTIFIER

::= { org ieee(111) standards-association-numbers-series-standards(2)
lan-man-stds(802) ieee802dot1(1) 1 }
-- =============================================================
-- Textual Conventions
-- =============================================================
IEEE8021PbbComponentIdentifier ::= TEXTUAL-CONVENTION

DISPLAY-HINT "d"
STATUS current
DESCRIPTION
"The component identifier is used to distinguish between the
multiple virtual bridge instances within a PB or PBB. Each
virtual bridge instance is called a component. In simple
situations where there is only a single component the default
value is 1. The component is identified by a component
identifier unique within the BEB and by a MAC address unique
within the PBBN. Each component is associated with a Backbone
Edge Bridge (BEB) Configuration managed object."
REFERENCE "12.3 l)"
SYNTAX Unsigned32 (1..4294967295)
IEEE8021PbbComponentIdentifierOrZero ::= TEXTUAL-CONVENTION

DISPLAY-HINT "d"
STATUS current
DESCRIPTION
"The component identifier is used to distinguish between the
multiple virtual bridge instances within a PB or PBB. In simple
situations where there is only a single component the default
value is 1. The component is identified by a component
identifier unique within the BEB and by a MAC address unique
within the PBBN. Each component is associated with a Backbone
Edge Bridge (BEB) Configuration managed object.
The special value '0' means 'no component identifier'. When

this TC is used as the SYNTAX of an object, that object must
specify the exact meaning for this value."
REFERENCE "12.3 l)"
SYNTAX Unsigned32 (0 | 1..4294967295)
IEEE8021PbbServiceIdentifier ::= TEXTUAL-CONVENTION

DISPLAY-HINT "d"
STATUS current
DESCRIPTION
Std 802.1Qbp-2014
"The service instance identifier is used at the Customer

Backbone Port of a PBB to distinguish a service instance
(Local-SID). If the Local-SID field is supported, it is
used to perform a bidirectional 1:1 mapping between the
Backbone I-SID and the Local-SID. If the Local-SID field
is not supported, the Local-SID value is the same as the
Backbone I-SID value."
REFERENCE "12.16.3, 12.16.5"
IEEE8021PbbServiceIdentifierOrUnassigned ::= TEXTUAL-CONVENTION

DISPLAY-HINT "d"
STATUS current
DESCRIPTION
"The service instance identifier is used at the Customer
Backbone Port of a PBB to distinguish a service instance
(Local-SID). If the Local-SID field is supported, it is
used to perform a bidirectional 1:1 mapping between the
Backbone I-SID and the Local-SID. If the Local-SID field
is not supported, the Local-SID value is the same as the
Backbone I-SID value.
The special value of 1 indicates an unassigned I-SID."

REFERENCE "12.16.3, 12.16.5"
SYNTAX Unsigned32 (1|256..16777214)
IEEE8021PbbIngressEgress ::= TEXTUAL-CONVENTION

STATUS current
DESCRIPTION
"A 2 bit selector which determines if frames on this VIP may
ingress to the PBBN but not egress the PBBN, egress to the
PBBN but not ingress the PBBN, or both ingress and egress
the PBBN."
REFERENCE "12.16.3, 12.16.5, 12.16.6"
SYNTAX BITS {
ingress(0),
egress(1)
}
IEEE8021PriorityCodePoint ::= TEXTUAL-CONVENTION

STATUS current
DESCRIPTION
"Bridge ports may encode or decode the PCP value of the
frames that traverse the port. This textual convention
names the possible encoding and decoding schemes that
the port may use. The priority and drop_eligible
parameters are encoded in the Priority Code Point (PCP)
field of the VLAN tag using the Priority Code Point
Encoding Table for the Port, and they are decoded from
the PCP using the Priority Code Point Decoding Table."
REFERENCE "12.6.2.6"
SYNTAX INTEGER {
codePoint8p0d(1),
codePoint7p1d(2),
codePoint6p2d(3),
codePoint5p3d(4)
}
IEEE8021BridgePortNumber ::= TEXTUAL-CONVENTION
Std 802.1Qbp-2014
DISPLAY-HINT "d"
STATUS current
DESCRIPTION
"An integer that uniquely identifies a bridge port, as
specified in 17.3.2.2 of IEEE 802.1ap.
This value is used within the spanning tree
protocol to identify this port to neighbor bridges."
IEEE8021BridgePortNumberOrZero ::= TEXTUAL-CONVENTION

DISPLAY-HINT "d"
STATUS current
DESCRIPTION
"An integer that uniquely identifies a bridge port, as
specified in 17.3.2.2 of IEEE 802.1ap. The value 0
means no port number, and this must be clarified in the
DESCRIPTION clause of any object defined using this
TEXTUAL-CONVENTION."
IEEE8021BridgePortType ::= TEXTUAL-CONVENTION

STATUS current
DESCRIPTION
"A port type. The possible port types are:
customerVlanPort(2) - Indicates a port is a C-tag

aware port of an enterprise VLAN aware bridge.
providerNetworkPort(3) - Indicates a port is an S-tag

aware port of a Provider Bridge or Backbone Edge
Bridge used for connections within a PBN or PBBN.
customerNetworkPort(4) - Indicates a port is an S-tag

aware port of a Provider Bridge or Backbone Edge
Bridge used for connections to the exterior of a
PBN or PBBN.
customerEdgePort(5) - Indicates a port is a C-tag

aware port of a Provider Bridge used for connections
to the exterior of a PBN or PBBN.
customerBackbonePort(6) - Indicates a port is a I-tag

aware port of a Backbone Edge Bridge's B-component.
virtualInstancePort(7) - Indicates a port is a virtual

S-tag aware port within a Backbone Edge Bridge's
I-component which is responsible for handling
S-tagged traffic for a specific backbone service
instance.
dBridgePort(8) - Indicates a port is a VLAN-unaware

member of an 802.1D bridge.
remoteCustomerAccessPort (9) - Indicates a port is an

S-tag aware port of a Provider Bridge used for
connections to remote customer interface LANs
through another PBN.
Std 802.1Qbp-2014
stationFacingBridgePort (10) - Indicates a port of a

Bridge that supports the EVB status parameters
(6.6.5) with an EVBMode parameter value of
EVB Bridge.
uplinkAccessPort (11) - Indicates a port on a

Port-mapping S-VLAN component that connects an EVB
Bridge with an EVB station.
uplinkRelayPort (12) - Indicates a port of an edge relay

that supports the EVB status parameters (6.6.5)
with an EVBMode parameter value of EVB station."
REFERENCE "12.16.1.1.3 h4), 12.16.2.1/2,
12.13.1.1, 12.13.1.2, 12.15.2.1, 12.15.2.2"
SYNTAX INTEGER {
none(1),
customerVlanPort(2),
providerNetworkPort(3),
customerNetworkPort(4),
customerEdgePort(5),
customerBackbonePort(6),
virtualInstancePort(7),
dBridgePort(8),
remoteCustomerAccessPort(9),
stationFacingBridgePort(10),
uplinkAccessPort(11),
uplinkRelayPort(12)
}
IEEE8021VlanIndex ::= TEXTUAL-CONVENTION

DISPLAY-HINT "d"
STATUS current
DESCRIPTION
"A value used to index per-VLAN tables: values of 0 and
4095 are not permitted. If the value is between 1 and
4094 inclusive, it represents an IEEE 802.1Q VLAN-ID with
global scope within a given bridged domain (see VlanId
textual convention). If the value is greater than 4095,
then it represents a VLAN with scope local to the
particular agent, i.e., one without a global VLAN-ID
assigned to it. Such VLANs are outside the scope of
IEEE 802.1Q, but it is convenient to be able to manage them
in the same way using this MIB."
REFERENCE "9.6"
SYNTAX Unsigned32 (1..4094|4096..4294967295)
IEEE8021VlanIndexOrWildcard ::= TEXTUAL-CONVENTION

DISPLAY-HINT "d"
STATUS current
DESCRIPTION
"A value used to index per-VLAN tables. The value 0 is not
permitted, while the value 4095 represents a 'wildcard'
value. An object whose SYNTAX is IEEE8021VlanIndexOrWildcard
must specify in its DESCRIPTION the specific meaning of the
wildcard value. If the value is between 1 and
4094 inclusive, it represents an IEEE 802.1Q VLAN-ID with
global scope within a given bridged domain (see VlanId
textual convention). If the value is greater than 4095,
Std 802.1Qbp-2014
then it represents a VLAN with scope local to the

particular agent, i.e., one without a global VLAN-ID
assigned to it. Such VLANs are outside the scope of
IEEE 802.1Q, but it is convenient to be able to manage them
in the same way using this MIB."
REFERENCE "9.6"
IEEE8021MstIdentifier ::= TEXTUAL-CONVENTION

DISPLAY-HINT "d"
STATUS current
DESCRIPTION
"In an MSTP Bridge, an MSTID, i.e., a value used to identify
a spanning tree (or MST) instance. In the PBB-TE environment
the value 4094 is used to identify VIDs managed by the PBB-TE
procedures."
IEEE8021ServiceSelectorType ::= TEXTUAL-CONVENTION

STATUS current
DESCRIPTION
"A value that represents a type (and thereby the format)
of a IEEE8021ServiceSelectorValue. The value can be one of
the following:
ieeeReserved(0) Reserved for definition by IEEE 802.1

recommend to not use zero unless
absolutely needed.
vlanId(1) 12-Bit identifier as described in IEEE802.1Q.
isid(2) 24-Bit identifier as described in IEEE802.1ah.
tesid(3) 32 Bit identifier as described below.
segid(4) 32 Bit identifier as described below.
path-tesid(5) 32 Bit identifier as described below.
group-isid(6) 24 Bit identifier as described below.
ieeeReserved(xx) Reserved for definition by IEEE 802.1
xx value can be [7].
To support future extensions, the IEEE8021ServiceSelectorType

textual convention SHOULD NOT be sub-typed in object type
definitions. It MAY be sub-typed in compliance statements in
order to require only a subset of these address types for a
compliant implementation.
The tesid is used as a service selector for MAs that are present
in bridges that implement PBB-TE functionality. A selector of
this type is interpreted as a 32 bit unsigned value of type
IEEE8021PbbTeTSidId. This type is used to index the
ieee8021PbbTeTeSiEspTable to find the ESPs which comprise the TE
Service Instance named by this TE-SID value.
The segid is used as a service selector for MAs that are present
in bridges that implement IPS functionality. A selector of
this type is interpreted as a 32 bit unsigned value of type
IEEE8021TeipsSegid. This type is used to index the
Ieee8021TeipsSegTable to find the SMPs which comprise the
Infrastructure Segment named by this segid value.
The path-tesid is used as a service selector for SPBM path MAs.

A selector of this type is interpreted as a 32 bit unsigned value
Std 802.1Qbp-2014
corresponding to the MA index dot1agCfmMaIndex. This type is used

to index the dot1agCfmMepSpbmEspTable to find the ESPs which
comprise the SPBM path associated with an SPBM path MA.
The group-isid is used as a service selector for SPBM group MAs.

A selector of this type is interpreted as a 24 bit unsigned value
corresponding to the I-SID associated with an SPBM group MA.
Implementations MUST ensure that IEEE8021ServiceSelectorType

objects and any dependent objects (e.g.,
IEEE8021ServiceSelectorValue objects) are consistent. An
inconsistentValue error MUST be generated if an attempt to
change an IEEE8021ServiceSelectorType object would, for
example, lead to an undefined IEEE8021ServiceSelectorValue value."
SYNTAX INTEGER {
vlanId(1),
isid(2),
tesid(3),
segid(4)
}
IEEE8021ServiceSelectorValueOrNone ::= TEXTUAL-CONVENTION

DISPLAY-HINT "d"
STATUS current
DESCRIPTION
"An integer that uniquely identifies a generic MAC service,
or none. Examples of service selectors are a VLAN-ID
(IEEE 802.1Q) and an I-SID (IEEE 802.1ah).
An IEEE8021ServiceSelectorValueOrNone value is always

interpreted within the context of an
IEEE8021ServiceSelectorType value. Every usage of the
IEEE8021ServiceSelectorValueOrNone textual convention is
required to specify the IEEE8021ServiceSelectorType object
that provides the context. It is suggested that the
IEEE8021ServiceSelectorType object be logically registered
before the object(s) that use the
IEEE8021ServiceSelectorValueOrNone textual convention, if
they appear in the same logical row.
The value of an IEEE8021ServiceSelectorValueOrNone object

must always be consistent with the value of the associated
IEEE8021ServiceSelectorType object. Attempts to set an
IEEE8021ServiceSelectorValueOrNone object to a value
inconsistent with the associated
IEEE8021ServiceSelectorType must fail with an
inconsistentValue error.
The special value of zero is used to indicate that no

service selector is present or used. This can be used in
any situation where an object or a table entry MUST either
refer to a specific service, or not make a selection.
Note that a MIB object that is defined using this

TEXTUAL-CONVENTION SHOULD clarify the meaning of
'no service' (i.e., the special value 0), as well as the
maximum value (i.e., 4094, for a VLAN ID)."
SYNTAX Unsigned32 (0 | 1..4294967295)
Std 802.1Qbp-2014
IEEE8021ServiceSelectorValue ::= TEXTUAL-CONVENTION

DISPLAY-HINT "d"
STATUS current
DESCRIPTION
"An integer that uniquely identifies a generic MAC service.
Examples of service selectors are a VLAN-ID (IEEE 802.1Q)
and an I-SID (IEEE 802.1ah).
An IEEE8021ServiceSelectorValue value is always interpreted

within the context of an IEEE8021ServiceSelectorType value.
Every usage of the IEEE8021ServiceSelectorValue textual
convention is required to specify the
IEEE8021ServiceSelectorType object that provides the context.
It is suggested that the IEEE8021ServiceSelectorType object
be logically registered before the object(s) that use the
IEEE8021ServiceSelectorValue textual convention, if they
appear in the same logical row.
The value of an IEEE8021ServiceSelectorValue object must

always be consistent with the value of the associated
IEEE8021ServiceSelectorType object. Attempts to set an
IEEE8021ServiceSelectorValue object to a value inconsistent
with the associated IEEE8021ServiceSelectorType must fail
with an inconsistentValue error.
Note that a MIB object that is defined using this

TEXTUAL-CONVENTION SHOULD clarify the
maximum value (i.e., 4094, for a VLAN ID)."
IEEE8021PortAcceptableFrameTypes ::= TEXTUAL-CONVENTION

STATUS current
DESCRIPTION
"Acceptable frame types on a port."
REFERENCE "12.10.1.3, 12.13.3.3, 12.13.3.4"
SYNTAX INTEGER {
admitAll(1),
admitUntaggedAndPriority(2),
admitTagged(3)
}
IEEE8021PriorityValue ::= TEXTUAL-CONVENTION

DISPLAY-HINT "d"
STATUS current
DESCRIPTION
"An 802.1Q user priority value."
IEEE8021PbbTeProtectionGroupId ::= TEXTUAL-CONVENTION

DISPLAY-HINT "d"
STATUS current
DESCRIPTION
"The PbbTeProtectionGroupId identifier is used to distinguish
protection group instances present in the B Component of
an IB-BEB."
REFERENCE "12.19.2"
Std 802.1Qbp-2014
IEEE8021PbbTeEsp ::= TEXTUAL-CONVENTION

STATUS current
DESCRIPTION
"This textual convention is used to represent the logical
components that comprise the 3-tuple that identifies an
Ethernet Switched Path. The 3-tuple consists of a
destination MAC address, a source MAC address and a VID.
Bytes (1..6) of this textual convention contain the
ESP-MAC-DA, bytes (7..12) contain the ESP-MAC-SA, and bytes
(13..14) contain the ESP-VID."
REFERENCE "802.1Qay 3.2"
SYNTAX OCTET STRING ( SIZE(14))
IEEE8021PbbTeTSidId ::= TEXTUAL-CONVENTION

DISPLAY-HINT "d"
STATUS current
DESCRIPTION
"This textual convention is used to represent an identifier
that refers to a TE Service Instance. Note that, internally
a TE-SID is implementation dependent. This textual convention
defines the external representation of TE-SID values."
REFERENCE
"802.1Qay 3.11"
IEEE8021PbbTeProtectionGroupConfigAdmin ::= TEXTUAL-CONVENTION

STATUS current
DESCRIPTION
"This textual convention is used to represent administrative
commands that can be issued to a protection group. The value
noAdmin(1) is used to indicate that no administrative action
is to be performed."
REFERENCE "26.10.3.3.5
26.10.3.3.6
26.10.3.3.7
12.19.2.3.2"
SYNTAX INTEGER {
clear(1),
lockOutProtection(2),
forceSwitch(3),
manualSwitchToProtection(4),
manualSwitchToWorking(5)
}
IEEE8021PbbTeProtectionGroupActiveRequests ::= TEXTUAL-CONVENTION

STATUS current
DESCRIPTION
"This textual convention is used to represent the status of
active requests within a protection group."
REFERENCE
"12.19.2.1.3 d)"
SYNTAX INTEGER {
noRequest(1),
loP(2),
fs(3),
pSFH(4),
wSFH(5),
Std 802.1Qbp-2014
IEEE8021TeipsIpgid ::= TEXTUAL-CONVENTION

DISPLAY-HINT "d"
STATUS current
DESCRIPTION
"The TEIPS IPG identifier is used to distinguish
IPG instances present in a PBB."
REFERENCE "12.24.1.1.3 a)"
IEEE8021TeipsSegid ::= TEXTUAL-CONVENTION

DISPLAY-HINT "d"
STATUS current
DESCRIPTION
"This textual convention is used to represent an
identifier that refers to an Infrastructure Segment.
Note that, internally a SEG-ID implementation
dependent. This textual convention defines the
external representation of SEG-ID values."
REFERENCE
"26.11.1"
IEEE8021TeipsSmpid ::= TEXTUAL-CONVENTION

STATUS current
DESCRIPTION
"This textual convention is used to represent the logical
components that comprise the 3-tuple that identifies a
Segment Monitoring Path (SMP). The 3-tuple consists of a
destination MAC address, a source MAC address and a VID.
Bytes (1..6) of this textual convention contain the
SMP-MAC-DA, bytes (7..12) contain the SMP-MAC-SA, and bytes
(13..14) contain the SMP-VID."
REFERENCE "26.11.1"
SYNTAX OCTET STRING ( SIZE(14))
IEEE8021TeipsIpgConfigAdmin ::= TEXTUAL-CONVENTION

STATUS current
DESCRIPTION
"This textual convention is used to represent administrative
commands that can be issued to an IPG. The value
clear(1) is used to indicate that no administrative action
is to be performed."
REFERENCE "12.24.2.1.3 h)"
SYNTAX INTEGER {
clear(1),
lockOutProtection(2),
forceSwitch(3),
}
IEEE8021TeipsIpgConfigActiveRequests ::= TEXTUAL-CONVENTION

STATUS current
DESCRIPTION
"This textual convention is used to represent the status of
active requests within an IPG."
REFERENCE
Std 802.1Qbp-2014
"12.24.2.1.3 d)"
SYNTAX INTEGER {
noRequest(1),
loP(2),
fs(3),
pSFH(4),
wSFH(5),
}
END
17.7.19 SPB MIB module
Delete the entire text of 17.7.19, and insert the following text:
-- ===================================================================
-- IEEE 802.1 Shortest Path Bridging (SPB) MIB --
-- ===================================================================
IEEE8021-SPB-MIB DEFINITIONS ::= BEGIN
IMPORTS
MODULE-IDENTITY, OBJECT-TYPE, Integer32, Unsigned32
FROM SNMPv2-SMI
RowStatus, MacAddress, TruthValue, TEXTUAL-CONVENTION
FROM SNMPv2-TC
ieee802dot1mibs, IEEE8021PbbIngressEgress,
IEEE8021BridgePortNumber, IEEE8021PbbServiceIdentifier,
IEEE8021PbbTeEsp
FROM IEEE8021-TC-MIB
ieee8021BridgeBasePort
FROM IEEE8021-BRIDGE-MIB
VlanId, VlanIdOrNone, VlanIdOrAny
FROM Q-BRIDGE-MIB
dot1agCfmMepEntry, dot1agCfmMdIndex, dot1agCfmMaIndex
FROM IEEE8021-CFM-MIB
InterfaceIndexOrZero
FROM IF-MIB
SnmpAdminString
FROM SNMP-FRAMEWORK-MIB
MODULE-COMPLIANCE, OBJECT-GROUP
FROM SNMPv2-CONF;
ieee8021SpbMib MODULE-IDENTITY
LAST-UPDATED "201305130000Z" -- May 13, 2013
CONTACT-INFO
" WG-URL: http://grouper.ieee.org/groups/802/1/index.html
Contact: Don Fedyk

445 Hoes Lane
P.O. Box 1331
Piscataway
NJ 08855-1331
USA
DESCRIPTION "802.1 SPB MIB"
REVISION "201305130000Z" -- May 13, 2013

DESCRIPTION "802.1Qbp additions and corrections"

DESCRIPTION "802.1 Shortest Path Bridging MIB Initial Version"
Std 802.1Qbp-2014
::= { ieee802dot1mibs 26 }
-- ===================================================================
-- TYPE DEFINITIONS --
-- ===================================================================
IEEE8021SpbAreaAddress ::= TEXTUAL-CONVENTION

DISPLAY-HINT "1x:"
STATUS current
DESCRIPTION
"This identifier is the 3 Byte IS-IS Area Address.
Domain Specific part(DSP)."
REFERENCE "12.25.1.1.2 a), 12.25.1.2.2 a), 12.25.1.3.2 a), 12.25.1.2.2 a)"
SYNTAX OCTET STRING (SIZE(3))
IEEE8021SpbEctAlgorithm ::= TEXTUAL-CONVENTION

DISPLAY-HINT "1x-"
STATUS current
DESCRIPTION
"The 4 byte Equal Cost Multiple Tree Algorithm identifier.
This identifies the tree computation algorithm and tie breakers."
REFERENCE "12.3 q)"
IEEE8021SpbMode ::= TEXTUAL-CONVENTION

STATUS current
DESCRIPTION
"Auto allocation control for this instance
of SPB. For SPBV it controls SPVIDs and for SPBM it controls
SPSourceID."
REFERENCE "27.10"
SYNTAX INTEGER { auto(1), manual(2) }
IEEE8021SpbEctMode ::= TEXTUAL-CONVENTION

STATUS current
DESCRIPTION
"The mode of the Base VID assigned for this instance of SPB.
Modes are assigned in the FID to MSTI Allocation table."
REFERENCE "12.25.5.1.3 c), 12.25.9.1.3 e)"
SYNTAX INTEGER { disabled(1), spbm(2), spbv(3) }
IEEE8021SpbDigestConvention ::= TEXTUAL-CONVENTION

STATUS current
DESCRIPTION
"The mode of the current Agreement Digest. This
determines the level of loop prevention."
REFERENCE "28.4.3"
SYNTAX INTEGER { off(1), loopFreeBoth(2), loopFreeMcastOnly(3) }
IEEE8021SpbLinkMetric ::= TEXTUAL-CONVENTION
DISPLAY-HINT "d"
STATUS current
DESCRIPTION
"The 24 bit cost of an SPB link. A lower metric
value means better. Value 16777215 equals Infinity."
REFERENCE "28.2"
SYNTAX Integer32(1..16777215)
IEEE8021SpbAdjState ::= TEXTUAL-CONVENTION

STATUS current
DESCRIPTION
"The current state of this SPB adjacency or port.
The values are up, down, and testing."
REFERENCE "12.25.6.1.3 d), 12.25.6.2.3 d), 12.25.7.1.3 (e"
SYNTAX INTEGER { up(1), down(2), testing(3) }
IEEE8021SpbmSPsourceId ::= TEXTUAL-CONVENTION

DISPLAY-HINT "1x:"
STATUS current
DESCRIPTION
Std 802.1Qbp-2014
"It is the high order 3 bytes for Group Address DA from this
bridge.
Note that only the 20 bits not including the top 4 bits are
the SPSourceID."
REFERENCE "27.15"
IEEE8021SpbDigest ::= TEXTUAL-CONVENTION

DISPLAY-HINT "1x"
STATUS current
DESCRIPTION
"The Topology Agreement digest hex string."
REFERENCE "28.4"
IEEE8021SpbMCID ::= TEXTUAL-CONVENTION

DISPLAY-HINT "1x"
STATUS current
DESCRIPTION
"MST Configuration Identifier digest hex string."
REFERENCE "13.8"
IEEE8021SpbBridgePriority ::= TEXTUAL-CONVENTION

DISPLAY-HINT "1x"
STATUS current
DESCRIPTION
"The Bridge priority is the top 2 bytes of the Bridge Identifier.
Lower values represent a better priority."
REFERENCE "13.26.3"
IEEE8021SpbMTID ::= TEXTUAL-CONVENTION

DISPLAY-HINT "d"
STATUS current
DESCRIPTION
"The IS-IS Multi Topology Identifier."
REFERENCE "3.23, 3.24"
SYNTAX Unsigned32
IEEE8021SpbServiceIdentifierOrAny ::= TEXTUAL-CONVENTION

DISPLAY-HINT "d"
STATUS current
DESCRIPTION
"The service instance identifier is used at the Customer Backbone
port in SPBM to distinguish a service instance.
The special value of 0xFFFFFF is used for wildcard.
This range also includes the default I-SID. "
REFERENCE "3.23, 3.24"
-- ===================================================================
-- OBJECT DEFINITIONS --
-- ===================================================================
-- ===================================================================
-- ieee8021SpbObjects:
-- ===================================================================
ieee8021SpbObjects OBJECT IDENTIFIER
::= { ieee8021SpbMib 1 }
-- ===================================================================
-- ieee8021SpbSys:
-- ===================================================================
ieee8021SpbSys OBJECT IDENTIFIER
::= { ieee8021SpbObjects 1 }
ieee8021SpbSysAreaAddress OBJECT-TYPE
SYNTAX IEEE8021SpbAreaAddress
MAX-ACCESS read-write
STATUS current
DESCRIPTION
Std 802.1Qbp-2014
"The three byte IS-IS Area Address to join. Normally

SPB will use area 00:00:00 however if SPB is being
used in conjunction with IPV4/V6 it may operate
using the IS-IS area address already in use.
This object is persistent."
REFERENCE "12.25.1.3.2, 12.25.1.3.3"
::= { ieee8021SpbSys 1 }
ieee8021SpbSysId OBJECT-TYPE
SYNTAX MacAddress
STATUS current
DESCRIPTION
"SYS ID used for all SPB instances on this bridge.
A six byte network wide unique identifier. This is
defaulted to the Bridge Address initially but may
be overridden.
REFERENCE "12.25.1.3.3, 3.21"
ieee8021SpbSysControlAddr OBJECT-TYPE
SYNTAX MacAddress
STATUS current
DESCRIPTION
"Group MAC that the ISIS control plane will use. SPB may
use a number of different addresses for SPB Hello and
LSP exchange. Section 27.2, 8.13.1.5 and Table 8-13 covers
the different choices. The choices are as follows:
01:80:C2:00:00:14 = All Level 1 Intermediate Systems
01:80:C2:00:00:15 = All Level 2 Intermediate Systems
09:00:2B:00:00:05 = All Intermediate Systems.
01:80:C2:00:00:2E = All Provider Bridge Intermediate Systems.
01:80:C2:00:00:2F = All Customer Bridge Intermediate Systems.
REFERENCE "12.25.1.1.2, 8.13.5.1"
ieee8021SpbSysName OBJECT-TYPE
SYNTAX SnmpAdminString (SIZE(0..32))
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"Name to be used to refer to this SPB bridge. This is advertised
in IS-IS and used for management."
REFERENCE "12.25.1.3.3"
ieee8021SpbSysBridgePriority OBJECT-TYPE
SYNTAX IEEE8021SpbBridgePriority
STATUS current
DESCRIPTION
"This is a 16 bit quantity which ranks this SPB Bridge
relative to others when breaking ties. This priority
is the high 16 bits of the Bridge Identifier. Its impact
depends on the tie breaking algorithm. Recommend
values 0..15 be assigned to core switches to ensure
diversity of the ECT Algorithms."
REFERENCE "12.25.1.3.3, 13.26.3"
ieee8021SpbmSysSPSourceId OBJECT-TYPE
SYNTAX IEEE8021SpbmSPsourceId
STATUS current
DESCRIPTION
"The Shortest Path Source Identifier.
It is the high order 3 bytes for Group Address DA from this
bridge.
Note that only the 20 bits not including the top 4 bits are
Std 802.1Qbp-2014
the SPSourceID.
REFERENCE "12.25.1.3.3, 3.17, 27.15"
ieee8021SpbvSysMode OBJECT-TYPE
SYNTAX IEEE8021SpbMode
STATUS current
DESCRIPTION
"Indication of supporting SPBV mode
auto(=1)/manual(=2)
auto => enable SPBV mode and auto allocate SPVIDs.
manual => enable SPBV mode and manually assign SPVIDs.
REFERENCE "12.25.1.3.3, 3.20"
DEFVAL {auto}
ieee8021SpbmSysMode OBJECT-TYPE
STATUS current
DESCRIPTION
"Indication of supporting SPBM mode
auto(=1)/manual(=2)
auto => enable SPBM mode and auto allocate SPsourceID.
manual => enable SPBM mode and manually assign SPsourceID.
REFERENCE "12.25.1.3.3, 3.19"
DEFVAL {auto}
ieee8021SpbSysDigestConvention OBJECT-TYPE
SYNTAX IEEE8021SpbDigestConvention
STATUS current
DESCRIPTION
"The Agreement Digest convention setting
off(=1)/loopFreeBoth(=2)/loopFreeMcastOnly(=3)
off => disable agreement digest checking in hellos
loopFreeBoth => block unsafe group and individual
traffic when digests disagree.
loopFreeMcastOnly =>block unsafe group traffic when digests
disagree.
REFERENCE "12.25.1.3.3, 28.4.3"
DEFVAL {loopFreeBoth}
-- ===================================================================
-- ieee8021SpbMtidStaticTable:
-- ===================================================================
ieee8021SpbMtidStaticTable OBJECT-TYPE
SYNTAX SEQUENCE OF Ieee8021SpbMtidStaticTableEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"A Table of multiple logical topologies - MT."
REFERENCE "12.25.2"
ieee8021SpbMtidStaticTableEntry OBJECT-TYPE
SYNTAX Ieee8021SpbMtidStaticTableEntry
STATUS current
DESCRIPTION
"This table configures a MTID to a topology index. A
topology index uniquely identifies a specific ISIS
topology enabling multiple instances or multiple
MTIDs within an instance. "
REFERENCE "12.25.2"
Std 802.1Qbp-2014
INDEX {
ieee8021SpbMtidStaticEntryMtid,
ieee8021SpbTopIx
}
::= { ieee8021SpbMtidStaticTable 1 }
Ieee8021SpbMtidStaticTableEntry ::=
SEQUENCE {
ieee8021SpbMtidStaticEntryMtid IEEE8021SpbMTID,
ieee8021SpbMTidStaticEntryMtidOverload TruthValue,
ieee8021SpbMtidStaticEntryRowStatus RowStatus,
ieee8021SpbTopIx IEEE8021SpbMTID
}
ieee8021SpbMtidStaticEntryMtid OBJECT-TYPE
SYNTAX IEEE8021SpbMTID
STATUS current
DESCRIPTION
"ISIS Multi Topology Identifier MTID
Each MTID defines logical topology and is used
to enable multiple SPB instances within one ISIS instance."
REFERENCE "12.25.1.3.2, 12.25.2.3.3, 28.12"
::= { ieee8021SpbMtidStaticTableEntry 1 }
ieee8021SpbMTidStaticEntryMtidOverload OBJECT-TYPE
SYNTAX TruthValue
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"When set for this logical topology this bridge can only
originate or terminate traffic. It cannot transit SPB
encapsulated traffic. This is the IS-IS overload feature
specific to an SPB IS-IS MTID logical topology.
REFERENCE "12.25.2.3.3, 27.8.1"
DEFVAL {false}
ieee8021SpbMtidStaticEntryRowStatus OBJECT-TYPE
SYNTAX RowStatus
STATUS current
DESCRIPTION
"The object indicates the status of an entry, and is used
to create/delete entries. This object is persistent.
REFERENCE "12.25.2.3.3"
ieee8021SpbTopIx OBJECT-TYPE
STATUS current
DESCRIPTION
"Unique identifier of this SPB topology
This is index is allocated for this ISIS/MT instance.
It is used as an index to most other SPB tables below and to
select the exact ISIS instance and which MT instance together."
REFERENCE "12.25.2.3.3"
-- ===================================================================
-- ieee8021SpbTopIxDynamicTable:
-- ===================================================================
ieee8021SpbTopIxDynamicTable OBJECT-TYPE
SYNTAX SEQUENCE OF Ieee8021SpbTopIxDynamicTableEntry
STATUS current
DESCRIPTION
"This table is for SPB dynamic information. The dynamic
information that is sent in this bridges Hellos."
Std 802.1Qbp-2014
REFERENCE "12.25.3"
ieee8021SpbTopIxDynamicTableEntry OBJECT-TYPE
SYNTAX Ieee8021SpbTopIxDynamicTableEntry
STATUS current
DESCRIPTION
"This table displays the digest information computed for this
bridge.
A bridge configures this information in MTID 0 only. "
REFERENCE "12.25.3"
INDEX {
ieee8021SpbTopIxDynamicEntryTopIx
}
::= { ieee8021SpbTopIxDynamicTable 1 }
Ieee8021SpbTopIxDynamicTableEntry ::=
SEQUENCE {
ieee8021SpbTopIxDynamicEntryTopIx IEEE8021SpbMTID,
ieee8021SpbTopIxDynamicEntryAgreeDigest IEEE8021SpbDigest,
ieee8021SpbTopIxDynamicEntryMCID IEEE8021SpbMCID,
ieee8021SpbTopIxDynamicEntryAuxMCID IEEE8021SpbMCID
}
ieee8021SpbTopIxDynamicEntryTopIx OBJECT-TYPE
STATUS current
DESCRIPTION
"ISIS-SPB Topology Index identifier
Each Topology Index defines logical topology and is used
to enable multiple SPB instances within several ISIS instances."
REFERENCE "12.25.3.1.2, 28.12"
::= { ieee8021SpbTopIxDynamicTableEntry 1 }
ieee8021SpbTopIxDynamicEntryAgreeDigest OBJECT-TYPE
SYNTAX IEEE8021SpbDigest
STATUS current
DESCRIPTION
"The topology agreement digest value. Digest of all
topology information, as in clause 28.4."
REFERENCE "12.25.3.1.3, 28.4"
ieee8021SpbTopIxDynamicEntryMCID OBJECT-TYPE
SYNTAX IEEE8021SpbMCID
STATUS current
DESCRIPTION
"The MST Identifier MCID. The MCID is a digest of the
VID to MSTID configuration table which determines the Base VIDs
enabled for SPBV and SPBM."
REFERENCE "12.25.3.1.3, 13.8"
ieee8021SpbTopIxDynamicEntryAuxMCID OBJECT-TYPE
STATUS current
DESCRIPTION
"The aux MST Identifier for migration.
Either MCID or AuxMCID must match for adjacency to form."
REFERENCE "12.25.3.1.3, 28.9"
-- ===================================================================
-- ieee8021SpbEctStaticTable:
-- ===================================================================
ieee8021SpbEctStaticTable OBJECT-TYPE
SYNTAX SEQUENCE OF Ieee8021SpbEctStaticTableEntry
Std 802.1Qbp-2014
STATUS current
DESCRIPTION
"The Equal Cost Tree (ECT) static configuration table."
REFERENCE "12.25.4"
ieee8021SpbEctStaticTableEntry OBJECT-TYPE
SYNTAX Ieee8021SpbEctStaticTableEntry
STATUS current
DESCRIPTION
"The Equal Cost Tree static configuration Table defines the
ECT-ALGORITHM for the Base VID and if SPBV is used for the SPVID.
"
REFERENCE "12.25.4"
INDEX {
ieee8021SpbEctStaticEntryTopIx,
ieee8021SpbEctStaticEntryBaseVid
}
::= { ieee8021SpbEctStaticTable 1 }
Ieee8021SpbEctStaticTableEntry ::=
SEQUENCE {
ieee8021SpbEctStaticEntryTopIx IEEE8021SpbMTID,
ieee8021SpbEctStaticEntryBaseVid VlanIdOrAny,
ieee8021SpbEctStaticEntryEctAlgorithm IEEE8021SpbEctAlgorithm,
ieee8021SpbvEctStaticEntrySpvid VlanIdOrNone,
ieee8021SpbEctStaticEntryRowStatus RowStatus
}
ieee8021SpbEctStaticEntryTopIx OBJECT-TYPE
STATUS current
DESCRIPTION
"The ISIS Topology Index identifier to which this
instance belongs. Each Topology Index defines logical topology
and is used to enable multiple SPB instances within several
ISIS instances."
REFERENCE "12.25.4.2.2, 12.25.4.2.3, 28.12"
::= { ieee8021SpbEctStaticTableEntry 1 }
ieee8021SpbEctStaticEntryBaseVid OBJECT-TYPE
SYNTAX VlanIdOrAny
STATUS current
DESCRIPTION
"Base VID to use for this ECT-ALGORITHM.
Traffic B-VID (SPBM) or Management VID (SPBV).
A Base VID value of 4095 is a wildcard for any Base VID
assigned to SPB operation."
REFERENCE "12.25.4.2.3, 3.3"
ieee8021SpbEctStaticEntryEctAlgorithm OBJECT-TYPE
SYNTAX IEEE8021SpbEctAlgorithm
STATUS current
DESCRIPTION
"This identifies the tie-breaking algorithms used in
Shortest Path Tree computation. Values range from
00-80-c2-01 to 00-80-c2-16 for 802.1 for each
the 16 ECT behaviors. The default is 00-80-c2-01
the LowPATHID.
REFERENCE "12.25.4.1, 12.25.4.2.3, 3.6"
DEFVAL {"00-80-c2-01"}
ieee8021SpbvEctStaticEntrySpvid OBJECT-TYPE
SYNTAX VlanIdOrNone
Std 802.1Qbp-2014
STATUS current
DESCRIPTION
"If SPBV mode this is the VID originating from this bridge.
This input is ignored if ieee8021SpbvSysMode is auto(1),
but the output always returns the SPVID in use.
Otherwise in SPBM this is empty, should be set = 0.
REFERENCE "12.25.4.2.3, 3.16"
ieee8021SpbEctStaticEntryRowStatus OBJECT-TYPE
SYNTAX RowStatus
STATUS current
DESCRIPTION
to create/delete entries.
REFERENCE "12.25.4.2.3"
-- ===================================================================
-- ieee8021SpbEctDynamicTable:
-- ===================================================================
ieee8021SpbEctDynamicTable OBJECT-TYPE
SYNTAX SEQUENCE OF Ieee8021SpbEctDynamicTableEntry
STATUS current
DESCRIPTION
"A table containing Data about the ECT behavior on this bridge"
REFERENCE "12.25.5"
ieee8021SpbEctDynamicTableEntry OBJECT-TYPE
SYNTAX Ieee8021SpbEctDynamicTableEntry
STATUS current
DESCRIPTION
"This table can be used to check that neighbor bridges are
using the same ECT Algorithm. "
REFERENCE "12.25.5"
INDEX {
ieee8021SpbEctDynamicEntryTopIx,
ieee8021SpbEctDynamicEntryBaseVid
}
::= { ieee8021SpbEctDynamicTable 1 }
Ieee8021SpbEctDynamicTableEntry ::=
SEQUENCE {
ieee8021SpbEctDynamicEntryTopIx IEEE8021SpbMTID,
ieee8021SpbEctDynamicEntryBaseVid VlanId,
ieee8021SpbEctDynamicEntryMode IEEE8021SpbEctMode,
ieee8021SpbEctDynamicEntryLocalUse TruthValue,
ieee8021SpbEctDynamicEntryRemoteUse TruthValue,
ieee8021SpbEctDynamicEntryIngressCheckDiscards Unsigned32
}
ieee8021SpbEctDynamicEntryTopIx OBJECT-TYPE
STATUS current
DESCRIPTION
ISIS instances."
REFERENCE "12.25.5.1.2, 12.25.5.1.3, 28.12"
::= { ieee8021SpbEctDynamicTableEntry 1 }
ieee8021SpbEctDynamicEntryBaseVid OBJECT-TYPE
SYNTAX VlanId
Std 802.1Qbp-2014
STATUS current
DESCRIPTION
"The Base VID being queried. Base VID
define the mode in the VID to MSTID table. "
REFERENCE "12.25.5.1.2, 12.25.5.1.3, 3.3"
ieee8021SpbEctDynamicEntryMode OBJECT-TYPE
SYNTAX IEEE8021SpbEctMode
STATUS current
DESCRIPTION
"The Operating mode of this Base VID.
SPBM (=2), SPBV (=3), or disabled or none (1)."
REFERENCE "12.25.5.1.3, 28.12.4"
ieee8021SpbEctDynamicEntryLocalUse OBJECT-TYPE
SYNTAX TruthValue
STATUS current
DESCRIPTION
"This value indicates the ECT is in use locally
(True/False) for this Base Vid. ECTs may be defined before
services are assigned. "
REFERENCE "12.25.5.1.3, 28.12.4"
ieee8021SpbEctDynamicEntryRemoteUse OBJECT-TYPE
SYNTAX TruthValue
STATUS current
DESCRIPTION
"This value indicates the remote ECT is in use
(True/False) for this Base Vid. ECTs may be defined before
services are assigned."
REFERENCE "12.25.5.1.3, 28.12.4"
ieee8021SpbEctDynamicEntryIngressCheckDiscards OBJECT-TYPE
SYNTAX Unsigned32
STATUS current
DESCRIPTION
"The number of SA check failures on this ECT VID
This is referred to as the ingress check and this
counter increments whenever a packet is discarded
for this VID because it has not come from an
interface which is on the shortest path to its SA.
"
REFERENCE "12.25.5.1.3"
-- ===================================================================
-- ieee8021SpbAdjStaticTable:
-- ===================================================================
ieee8021SpbAdjStaticTable OBJECT-TYPE
SYNTAX SEQUENCE OF Ieee8021SpbAdjStaticTableEntry
STATUS current
DESCRIPTION
"A table containing the SPB configuration data for a neighbor"
REFERENCE "12.25.6"
ieee8021SpbAdjStaticTableEntry OBJECT-TYPE
SYNTAX Ieee8021SpbAdjStaticTableEntry
STATUS current
DESCRIPTION
"This table can be used to display the interfaces and metrics
Std 802.1Qbp-2014
of a neighbor bridge. "

REFERENCE "12.25.6"
INDEX {
ieee8021SpbAdjStaticEntryTopIx,
ieee8021SpbAdjStaticEntryIfIndex
}
::= { ieee8021SpbAdjStaticTable 1 }
Ieee8021SpbAdjStaticTableEntry ::=
SEQUENCE {
ieee8021SpbAdjStaticEntryTopIx IEEE8021SpbMTID,
ieee8021SpbAdjStaticEntryIfIndex InterfaceIndexOrZero,
ieee8021SpbAdjStaticEntryMetric IEEE8021SpbLinkMetric,
ieee8021SpbAdjStaticEntryIfAdminState IEEE8021SpbAdjState,
ieee8021SpbAdjStaticEntryRowStatus RowStatus
}
ieee8021SpbAdjStaticEntryTopIx OBJECT-TYPE
STATUS current
DESCRIPTION
ISIS instances."
REFERENCE "12.25.6.1.2, 12.25.6.1.3, 28.12"
::= { ieee8021SpbAdjStaticTableEntry 1 }
ieee8021SpbAdjStaticEntryIfIndex OBJECT-TYPE
SYNTAX InterfaceIndexOrZero
STATUS current
DESCRIPTION
"The System interface/index which defines this
adjacency. A value of 0 is a wildcard for any
interface on which SPB Operation is supported."
REFERENCE "12.25.6.1.2, 12.25.6.1.3"
ieee8021SpbAdjStaticEntryMetric OBJECT-TYPE
SYNTAX IEEE8021SpbLinkMetric
STATUS current
DESCRIPTION
"The ieee8021Spb metric (incremental cost) to this peer.
The contribution of this link to total path cost.
Recommended values are inversely proportional to link speed.
Range is (1..16777215) where 16777215 (0xFFFFFF) is
infinity; infinity signifies that the adjacency is
UP, but is not to be used for traffic.
REFERENCE "12.25.6.1.2, 12.25.6.1.3, 28.12.7"
ieee8021SpbAdjStaticEntryIfAdminState OBJECT-TYPE
SYNTAX IEEE8021SpbAdjState
STATUS current
DESCRIPTION
"The administrative state of this interface/port.
Up is the default.
REFERENCE "12.25.6.1.2, 12.25.6.1.3"
ieee8021SpbAdjStaticEntryRowStatus OBJECT-TYPE
SYNTAX RowStatus
STATUS current
DESCRIPTION
Std 802.1Qbp-2014
to create/delete entries.
REFERENCE "12.25.6.1.3"
-- ===================================================================
-- ieee8021SpbAdjDynamicTable:
-- ===================================================================
ieee8021SpbAdjDynamicTable OBJECT-TYPE
SYNTAX SEQUENCE OF Ieee8021SpbAdjDynamicTableEntry
STATUS current
DESCRIPTION
"The SPB neighbor dynamic information table."
REFERENCE "12.25.7"
ieee8021SpbAdjDynamicTableEntry OBJECT-TYPE
SYNTAX Ieee8021SpbAdjDynamicTableEntry
STATUS current
DESCRIPTION
"This table is used to determine operational values of digests
and interfaces of neighbor bridges."
REFERENCE "12.25.7"
INDEX {
ieee8021SpbAdjDynamicEntryTopIx,
ieee8021SpbAdjDynamicEntryIfIndex,
ieee8021SpbAdjDynamicEntryPeerSysId
}
::= { ieee8021SpbAdjDynamicTable 1 }
Ieee8021SpbAdjDynamicTableEntry ::=
SEQUENCE {
ieee8021SpbAdjDynamicEntryTopIx IEEE8021SpbMTID,
ieee8021SpbAdjDynamicEntryIfIndex InterfaceIndexOrZero,
ieee8021SpbAdjDynamicEntryPeerSysId MacAddress,
ieee8021SpbAdjDynamicEntryPort IEEE8021BridgePortNumber,
ieee8021SpbAdjDynamicEntryIfOperState IEEE8021SpbAdjState,
ieee8021SpbAdjDynamicEntryPeerSysName SnmpAdminString,
ieee8021SpbAdjDynamicEntryPeerAgreeDigest IEEE8021SpbDigest,
ieee8021SpbAdjDynamicEntryPeerMCID IEEE8021SpbMCID,
ieee8021SpbAdjDynamicEntryPeerAuxMCID IEEE8021SpbMCID,
ieee8021SpbAdjDynamicEntryLocalCircuitID Unsigned32,
ieee8021SpbAdjDynamicEntryPeerLocalCircuitID Unsigned32,
ieee8021SpbAdjDynamicEntryPortIdentifier Unsigned32,
ieee8021SpbAdjDynamicEntryPeerPortIdentifier Unsigned32,
ieee8021SpbAdjDynamicEntryIsisCircIndex Unsigned32
}
ieee8021SpbAdjDynamicEntryTopIx OBJECT-TYPE
STATUS current
DESCRIPTION
ISIS instances."
REFERENCE "12.25.7.1.2, 12.25.7.1.3, 28.12"
::= { ieee8021SpbAdjDynamicTableEntry 1 }
ieee8021SpbAdjDynamicEntryIfIndex OBJECT-TYPE
SYNTAX InterfaceIndexOrZero
STATUS current
DESCRIPTION
"System interface/index which defines this adjacency
A value of 0 is a wildcard for any interface
on which SPB Operation is enabled."
REFERENCE "12.25.7.1.2, 12.25.7.1.3"
Std 802.1Qbp-2014
ieee8021SpbAdjDynamicEntryPeerSysId OBJECT-TYPE
SYNTAX MacAddress
STATUS current
DESCRIPTION
"The SPB System Identifier of this peer. This is used to
identify a neighbor uniquely."
REFERENCE "12.25.7.1.3, 3.21"
ieee8021SpbAdjDynamicEntryPort OBJECT-TYPE
SYNTAX IEEE8021BridgePortNumber
STATUS current
DESCRIPTION
"The port number to reach this adjacency."
REFERENCE "12.25.7.1.3"
ieee8021SpbAdjDynamicEntryIfOperState OBJECT-TYPE
SYNTAX IEEE8021SpbAdjState
STATUS current
DESCRIPTION
"The operational state of this port.
up, down or testing (in test)."
REFERENCE "12.25.7.1.3"
ieee8021SpbAdjDynamicEntryPeerSysName OBJECT-TYPE
STATUS current
DESCRIPTION
"IS-IS system name of peer.
This is the ASCII name assigned to the bridge to aid
management. It is the same as the ieee8021SpbSysName. "
REFERENCE "12.25.7.1.3"
ieee8021SpbAdjDynamicEntryPeerAgreeDigest OBJECT-TYPE
SYNTAX IEEE8021SpbDigest
STATUS current
DESCRIPTION
"The peer topology agreement digest value
(all of the elements defined in clause 28.4).
If it does not match this bridge's digest it indicates loss of
synchronization."
REFERENCE "12.25.7.1.3, 28.4"
ieee8021SpbAdjDynamicEntryPeerMCID OBJECT-TYPE
STATUS current
DESCRIPTION
"The peer MST Identifier MCID. The MCID is a digest of the
VID to MSTID configuration table which determines the Base VIDs
enabled for SPBV and SPBM."
REFERENCE "12.25.7.1.3, 13.8"
ieee8021SpbAdjDynamicEntryPeerAuxMCID OBJECT-TYPE
STATUS current
DESCRIPTION
"The peer auxiliary MST Identifier. This MCID is
used for migration."
REFERENCE "12.25.7.1.3, 27.4.1, 28.12.2"
Std 802.1Qbp-2014
ieee8021SpbAdjDynamicEntryLocalCircuitID OBJECT-TYPE
SYNTAX Unsigned32
STATUS current
DESCRIPTION
"The value used by IS-IS to identify this adjacency locally."
REFERENCE "12.25.7.1.3, 28.11"
ieee8021SpbAdjDynamicEntryPeerLocalCircuitID OBJECT-TYPE
SYNTAX Unsigned32
STATUS current
DESCRIPTION
"The value used by peer IS-IS to identify this adjacency remotely."
REFERENCE "12.25.7.1.3, 28.11"
ieee8021SpbAdjDynamicEntryPortIdentifier OBJECT-TYPE
SYNTAX Unsigned32
STATUS current
DESCRIPTION
"The value for this bridge which has been selected by
IS-IS to form this adjacency if there is more than 1 candidate
link."
REFERENCE "12.25.7.1.3, 28.11"
ieee8021SpbAdjDynamicEntryPeerPortIdentifier OBJECT-TYPE
SYNTAX Unsigned32
STATUS current
DESCRIPTION
"The value for peer port Identifier selected by IS-IS
to form this adjacency if there is more than 1 candidate link."
REFERENCE "12.25.7.1.3, 28.11"
ieee8021SpbAdjDynamicEntryIsisCircIndex OBJECT-TYPE
SYNTAX Unsigned32
STATUS current
DESCRIPTION
"The isisCircTable reference. This allows cross referencing
to an IS-IS MIB."
REFERENCE "12.25.7.1.3"
-- ===================================================================
-- ieee8021SpbTopNodeTable:
-- ===================================================================
ieee8021SpbTopNodeTable OBJECT-TYPE
SYNTAX SEQUENCE OF Ieee8021SpbTopNodeTableEntry
STATUS current
DESCRIPTION
"Table of network specific bridge information."
REFERENCE "12.25.8"
ieee8021SpbTopNodeTableEntry OBJECT-TYPE
SYNTAX Ieee8021SpbTopNodeTableEntry
STATUS current
DESCRIPTION
"This table is used to display system level information about
bridges in the network. "
REFERENCE "12.25.8"
INDEX {
Std 802.1Qbp-2014
ieee8021SpbTopNodeEntryTopIx,
ieee8021SpbTopNodeEntrySysId
}
::= { ieee8021SpbTopNodeTable 1 }
Ieee8021SpbTopNodeTableEntry ::=
SEQUENCE {
ieee8021SpbTopNodeEntryTopIx IEEE8021SpbMTID,
ieee8021SpbTopNodeEntrySysId MacAddress,
ieee8021SpbTopNodeEntryBridgePriority IEEE8021SpbBridgePriority,
ieee8021SpbmTopNodeEntrySPsourceID IEEE8021SpbmSPsourceId,
ieee8021SpbTopNodeEntrySysName SnmpAdminString
}
ieee8021SpbTopNodeEntryTopIx OBJECT-TYPE
STATUS current
DESCRIPTION
ISIS instances."
REFERENCE "12.25.8.1.2, 12.25.8.1.3, 28.12"
::= { ieee8021SpbTopNodeTableEntry 1 }
ieee8021SpbTopNodeEntrySysId OBJECT-TYPE
SYNTAX MacAddress
STATUS current
DESCRIPTION
"The IS-IS System ID of a bridge in the SPB
LSP database and hence the network.
A value of 0 is a wildcard for all System identifiers."
REFERENCE "12.25.8.1.2, 12.25.8.1.3, 3.21"
ieee8021SpbTopNodeEntryBridgePriority OBJECT-TYPE
STATUS current
DESCRIPTION
"The Bridge Priority of the bridge in the LSP database.
This is a 16 bit quantity which ranks this SPB Bridge
relative to others when breaking ties. This priority
is the high 16 bits of the Bridge Identifier. Its impact
depends on the tie breaking algorithm. Recommend
values 0..15 be assigned to core switches to ensure
diversity of the ECT Algorithms."
REFERENCE "12.25.8.1.3, 13.26.3"
ieee8021SpbmTopNodeEntrySPsourceID OBJECT-TYPE
SYNTAX IEEE8021SpbmSPsourceId
STATUS current
DESCRIPTION
"The Shortest Path Source Identifier.
It is the high order 3 bytes for Group Address DA from this
bridge. Note that only the 20 bits not including the
top 4 bits are the SPSourceID."
REFERENCE "12.25.8.1.3, 3.17"
ieee8021SpbTopNodeEntrySysName OBJECT-TYPE
STATUS current
DESCRIPTION
"The System Name. A Human readable name of this bridge
This is used to aid in management and is used in
place of the System identifier in many commands and displays."
Std 802.1Qbp-2014
REFERENCE "12.25.8.1.3"
-- ===================================================================
-- ieee8021SpbTopEctTable:
-- ===================================================================
ieee8021SpbTopEctTable OBJECT-TYPE
SYNTAX SEQUENCE OF Ieee8021SpbTopEctTableEntry
STATUS current
DESCRIPTION
"Table of all ECT use in the network"
REFERENCE "12.25.9"
ieee8021SpbTopEctTableEntry OBJECT-TYPE
SYNTAX Ieee8021SpbTopEctTableEntry
STATUS current
DESCRIPTION
"This table lists bridges and the ECT Algorithms configured and in
use. "
REFERENCE "12.25.9"
INDEX {
ieee8021SpbTopEctEntryTopIx,
ieee8021SpbTopEctEntrySysId,
ieee8021SpbTopEctEntryBaseVid
}
::= { ieee8021SpbTopEctTable 1 }
Ieee8021SpbTopEctTableEntry ::=
SEQUENCE {
ieee8021SpbTopEctEntryTopIx IEEE8021SpbMTID,
ieee8021SpbTopEctEntrySysId MacAddress,
ieee8021SpbTopEctEntryBaseVid VlanIdOrAny,
ieee8021SpbTopEctEntryEctAlgorithm IEEE8021SpbEctAlgorithm,
ieee8021SpbTopEctEntryMode IEEE8021SpbEctMode,
ieee8021SpbvTopEctSysMode IEEE8021SpbMode,
ieee8021SpbvTopEctEntrySpvid VlanIdOrNone,
ieee8021SpbTopEctEntryLocalUse TruthValue
}
ieee8021SpbTopEctEntryTopIx OBJECT-TYPE
STATUS current
DESCRIPTION
ISIS instances."
REFERENCE "12.25.9.1.2, 12.25.9.1.3"
::= { ieee8021SpbTopEctTableEntry 1 }
ieee8021SpbTopEctEntrySysId OBJECT-TYPE
SYNTAX MacAddress
STATUS current
DESCRIPTION
"The system ID which is using a particular ECT.
REFERENCE "12.25.9.1.2, 12.25.9.1.3, 3.21"
ieee8021SpbTopEctEntryBaseVid OBJECT-TYPE
SYNTAX VlanIdOrAny
STATUS current
DESCRIPTION
"Base VID related to this algorithm
In the case of SPBM this is the B-VID that carries
traffic for this ECT-ALGORITHM. In the case of SPBV
Std 802.1Qbp-2014
this is the Base-VID used for management.

REFERENCE "12.25.9.1.2, 12.25.9.1.3, 3.3"
ieee8021SpbTopEctEntryEctAlgorithm OBJECT-TYPE
SYNTAX IEEE8021SpbEctAlgorithm
STATUS current
DESCRIPTION
"The ECT-ALGORITHM in use.
A 32 bit number. The ISIS Topology Index identifier to which this
ISIS instances.; the upper 24 bits are an OUI
and the lower 8 bits are an index. This creates a
world-wide unique identity for the computation that
will be using the VID thus ensuring consistency."
REFERENCE "12.25.9.1.3, 3.6"
ieee8021SpbTopEctEntryMode OBJECT-TYPE
SYNTAX IEEE8021SpbEctMode
STATUS current
DESCRIPTION
"Operating mode : SPBM (=2) or SPBV (=3)"
REFERENCE "12.25.9.1.3"
ieee8021SpbvTopEctSysMode OBJECT-TYPE
STATUS current
DESCRIPTION
"Indication of supporting SPBV mode
auto(=1)/manual(=2)
auto => SPBV mode and auto allocate SPVIDs.
manual => SPBV mode and manually assign SPVIDs."
REFERENCE "12.25.9.1.3, 3.18"
ieee8021SpbvTopEctEntrySpvid OBJECT-TYPE
SYNTAX VlanIdOrNone
STATUS current
DESCRIPTION
"SPVID in V mode
The VID this bridge will use to originate traffic
using this ECT-ALGORITHM when running in SPBV mode."
REFERENCE "12.25.9.1.3, 3.14"
ieee8021SpbTopEctEntryLocalUse OBJECT-TYPE
SYNTAX TruthValue
STATUS current
DESCRIPTION
"Is this ECT-ALGORITHM in use locally by advertising
bridge :- TRUE or FALSE. This is used to help with
disruption-free migration between ECT-ALGORITHMs.
Changes are only allowed if this flag is FALSE."
REFERENCE "12.25.9.1.3, 28.12.5"
-- ===================================================================
-- ieee8021SpbTopEdgeTable:
-- ===================================================================
ieee8021SpbTopEdgeTable OBJECT-TYPE
SYNTAX SEQUENCE OF Ieee8021SpbTopEdgeTableEntry
Std 802.1Qbp-2014
STATUS current
DESCRIPTION
"A Table of edges in network (not duplicated),
but each link will appear as two entries, one
ordered {near-far}, the other {far-near}."
REFERENCE "12.25.10"
ieee8021SpbTopEdgeTableEntry OBJECT-TYPE
SYNTAX Ieee8021SpbTopEdgeTableEntry
STATUS current
DESCRIPTION
"The table lists information about bridge edges (links)."
INDEX {
ieee8021SpbTopEdgeEntryTopIx,
ieee8021SpbTopEdgeEntrySysIdNear,
ieee8021SpbTopEdgeEntrySysIdFar
}
::= { ieee8021SpbTopEdgeTable 1 }
Ieee8021SpbTopEdgeTableEntry ::=
SEQUENCE {
ieee8021SpbTopEdgeEntryTopIx IEEE8021SpbMTID,
ieee8021SpbTopEdgeEntrySysIdNear MacAddress,
ieee8021SpbTopEdgeEntrySysIdFar MacAddress,
ieee8021SpbTopEdgeEntryMetricNear2Far IEEE8021SpbLinkMetric,
ieee8021SpbTopEdgeEntryMetricFar2Near IEEE8021SpbLinkMetric
}
ieee8021SpbTopEdgeEntryTopIx OBJECT-TYPE
STATUS current
DESCRIPTION
ISIS instances."
REFERENCE "12.25.10.1.2, 12.25.10.1.3, 28.12"
::= { ieee8021SpbTopEdgeTableEntry 1 }
ieee8021SpbTopEdgeEntrySysIdNear OBJECT-TYPE
SYNTAX MacAddress
STATUS current
DESCRIPTION
"The System ID of near bridge (the bridge
reporting the adjacency).
REFERENCE "12.25.10.1.2, 12.25.10.1.3, 3.21"
ieee8021SpbTopEdgeEntrySysIdFar OBJECT-TYPE
SYNTAX MacAddress
STATUS current
DESCRIPTION
"The System ID of far bridge (the neighbor
of the bridge reporting).
REFERENCE "12.25.10.1.2, 12.25.10.1.3, 3.21"
ieee8021SpbTopEdgeEntryMetricNear2Far OBJECT-TYPE
STATUS current
DESCRIPTION
"The metric used on this edge advertised by near end
This is the raw value. If it is less than the
Std 802.1Qbp-2014
MetricFar2Near (below), the MetricFar2Near is

used as the SPF metric in both directions."
REFERENCE "12.25.10.1.3, 28.12.7"
ieee8021SpbTopEdgeEntryMetricFar2Near OBJECT-TYPE
STATUS current
DESCRIPTION
"The metric used on this edge advertised by far end
This is the raw value. If it is less than the
MetricNear2Far (above), the MetricNear2Far is
used as the SPF metric in both directions."
REFERENCE "12.25.10.1.3, 28.12.7"
-- ===================================================================
-- ieee8021SpbmTopSrvTable:
-- ===================================================================
ieee8021SpbmTopSrvTable OBJECT-TYPE
SYNTAX SEQUENCE OF Ieee8021SpbmTopSrvTableEntry
STATUS current
DESCRIPTION
"All SPBM PBB encapsulated services in this network."
ieee8021SpbmTopSrvTableEntry OBJECT-TYPE
SYNTAX Ieee8021SpbmTopSrvTableEntry
STATUS current
DESCRIPTION
"This table displays information about PBB services received
in the LSP data base. The Service Identifier is associated with
the MAC address and Base VID of the bridge that originates or
terminates the service. "
INDEX {
ieee8021SpbmTopSrvEntryTopIx,
ieee8021SpbmTopSrvEntrySysId,
ieee8021SpbmTopSrvEntryIsid,
ieee8021SpbmTopSrvEntryBaseVid,
ieee8021SpbmTopSrvEntryMac
}
::= { ieee8021SpbmTopSrvTable 1 }
Ieee8021SpbmTopSrvTableEntry ::=
SEQUENCE {
ieee8021SpbmTopSrvEntryTopIx IEEE8021SpbMTID,
ieee8021SpbmTopSrvEntrySysId MacAddress,
ieee8021SpbmTopSrvEntryIsid IEEE8021SpbServiceIdentifierOrAny,
ieee8021SpbmTopSrvEntryBaseVid VlanIdOrAny,
ieee8021SpbmTopSrvEntryMac MacAddress,
ieee8021SpbmTopSrvEntryIsidFlags IEEE8021PbbIngressEgress
ieee8021SpbmTopSrvEntryTopIx OBJECT-TYPE
STATUS current
DESCRIPTION
"Entry of one The ISIS Topology Index identifier to which this
ISIS instances."
REFERENCE "12.25.11.1.2, 12.25.11.1.3, 28.12"
::= { ieee8021SpbmTopSrvTableEntry 1 }
ieee8021SpbmTopSrvEntrySysId OBJECT-TYPE
Std 802.1Qbp-2014
SYNTAX MacAddress
STATUS current
DESCRIPTION
"The System identifier this service originates/terminates on.
REFERENCE "12.25.11.1.2, 12.25.11.1.3, 3.21"
ieee8021SpbmTopSrvEntryIsid OBJECT-TYPE
SYNTAX IEEE8021SpbServiceIdentifierOrAny
STATUS current
DESCRIPTION
"An ISID (service) originating/terminating on this bridge.
A value of 0 is a wildcard for any ISID."
REFERENCE "12.25.11.1.2, 12.25.11.1.3, 28.12.10"
ieee8021SpbmTopSrvEntryBaseVid OBJECT-TYPE
SYNTAX VlanIdOrAny
STATUS current
DESCRIPTION
"The Base VID associated with this service. The Base VID determines
the ECT Algorithm that is associated with this service.
REFERENCE "12.25.11.1.2, 12.25.11.1.3, 28.12.10"
ieee8021SpbmTopSrvEntryMac OBJECT-TYPE
SYNTAX MacAddress
STATUS current
DESCRIPTION
"The MAC address associated with a service.
An additional nodal MAC address by which an I-SID
can be reached may be advertised, in which case
traffic to this MAC follows a forwarding path identical
to that taken to reach the corresponding SYSID (nodal) MAC.
If no additional MAC is advertised this will be the SYSID MAC.
A value of 0 is a wildcard for the MAC address."
REFERENCE "12.25.11.1.3, 28.12.10"
ieee8021SpbmTopSrvEntryIsidFlags OBJECT-TYPE
SYNTAX IEEE8021PbbIngressEgress
STATUS current
DESCRIPTION
"A pair of flags defining the attributes of this
service. These specify independently whether
ingress frames to the SPBM region should be
transmitted within it, and whether frames
received from the SPBM region are required
egress it."
REFERENCE "12.25.11.1.2, 12.25.11.1.3, 28.12.10"
-- ===================================================================
-- ieee8021SpbvTopSrvTable:
-- ===================================================================
ieee8021SpbvTopSrvTable OBJECT-TYPE
SYNTAX SEQUENCE OF Ieee8021SpbvTopSrvTableEntry
STATUS current
DESCRIPTION
"The SPBV group services in this network"
Std 802.1Qbp-2014
ieee8021SpbvTopSrvTableEntry OBJECT-TYPE
SYNTAX Ieee8021SpbvTopSrvTableEntry
STATUS current
DESCRIPTION
"This table displays information about SPBV group address.
The group address is a associated with MAC address and Base
VID of the bridge that originates or terminates the service."
INDEX {
ieee8021SpbvTopSrvEntryTopIx,
ieee8021SpbvTopSrvEntrySysId,
ieee8021SpbvTopSrvEntryMMac
}
::= { ieee8021SpbvTopSrvTable 1 }
Ieee8021SpbvTopSrvTableEntry ::=
SEQUENCE {
ieee8021SpbvTopSrvEntryTopIx IEEE8021SpbMTID,
ieee8021SpbvTopSrvEntrySysId MacAddress,
ieee8021SpbvTopSrvEntryMMac MacAddress,
ieee8021SpbvTopSrvEntryBaseVid VlanId,
ieee8021SpbvTopSrvEntryMMacFlags IEEE8021PbbIngressEgress
}
ieee8021SpbvTopSrvEntryTopIx OBJECT-TYPE
STATUS current
DESCRIPTION
ISIS instances."
REFERENCE "12.25.12.1.2, 12.25.12.1.3, 28.12"
::= { ieee8021SpbvTopSrvTableEntry 1 }
ieee8021SpbvTopSrvEntrySysId OBJECT-TYPE
SYNTAX MacAddress
STATUS current
DESCRIPTION
"The System identifier advertising this group address.
REFERENCE "12.25.12.1.2, 12.25.12.1.3, 3.21"
ieee8021SpbvTopSrvEntryMMac OBJECT-TYPE
SYNTAX MacAddress
STATUS current
DESCRIPTION
"This Group MAC address entry.
A value of 0 is a wildcard for any Group MAC address. "
REFERENCE "12.25.12.1.2, 12.25.12.1.3, 28.12.9"
ieee8021SpbvTopSrvEntryBaseVid OBJECT-TYPE
SYNTAX VlanId
STATUS current
DESCRIPTION
"The Base VID associated with this service. The Base VID determines
the ECT Algorithm that is associated with this service."
REFERENCE "12.25.12.1.3, 3.3"
ieee8021SpbvTopSrvEntryMMacFlags OBJECT-TYPE
SYNTAX IEEE8021PbbIngressEgress
STATUS current
Std 802.1Qbp-2014
DESCRIPTION
"A pair of {ingress, egress} flags for this
Group Address, defining transmit/receive or both. This enables
filtering of Group addresses to interwork with MMRP."
REFERENCE "12.25.12.1.3, 28.12.9"
-- ===================================================================
-- ieee8021SpbmBsiStaticTable:
-- ===================================================================
ieee8021SpbmBsiStaticTable OBJECT-TYPE
SYNTAX SEQUENCE OF Ieee8021SpbmBsiStaticEntry
STATUS current
DESCRIPTION
"Table of BSIs configured on this system and assigned to
an SPBM VID.
The table is indexed by
- ieee8021SpbTopIx from ieee8021SpbMtidStaticTable
indicating the ISIS-SPB topology instance into
which the BSI will be advertised,
- ieee8021BridgeBasePort from ieee8021PbbCbpTable
identifying the CPB on which the BSI is configured,
- an I-SID value identifying the BSI, and
- a VID value identifying a B-VID for which forwarding
state is to be installed for the BSI"
REFERENCE "12.25.8"
ieee8021SpbmBsiStaticEntry OBJECT-TYPE
SYNTAX Ieee8021SpbmBsiStaticEntry
STATUS current
DESCRIPTION
"This table contains information about backbone services
configured on this system to be advertised by ISIS-SPB."
REFERENCE "12.25.8"
INDEX {
ieee8021SpbTopIx,
ieee8021BridgeBasePort,
ieee8021SpbmBsiStaticEntryIsid,
ieee8021SpbmBsiStaticEntryBaseVid
}
::= { ieee8021SpbmBsiStaticTable 1 }
Ieee8021SpbmBsiStaticEntry ::=
SEQUENCE {
ieee8021SpbmBsiStaticEntryIsid
IEEE8021PbbServiceIdentifier,
ieee8021SpbmBsiStaticEntryBaseVid VlanId,
ieee8021SpbmBsiStaticEntryTBit TruthValue,
ieee8021SpbmBsiStaticEntryRBit TruthValue,
ieee8021SpbmBsiStaticEntryTsBit TruthValue,
ieee8021SpbmBsiStaticEntryTieBreakMask Integer32,
ieee8021SpbmBsiStaticEntryRowStatus RowStatus
}
ieee8021SpbmBsiStaticEntryIsid OBJECT-TYPE
SYNTAX IEEE8021PbbServiceIdentifier
STATUS current
DESCRIPTION
"An I-SID registered on the CBP identified
by ieee8021BridgeBasePort."
::= { ieee8021SpbmBsiStaticEntry 1 }
ieee8021SpbmBsiStaticEntryBaseVid OBJECT-TYPE
SYNTAX VlanId
STATUS current
DESCRIPTION
"An B-VID registered on the CBP identified
Std 802.1Qbp-2014
by ieee8021BridgeBasePort."
ieee8021SpbmBsiStaticEntryTBit OBJECT-TYPE
SYNTAX TruthValue
STATUS current
DESCRIPTION
"If true(1), indicates the BSI transmits multicast
frames from this CBP.
ieee8021SpbmBsiStaticEntryRBit OBJECT-TYPE
SYNTAX TruthValue
STATUS current
DESCRIPTION
"If true(1), indicates the BSI wishes to receive
multicast frames at this CBP.
ieee8021SpbmBsiStaticEntryTsBit OBJECT-TYPE
SYNTAX TruthValue
STATUS current
DESCRIPTION
frames on a shared tree from this CBP.
ieee8021SpbmBsiStaticEntryTieBreakMask OBJECT-TYPE
SYNTAX Integer32 (0..15)
STATUS current
DESCRIPTION
"The value used to create the Tie-Break Mask
for calculating multicast trees.
ieee8021SpbmBsiStaticEntryRowStatus OBJECT-TYPE
SYNTAX RowStatus
STATUS current
DESCRIPTION
"This column holds the status for this row.
When the status is active, no columns of this table may be
modified.
-- ===================================================================
-- SPBM MEP configurable objects
-- ===================================================================
dot1agCfmMepSpbmTable OBJECT-TYPE
SYNTAX SEQUENCE OF Dot1agCfmMepSpbmEntry
STATUS current
DESCRIPTION
"The additional objects configurable in SPBM MEPs"
REFERENCE "27.18"
dot1agCfmMepSpbmEntry OBJECT-TYPE
SYNTAX Dot1agCfmMepSpbmEntry
STATUS current
DESCRIPTION
"The SPBM MEP table additions."
Std 802.1Qbp-2014
AUGMENTS { dot1agCfmMepEntry }
::= { dot1agCfmMepSpbmTable 1 }
Dot1agCfmMepSpbmEntry ::=
SEQUENCE {
dot1agCfmMepTransmitLbmSpbmDA MacAddress,
dot1agCfmMepTransmitLtmSpbmDA MacAddress
}
dot1agCfmMepTransmitLbmSpbmDA OBJECT-TYPE
SYNTAX MacAddress
STATUS current
DESCRIPTION
"The MAC Address to be used as the LBM destination address
in an SPBM MA: A unicast or multicast address."
REFERENCE
"12.14.7.3.2:g"
::= { dot1agCfmMepSpbmEntry 1 }
dot1agCfmMepTransmitLtmSpbmDA OBJECT-TYPE
SYNTAX MacAddress
STATUS current
DESCRIPTION
"The MAC Address to be used as the LTM destination address
in an SPBM MA: A unicast or multicast address."
REFERENCE
"12.14.7.4.2:f"
::= { dot1agCfmMepSpbmEntry 2 }
-- ===================================================================
-- SPBM path MA and ECMP path MA TE-SIDs
-- ===================================================================
dot1agCfmMepSpbmEspTable OBJECT-TYPE
SYNTAX SEQUENCE OF Dot1agCfmMepSpbmEspEntry
STATUS current
DESCRIPTION
"The SPBM ESP table contains path-tesid information for each
SPBM path MA known to a system.
This table uses three indices. The first two indices are the
indices of the Maintenance Domain and MA tables, the reason
being that a path-tesid is always related to an MA and
Maintenance Domain."
REFERENCE
"27.18.1, 12.14.5.3.2:c"
dot1agCfmMepSpbmEspEntry OBJECT-TYPE
SYNTAX Dot1agCfmMepSpbmEspEntry
STATUS current
DESCRIPTION
"The SPBM path MA ESP entry. Each entry refers to an
ESP by identifier and contains information about
one of the ESPs that comprise an SPBM path MA.
The "
INDEX { dot1agCfmMdIndex,
dot1agCfmMaIndex,
dot1agCfmMepSpbmEspIndex
}
::= { dot1agCfmMepSpbmEspTable 1 }
Dot1agCfmMepSpbmEspEntry ::=
SEQUENCE {
dot1agCfmMepSpbmEspIndex Unsigned32,
dot1agCfmMepSpbmEspEsp IEEE8021PbbTeEsp,
dot1agCfmMepSpbmEspRowStatus RowStatus
Std 802.1Qbp-2014
dot1agCfmMepSpbmEspIndex OBJECT-TYPE
STATUS current
DESCRIPTION
"This is an identifier, of local signifigance to a particular
SPBM path MA which is used to index the ESPs associated
with that MA."
::= { dot1agCfmMepSpbmEspEntry 1 }
dot1agCfmMepSpbmEspEsp OBJECT-TYPE
SYNTAX IEEE8021PbbTeEsp
STATUS current
DESCRIPTION
"This column holds the ESP identifier for one of the Ethernet
Switched Paths that define the SPBM path MA.
REFERENCE
"27.18.1, 12.14.5.3.2:c"
dot1agCfmMepSpbmEspRowStatus OBJECT-TYPE
SYNTAX RowStatus
STATUS current
DESCRIPTION
modified.
-- =============================================================
-- Conformance Information
-- =============================================================
ieee8021SpbConformance OBJECT IDENTIFIER ::= { ieee8021SpbMib 2}

ieee8021SpbGroups OBJECT IDENTIFIER ::= { ieee8021SpbConformance 1}
ieee8021SpbCompliances OBJECT IDENTIFIER ::= { ieee8021SpbConformance 2}
-- =============================================================
-- SPBM Units of conformance
-- =============================================================
ieee8021SpbSysGroupSPBM OBJECT-GROUP
OBJECTS {
ieee8021SpbSysAreaAddress,
ieee8021SpbSysId,
ieee8021SpbSysControlAddr,
ieee8021SpbSysName,
ieee8021SpbSysBridgePriority,
ieee8021SpbmSysSPSourceId,
ieee8021SpbmSysMode,
ieee8021SpbSysDigestConvention
}
STATUS current
DESCRIPTION
"The collection of objects used to represent ieee8021SpbSys"
::= { ieee8021SpbGroups 1 }
ieee8021SpbMtidStaticTableGroupSPBM OBJECT-GROUP
OBJECTS {
ieee8021SpbMTidStaticEntryMtidOverload,
ieee8021SpbMtidStaticEntryRowStatus
}
STATUS current
DESCRIPTION
Std 802.1Qbp-2014
"The collection of objects used to represent ieee8021SpbMtidStaticTable"

ieee8021SpbTopIxDynamicTableGroupSPBM OBJECT-GROUP
OBJECTS {
ieee8021SpbTopIxDynamicEntryAgreeDigest,
ieee8021SpbTopIxDynamicEntryMCID,
ieee8021SpbTopIxDynamicEntryAuxMCID
}
STATUS current
DESCRIPTION
"The collection of objects used to represent ieee8021SpbTopIxDynamicTable"
ieee8021SpbEctStaticTableGroupSPBM OBJECT-GROUP
OBJECTS {
ieee8021SpbEctStaticEntryEctAlgorithm,
ieee8021SpbEctStaticEntryRowStatus
}
STATUS current
DESCRIPTION
"The collection of objects used to represent ieee8021SpbEctStaticTable"
ieee8021SpbEctDynamicTableGroupSPBM OBJECT-GROUP
OBJECTS {
ieee8021SpbEctDynamicEntryMode,
ieee8021SpbEctDynamicEntryLocalUse,
ieee8021SpbEctDynamicEntryRemoteUse,
ieee8021SpbEctDynamicEntryIngressCheckDiscards
}
STATUS current
DESCRIPTION
"The collection of objects used to represent ieee8021SpbEctDynamicTable"
ieee8021SpbAdjStaticTableGroupSPBM OBJECT-GROUP
OBJECTS {
ieee8021SpbAdjStaticEntryMetric,
ieee8021SpbAdjStaticEntryIfAdminState,
ieee8021SpbAdjStaticEntryRowStatus
}
STATUS current
DESCRIPTION
"The collection of objects used to represent ieee8021SpbAdjStaticTable"
ieee8021SpbAdjDynamicTableGroupSPBM OBJECT-GROUP
OBJECTS {
ieee8021SpbAdjDynamicEntryPort,
ieee8021SpbAdjDynamicEntryIfOperState,
ieee8021SpbAdjDynamicEntryPeerSysName,
ieee8021SpbAdjDynamicEntryPeerAgreeDigest,
ieee8021SpbAdjDynamicEntryPeerMCID,
ieee8021SpbAdjDynamicEntryPeerAuxMCID,
ieee8021SpbAdjDynamicEntryLocalCircuitID,
ieee8021SpbAdjDynamicEntryPeerLocalCircuitID,
ieee8021SpbAdjDynamicEntryPortIdentifier,
ieee8021SpbAdjDynamicEntryPeerPortIdentifier,
ieee8021SpbAdjDynamicEntryIsisCircIndex
}
STATUS current
DESCRIPTION
"The collection of objects used to represent ieee8021SpbAdjDynamicTable"
ieee8021SpbTopNodeTableGroupSPBM OBJECT-GROUP
Std 802.1Qbp-2014
OBJECTS {
ieee8021SpbTopNodeEntryBridgePriority,
ieee8021SpbmTopNodeEntrySPsourceID,
ieee8021SpbTopNodeEntrySysName
}
STATUS current
DESCRIPTION
"The collection of objects used to represent ieee8021SpbTopNodeTable"
ieee8021SpbTopEctTableGroupSPBM OBJECT-GROUP
OBJECTS {
ieee8021SpbTopEctEntryEctAlgorithm,
ieee8021SpbTopEctEntryMode,
ieee8021SpbTopEctEntryLocalUse
}
STATUS current
DESCRIPTION
"The collection of objects used to represent ieee8021SpbTopEctTable"
ieee8021SpbTopEdgeTableGroupSPBM OBJECT-GROUP
OBJECTS {
ieee8021SpbTopEdgeEntryMetricNear2Far,
ieee8021SpbTopEdgeEntryMetricFar2Near
}
STATUS current
DESCRIPTION
"The collection of objects used to represent ieee8021SpbTopEdgeTable"
ieee8021SpbmTopSrvTableGroupSPBM OBJECT-GROUP
OBJECTS {
ieee8021SpbmTopSrvEntryIsidFlags
}
STATUS current
DESCRIPTION
"The collection of objects used to represent ieee8021SpbmTopSrvTable"
-- See below for additional SPBM Units of conformance (after SPBV section)
-- =============================================================
-- SPBV Units of conformance
-- =============================================================
ieee8021SpbSysGroupSPBV OBJECT-GROUP
OBJECTS {
ieee8021SpbSysAreaAddress,
ieee8021SpbSysId,
ieee8021SpbSysControlAddr,
ieee8021SpbSysName,
ieee8021SpbSysBridgePriority,
ieee8021SpbvSysMode,
ieee8021SpbSysDigestConvention
}
STATUS current
DESCRIPTION
"The collection of objects used to represent ieee8021SpbSys"
ieee8021SpbMtidStaticTableGroupSPBV OBJECT-GROUP
OBJECTS {
ieee8021SpbMTidStaticEntryMtidOverload,
ieee8021SpbMtidStaticEntryRowStatus
}
Std 802.1Qbp-2014
STATUS current
DESCRIPTION
"The collection of objects used to represent ieee8021SpbMtidStaticTable"
ieee8021SpbTopIxDynamicTableGroupSPBV OBJECT-GROUP
OBJECTS {
ieee8021SpbTopIxDynamicEntryAgreeDigest,
ieee8021SpbTopIxDynamicEntryMCID,
ieee8021SpbTopIxDynamicEntryAuxMCID
}
STATUS current
DESCRIPTION
"The collection of objects used to represent ieee8021SpbTopIxDynamicTable"
ieee8021SpbEctStaticTableGroupSPBV OBJECT-GROUP
OBJECTS {
ieee8021SpbEctStaticEntryEctAlgorithm,
ieee8021SpbvEctStaticEntrySpvid,
ieee8021SpbEctStaticEntryRowStatus
}
STATUS current
DESCRIPTION
"The collection of objects used to represent ieee8021SpbEctStaticTable"
ieee8021SpbEctDynamicTableGroupSPBV OBJECT-GROUP
OBJECTS {
ieee8021SpbEctDynamicEntryMode,
ieee8021SpbEctDynamicEntryLocalUse,
ieee8021SpbEctDynamicEntryRemoteUse,
ieee8021SpbEctDynamicEntryIngressCheckDiscards
}
STATUS current
DESCRIPTION
"The collection of objects used to represent ieee8021SpbEctDynamicTable"
ieee8021SpbAdjStaticTableGroupSPBV OBJECT-GROUP
OBJECTS {
ieee8021SpbAdjStaticEntryMetric,
ieee8021SpbAdjStaticEntryIfAdminState,
ieee8021SpbAdjStaticEntryRowStatus
}
STATUS current
DESCRIPTION
"The collection of objects used to represent ieee8021SpbAdjStaticTable"
ieee8021SpbAdjDynamicTableGroupSPBV OBJECT-GROUP
OBJECTS {
ieee8021SpbAdjDynamicEntryPort,
ieee8021SpbAdjDynamicEntryIfOperState,
ieee8021SpbAdjDynamicEntryPeerSysName,
ieee8021SpbAdjDynamicEntryPeerAgreeDigest,
ieee8021SpbAdjDynamicEntryPeerMCID,
ieee8021SpbAdjDynamicEntryPeerAuxMCID,
ieee8021SpbAdjDynamicEntryLocalCircuitID,
ieee8021SpbAdjDynamicEntryPeerLocalCircuitID,
ieee8021SpbAdjDynamicEntryPortIdentifier,
ieee8021SpbAdjDynamicEntryPeerPortIdentifier,
ieee8021SpbAdjDynamicEntryIsisCircIndex
}
STATUS current
DESCRIPTION
"The collection of objects used to represent ieee8021SpbAdjDynamicTable"
Std 802.1Qbp-2014
ieee8021SpbTopNodeTableGroupSPBV OBJECT-GROUP
OBJECTS {
ieee8021SpbTopNodeEntryBridgePriority,
ieee8021SpbTopNodeEntrySysName
}
STATUS current
DESCRIPTION
"The collection of objects used to represent ieee8021SpbTopNodeTable"
ieee8021SpbTopEctTableGroupSPBV OBJECT-GROUP
OBJECTS {
ieee8021SpbTopEctEntryEctAlgorithm,
ieee8021SpbTopEctEntryMode,
ieee8021SpbvTopEctSysMode,
ieee8021SpbvTopEctEntrySpvid,
ieee8021SpbTopEctEntryLocalUse
}
STATUS current
DESCRIPTION
"The collection of objects used to represent ieee8021SpbTopEctTable"
ieee8021SpbTopEdgeTableGroupSPBV OBJECT-GROUP
OBJECTS {
ieee8021SpbTopEdgeEntryMetricNear2Far,
ieee8021SpbTopEdgeEntryMetricFar2Near
}
STATUS current
DESCRIPTION
"The collection of objects used to represent ieee8021SpbTopEdgeTable"
ieee8021SpbvTopSrvTableGroupSPBV OBJECT-GROUP
OBJECTS {
ieee8021SpbvTopSrvEntryBaseVid,
ieee8021SpbvTopSrvEntryMMacFlags
}
STATUS current
DESCRIPTION
"The collection of objects used to represent ieee8021SpbvTopSrvTable"
-- =============================================================
-- Additional SPBM Units of conformance
-- =============================================================
ieee8021SpbmBsiStaticTableGroupSPBM OBJECT-GROUP
OBJECTS {
ieee8021SpbmBsiStaticEntryTBit,
ieee8021SpbmBsiStaticEntryRBit,
ieee8021SpbmBsiStaticEntryTsBit,
ieee8021SpbmBsiStaticEntryTieBreakMask,
ieee8021SpbmBsiStaticEntryRowStatus
}
STATUS current
DESCRIPTION
"The collection of objects used to represent ieee8021SpbmBsiStaticTable"
dot1agCfmMepSpbmTableGroupSPBM OBJECT-GROUP
OBJECTS {
dot1agCfmMepTransmitLbmSpbmDA,
dot1agCfmMepTransmitLtmSpbmDA
}
STATUS current
Std 802.1Qbp-2014
DESCRIPTION
"The collection of objects used to represent dot1agCfmMepSpbmTable"
dot1agCfmMepSpbmEspTableGroupSPBM OBJECT-GROUP
OBJECTS {
dot1agCfmMepSpbmEspEsp,
dot1agCfmMepSpbmEspRowStatus
}
STATUS current
DESCRIPTION
"The collection of objects used to represent dot1agCfmMepSpbmEspTable"
-- =============================================================
-- Compliance statements SPBM
-- =============================================================
ieee8021SpbComplianceSPBM MODULE-COMPLIANCE
STATUS current
DESCRIPTION
"Compliance to IEEE 802.1 SPBM mode"
MODULE
MANDATORY-GROUPS {
ieee8021SpbSysGroupSPBM ,
ieee8021SpbMtidStaticTableGroupSPBM ,
ieee8021SpbTopIxDynamicTableGroupSPBM ,
ieee8021SpbEctStaticTableGroupSPBM ,
ieee8021SpbEctDynamicTableGroupSPBM ,
ieee8021SpbAdjStaticTableGroupSPBM ,
ieee8021SpbAdjDynamicTableGroupSPBM ,
ieee8021SpbTopNodeTableGroupSPBM ,
ieee8021SpbTopEctTableGroupSPBM ,
ieee8021SpbTopEdgeTableGroupSPBM ,
ieee8021SpbmTopSrvTableGroupSPBM ,
ieee8021SpbmBsiStaticTableGroupSPBM
}
GROUP dot1agCfmMepSpbmTableGroupSPBM
DESCRIPTION
"This group is mandatory ONLY for devices supporting
SPBM VID MAs."
GROUP dot1agCfmMepSpbmEspTableGroupSPBM
DESCRIPTION
"This group is mandatory ONLY for devices supporting
SPBM path MAs or ECMP path MAs."
::= { ieee8021SpbCompliances 1 }
-- =============================================================
-- Compliance statements SPBV
-- =============================================================
ieee8021SpbComplianceSPBV MODULE-COMPLIANCE
STATUS current
DESCRIPTION
"Compliance to IEEE 802.1 SPBV mode"
MODULE
MANDATORY-GROUPS {
ieee8021SpbSysGroupSPBV ,
ieee8021SpbMtidStaticTableGroupSPBV ,
ieee8021SpbTopIxDynamicTableGroupSPBV ,
ieee8021SpbEctStaticTableGroupSPBV ,
ieee8021SpbEctDynamicTableGroupSPBV ,
ieee8021SpbAdjStaticTableGroupSPBV ,
ieee8021SpbAdjDynamicTableGroupSPBV ,
ieee8021SpbTopNodeTableGroupSPBV ,
ieee8021SpbTopEctTableGroupSPBV ,
ieee8021SpbTopEdgeTableGroupSPBV ,
ieee8021SpbvTopSrvTableGroupSPBV
Std 802.1Qbp-2014
}
::= { ieee8021SpbCompliances 2 }
END
Insert 17.7.21 after 17.7.20:

17.7.21 ECMP MIB module
-- ===================================================================
-- IEEE 802.1 Equal Cost Multiple Paths (ECMP) MIB
-- ===================================================================
IEEE8021-ECMP-MIB DEFINITIONS ::= BEGIN
IMPORTS
MODULE-IDENTITY, OBJECT-TYPE, Integer32, Counter64
FROM SNMPv2-SMI
RowStatus, TruthValue
FROM SNMPv2-TC
ieee802dot1mibs
FROM IEEE8021-TC-MIB
PortList, VlanId
FROM Q-BRIDGE-MIB
ieee8021BridgeBasePortComponentId, ieee8021BridgeBasePort
FROM IEEE8021-BRIDGE-MIB
ieee8021QBridgeTpFdbEntry, ieee8021QBridgePortVlanStatisticsEntry
FROM IEEE8021-Q-BRIDGE-MIB
IEEE8021SpbBridgePriority, ieee8021SpbmTopSrvTableEntry,
ieee8021SpbTopIx
FROM IEEE8021-SPB-MIB
MODULE-COMPLIANCE, OBJECT-GROUP
FROM SNMPv2-CONF;
ieee8021EcmpMib MODULE-IDENTITY
LAST-UPDATED "201305130000Z" -- May 13, 2013
CONTACT-INFO
"WG-URL: http://grouper.ieee.org/groups/802/1/index.html
Contact: Ben Mack-Crane

445 Hoes Lane
P.O. Box 1331
Piscataway
NJ 08855-1331
USA
DESCRIPTION "802.1 ECMP MIB"
REVISION "201305130000Z" -- May 13, 2013
DESCRIPTION "802.1 Equal Cost Multiple Paths MIB Initial Version"
::= { ieee802dot1mibs 28 }
ieee8021EcmpNotifications OBJECT IDENTIFIER ::= { ieee8021EcmpMib 0 }

ieee8021EcmpObjects OBJECT IDENTIFIER ::= { ieee8021EcmpMib 1 }
ieee8021EcmpConformance OBJECT IDENTIFIER ::= { ieee8021EcmpMib 2 }
Std 802.1Qbp-2014
-- ===================================================================
-- OBJECT DEFINITIONS
-- ===================================================================
-- =============================================================
-- ECMP FDB object for Individual Addresses
-- =============================================================
ieee8021QBridgeEcmpFdbTable OBJECT-TYPE
SYNTAX SEQUENCE OF Ieee8021QBridgeEcmpFdbEntry
STATUS current
DESCRIPTION
"A table that contains information about unicast entries
for which the device has forwarding and/or filtering
information. This information is used by the
ECMP next hop selection function in determining how to
propagate a received frame."
REFERENCE "12.7.7.3, 8.8.3:c"
::= { ieee8021EcmpObjects 1 }
ieee8021QBridgeEcmpFdbEntry OBJECT-TYPE
SYNTAX Ieee8021QBridgeEcmpFdbEntry
STATUS current
DESCRIPTION
"Information about a specific unicast MAC address for
which the device has some forwarding and/or filtering
information."
AUGMENTS { ieee8021QBridgeTpFdbEntry }
::= { ieee8021QBridgeEcmpFdbTable 1 }
Ieee8021QBridgeEcmpFdbEntry ::=
SEQUENCE {
ieee8021QBridgeEcmpFdbPortList PortList
}
ieee8021QBridgeEcmpFdbPortList OBJECT-TYPE
SYNTAX PortList
STATUS current
DESCRIPTION
"The complete set of ports, in this FID, to which
frames destined for this individual MAC address may be
forwarded."
::= { ieee8021QBridgeEcmpFdbEntry 1 }
-- =============================================================
-- Flow Filtering Control Table
-- =============================================================
ieee8021EcmpFlowFilterCtlTable OBJECT-TYPE
SYNTAX SEQUENCE OF Ieee8021EcmpFlowFilterCtlEntry
STATUS current
DESCRIPTION
"A table flow filtering control informmation for ports
in a Bridge supporting F-Tag processing."
REFERENCE "12.16.5.4, 12.16.5.5"
Std 802.1Qbp-2014
ieee8021EcmpFlowFilterCtlEntry OBJECT-TYPE
SYNTAX Ieee8021EcmpFlowFilterCtlEntry
STATUS current
DESCRIPTION
"An entry in the Flow Filtering Control Table for a
port (CPB or PNP)."
INDEX { ieee8021BridgeBasePortComponentId,
ieee8021BridgeBasePort,
ieee8021EcmpFlowFilterCtlVid }
::= { ieee8021EcmpFlowFilterCtlTable 1 }
Ieee8021EcmpFlowFilterCtlEntry ::=
SEQUENCE {
ieee8021EcmpFlowFilterCtlVid VlanId,
ieee8021EcmpFlowFilterCtlEnabled TruthValue,
ieee8021EcmpFlowFilterCtlHashGen TruthValue,
ieee8021EcmpFlowFilterCtlTtl Integer32
}
ieee8021EcmpFlowFilterCtlVid OBJECT-TYPE
SYNTAX VlanId
STATUS current
DESCRIPTION
"A B-vID registered on the port."
::= { ieee8021EcmpFlowFilterCtlEntry 1 }
ieee8021EcmpFlowFilterCtlEnabled OBJECT-TYPE
SYNTAX TruthValue
STATUS current
DESCRIPTION
"Indicates whether or not flow filtering behavior
is enabled on the port for the VID
(true(1) is enabled, false(2) is disabled)."
ieee8021EcmpFlowFilterCtlHashGen OBJECT-TYPE
SYNTAX TruthValue
STATUS current
DESCRIPTION
"indicates whether or not flow hash generation
is enabled on the port for the VID
(true(1) is enabled, false(2) is disabled)."
ieee8021EcmpFlowFilterCtlTtl OBJECT-TYPE
STATUS current
DESCRIPTION
"the initial TTL value for frames entering
the flow filtering SPT Domain.
Valid values are 1..63, zero indicates the
value has not been set.
Std 802.1Qbp-2014

-- ===================================================================
-- ECMP ECT Static Entry Table
-- ===================================================================
ieee8021EcmpEctStaticTable OBJECT-TYPE
SYNTAX SEQUENCE OF Ieee8021EcmpEctStaticEntry
STATUS current
DESCRIPTION
"Table containing alternate Bridge priorities for tie-breaker
masks used in selecting shared tree root bridges.
The table is indexed by
- ieee8021SpbTopIx from ieee8021SpbMtidStaticTable
indicating the ISIS-SPB topology instance into
which the bridge priority will be advertised, and
- ieee8021EcmpEctStaticEntryTieBreakMask
the associated tie-break mask value."
ieee8021EcmpEctStaticEntry OBJECT-TYPE
SYNTAX Ieee8021EcmpEctStaticEntry
STATUS current
DESCRIPTION
"This entry contains information about backbone services
configured on this system to be advertised by ISIS-SPB."
REFERENCE "12.25.8"
INDEX {
ieee8021SpbTopIx,
ieee8021EcmpEctStaticEntryTieBreakMask
}
::= { ieee8021EcmpEctStaticTable 1 }
Ieee8021EcmpEctStaticEntry ::=
SEQUENCE {
ieee8021EcmpEctStaticEntryTieBreakMask Integer32,
ieee8021EcmpEctStaticEntryBridgePriority IEEE8021SpbBridgePriority,
ieee8021EcmpEctStaticEntryRowStatus RowStatus
}
ieee8021EcmpEctStaticEntryTieBreakMask OBJECT-TYPE
STATUS current
DESCRIPTION
for selecting a shared tree root bridge."
::= { ieee8021EcmpEctStaticEntry 1 }
ieee8021EcmpEctStaticEntryBridgePriority OBJECT-TYPE
STATUS current
DESCRIPTION
"A Bridge Priority value to be used
Std 802.1Qbp-2014
for selecting a shared tree root bridge,

i.e. the four most significant bits of the
Bridge Identifier.
ieee8021EcmpEctStaticEntryRowStatus OBJECT-TYPE
SYNTAX RowStatus
STATUS current
DESCRIPTION

modified. All columns must have a valid value before the row
can be activated.
-- ===================================================================
-- ECMP extensions to ieee8021SpbmTopSrvTable
-- ===================================================================
ieee8021EcmpTopSrvTable OBJECT-TYPE
SYNTAX SEQUENCE OF Ieee8021EcmpTopSrvEntry
STATUS current
DESCRIPTION
"Added info for SPBM PBB encapsulated services in this network."
REFERENCE "12.25.8"
ieee8021EcmpTopSrvEntry OBJECT-TYPE
SYNTAX Ieee8021EcmpTopSrvEntry
STATUS current
DESCRIPTION
"This table contains additional information about backbone
services configured on this system to be advertised by
ISIS-SPB."
REFERENCE "12.25.8"
AUGMENTS { ieee8021SpbmTopSrvTableEntry }
::= { ieee8021EcmpTopSrvTable 1 }
Ieee8021EcmpTopSrvEntry ::=
SEQUENCE {
ieee8021EcmpTopSrvEntryTsBit TruthValue,
ieee8021EcmpTopSrvEntryTieBreakMask Integer32
}
ieee8021EcmpTopSrvEntryTsBit OBJECT-TYPE
SYNTAX TruthValue
STATUS current
DESCRIPTION
frames on a shared tree from this CBP."
::= { ieee8021EcmpTopSrvEntry 1 }
Std 802.1Qbp-2014
ieee8021EcmpTopSrvEntryTieBreakMask OBJECT-TYPE
STATUS current
DESCRIPTION
for calculating multicast trees."
::= { ieee8021EcmpTopSrvEntry 2 }
-- =============================================================
-- Per port VLAN TTL Statistics Table
-- =============================================================
ieee8021QBridgePortVlanTtlStatisticsTable OBJECT-TYPE
SYNTAX SEQUENCE OF Ieee8021QBridgePortVlanTtlStatisticsEntry
STATUS current
DESCRIPTION
"A table containing per-port, per-VID TTL discard statistics."
ieee8021QBridgePortVlanTtlStatisticsEntry OBJECT-TYPE
SYNTAX Ieee8021QBridgePortVlanTtlStatisticsEntry
STATUS current
DESCRIPTION
"TTL discard statistics for a VID on an interface."
AUGMENTS { ieee8021QBridgePortVlanStatisticsEntry }
::= { ieee8021QBridgePortVlanTtlStatisticsTable 1 }
Ieee8021QBridgePortVlanTtlStatisticsEntry ::=
SEQUENCE {
ieee8021QBridgeTpVlanPortTtlDiscards Counter64
}
ieee8021QBridgeTpVlanPortTtlDiscards OBJECT-TYPE
SYNTAX Counter64
UNITS "frames"
STATUS current
DESCRIPTION
"The number of valid frames received by this port from
its segment that were classified as belonging to this
VLAN and that were discarded due to TTL expiry.
Discontinuities in the value of the counter can occur
at re-initialization of the management system, and at
other times as indicated by the value of
ifCounterDiscontinuityTime object of the associated
interface (if any)."
REFERENCE "12.6.1.1.3"
::= { ieee8021QBridgePortVlanTtlStatisticsEntry 1 }
-- ===================================================================
-- Conformance Information
-- ===================================================================
ieee8021EcmpGroups OBJECT IDENTIFIER ::= { ieee8021EcmpConformance 1}

ieee8021EcmpCompliances OBJECT IDENTIFIER ::= { ieee8021EcmpConformance 2}
Std 802.1Qbp-2014
-- ===================================================================
-- Units of conformance
-- ===================================================================
ieee8021QBridgeEcmpFdbGroup OBJECT-GROUP
OBJECTS {
ieee8021QBridgeEcmpFdbPortList
}
STATUS current
DESCRIPTION
"FDB Port Map for ECMP Individual address"
::= { ieee8021EcmpGroups 1 }
ieee8021EcmpFlowFilterCtlGroup OBJECT-GROUP
OBJECTS {
ieee8021EcmpFlowFilterCtlEnabled,
ieee8021EcmpFlowFilterCtlHashGen,
}
STATUS current
DESCRIPTION
"Flow filtering control parameters on a CBP or PNP"
ieee8021EcmpEctStaticGroup OBJECT-GROUP
OBJECTS {
ieee8021EcmpEctStaticEntryBridgePriority,
}
STATUS current
DESCRIPTION
"Optional Bridge Priority for selecting shared tree root"
ieee8021EcmpTopSrvGroup OBJECT-GROUP
OBJECTS {
ieee8021EcmpTopSrvEntryTsBit,
ieee8021EcmpTopSrvEntryTieBreakMask
}
STATUS current
DESCRIPTION
"Advertised I-SID parameters controlling multicast routing"
ieee8021QBridgePortVlanTtlStatisticsGroup OBJECT-GROUP
OBJECTS {
ieee8021QBridgeTpVlanPortTtlDiscards
}
STATUS current
DESCRIPTION
"TTL discard statistics"
-- ===================================================================
-- Compliance statements
-- ===================================================================
ieee8021EcmpCompliance MODULE-COMPLIANCE
STATUS current
Std 802.1Qbp-2014
DESCRIPTION
"Compliance to IEEE 802.1 SPBM ECMP"
MODULE
MANDATORY-GROUPS {
ieee8021QBridgeEcmpFdbGroup,
ieee8021EcmpEctStaticGroup,
ieee8021EcmpTopSrvGroup
}
::= { ieee8021EcmpCompliances 1 }
ieee8021EcmpFlowFilteringCompliance MODULE-COMPLIANCE
STATUS current
DESCRIPTION
"Compliance to IEEE 802.1 SPBM ECMP with flow filtering"
MODULE
MANDATORY-GROUPS {
ieee8021EcmpFlowFilterCtlGroup,
ieee8021QBridgePortVlanTtlStatisticsGroup
}
::= { ieee8021EcmpCompliances 2 }
END
Std 802.1Qbp-2014
19. Connectivity Fault Management Entity operation
19.3 MIP Half Function
19.3.3 MHF architecture
Replace Figure 19-3 with the following figure:
Passive SAP — ( ) — (E)ISS
Passive MHF Multiplexer

Linktrace Responder
other
Linktrace — ( ) — SAP (ISS)
OpCode De-
multiplexer
Frame MD Level not present
Frame MD Level > mdLevel

Frame MD Level < mdLevel
LTR LTM
RFM
Active MHF Multiplexer
RFM Receiver
LOM SAP
Data frame
()
SFM
Decapsulator Responder
LBM†
LBR LBM*
LBM
MHF Loopback Responder
Frame Type != CFM

CCM
MHF Continuity Check Receiver
Frame MD Level == mdLevel
MIP CCM Database
MHF Level Demultiplexer
Frame Type == CFM
MHF Type Demultiplexer
MHF symbol: —( ) — (E)ISS Active SAP

* This path is present only in PBB-TE or SPBM MHFs
† This path is present only in non-PBB-TE non-SPBM MHFs
Figure 19-3—MIP Half Function
Change the first paragraph in 19.4 as shown:
19.4 Maintenance Point addressing
The CFM entities within an MP use the Group addresses for CCM and LTM PDUs listed in Table 8-15 and
Table 8-16 and in the case of PBB-TE, SPBM, and ECMP path MAs, the Individual MAC Addresses or the
Group MAC addresses that are associated with the monitored TESIservices (20.1, 20.2, 20.3). In addition,
they recognize and in the case of PBB-TE, SPBM, and ECMP path MEPs use the Individual MAC address
Std 802.1Qbp-2014
of the port on which the MP is operating. This is the port on which the MP is configured, if the Bridge
created the MP using the Individual MP address model (J.6.1), and is a CFM Port, if the Bridge created the
MP using the Shared MP address model (J.6.2). CFM entities associated with a TESI may also use the ESP-
SA parameter in the tuple identifying the corresponding ESP.
Std 802.1Qbp-2014
20. Connectivity Fault Management protocols
20.1 Continuity Check protocol
Change the paragraph in 20.1 beginning with “Depending on the associated MA” as shown:
Depending on the associated MA, a CCM is carried
g) In a multicast frame, with a destination_address parameter chosen according to the transmitting

MEP’s MD Level, according to Table 8-15; or
h) In the case of a PBB-TE, SPBM, or ECMP associated MA, in a unicast or multicast frame with a
destination_address identified by the monitored MA.
The CCM does not generate a response. Therefore, in a networkan MA with n MEPs, n CCMs need to be
transmitted periodically, one from each MEP. Compared to a full mesh of point-to-point messages in terms
of frames carried on wires, multicast CCMs require less bandwidth than the point-to-point messages, except
of course for MAs with only two MEPs. And for each MEP, only one transmission and n – 1 receptions are
required, instead of n – 1 of each. In addition, even in MAs with only two MEPs, using multicast instead of
unicasts for CCMs obviates the need for configuration or discovery of those MEPs’ MAC addresses.
Insert the following paragraph at the end of 20.1:
An ECMP path MA is used to test multiple paths between a pair of endpoints. This type of MA has only two
MEPs, at two SPT Region boundary ports. An ECMP path MEP cycles through a set of flow hash values
intended to direct the CCM frames along (and thus test) different paths to the other MEP in the MA. The
path taken by CCM frames with a given flow hash depends on the current state of the network (i.e., paths are
subject to rerouting triggered by topology changes). Each flow hash is used in at least three consecutive
CCM frames so that a fault on a particular path will be detected and reported back via an RDI signal. To
avoid false positive or false negative detections of a loss of connectivity the rate of CCM transmission
should be greater than the maximum difference in latency between any pair of paths.
Change the first paragraph in 20.2 as shown:
20.2 Loopback protocol
The Loopback protocol is used for Fault verification and isolation. To verify the connectivity between MEPs
and MIPs, a MEP can be instructed by a system administrator to issue one or more LBMs. The LBM is
initiated by a MEP with specified destination_address, priority, and drop_eligible parameters, the
destination_address being the Individual MAC address of another MP within the same Maintenance
Association as the transmitting MEP. In the case of a PBB-TE and SPBM VID MAs, the
destination_address parameter for an LBM is always a MAC address associated with the terminating
CBP(s). In order to identify intermediate MHFs in the PBB-TE and SPBM VID MAs, an additional TLV,
the PBB-TE MIP TLV (21.7.5), is carried as the first TLV in an LBM, with the receiving MHF’s MAC
address in its MIP MAC address field (21.7.5.1). The receiving MP responds to the LBM with a Loopback
Reply (LBR).
Change the first paragraph in 20.2.1 as shown:
20.2.1 Loopback Message transmission
LBMs are transmitted by operator command as specified in 12.14.7.3. Each LBM transmitted contains a
Loopback Transaction Identifier field (21.7.3) that is incremented with each transmission. That enables the
Std 802.1Qbp-2014
transmitting MEP to correlate the returned LBRs with the transmitted LBMs. In a PBB-TE or SPBM VID
MA, a PBB-TE MIP TLV is carried by the transmitted LBM as the first TLV if the targeted MP is a MIP.
The MIP MAC address field (21.7.5.1) in the TLV is set to the destination_address parameter of the
appropriate managed object [item b) in 12.14.7.3.2]. The PBB-TE MIP TLV provides also the Reverse VID
field [21.7.5.2, item f) in 12.14.7.3.2] to be used in the VID field by a MIP transmitted LBR, and, when the
LBM is to be sent on a point-to-multipoint TESI, the Reverse MAC field (21.7.5.3) associated with MAC
addresses to be used by the LBR. The LBM can carry an arbitrary amount of data to help diagnose faults that
are sensitive to the amount or pattern of data in a frame [item d) in 12.14.7.3.2]. It can be sent with any
priority or drop_eligible parameters [item e) in 12.14.7.3.2].
20.2.2 Loopback Message reception and Loopback Reply transmission
When an LBM is received by an MP Loopback Responder (19.2.10), it may be examined for validity and
discarded if invalid. Whether or not the LBM is examined for validity, it shall be discarded if the
source_address is a Group and not an Individual MAC address. Also, if the destination_address does not
match the MAC address of the receiving MP, and the MP Loopback Responder does not reside in a PBB-TE
or SPBM VID MHF, the MP shall discard the LBM. If the receiving MP Loopback Responder resides in a
non-PBB-TE and non-SPBM VID associated MHF and the destination_address is a Group MAC address,
the MHF shall discard the LBM. If the MP Loopback Responder state machine resides in a PBB-TE MEP
and the received LBM carries a PBB-TE MIP TLV, the MEP shall discard the LBM. If the MP Loopback
Responder state machine resides in an SPBM VID MEP and the received LBM carries a PBB-TE MIP TLV,
the MEP may process the LBM if the MIP MAC address field matches the MEP’s address and shall
otherwise discard the LBM. PBB-TE and SPBM VID MHFs, forward all received LBMs and only stop and
process those that carry a PBB-TE MIP TLV containing in their MIP MAC address field the MAC address
of the receiving PBB-TE MIP [item f) in 20.28.1]. If the frame passes these tests, the receiving MP generates
an LBR and transmits it to the originating MEP. Every M_UNITDATA.indication (or
EM_UNITDATA.indication) parameter and octet in the mac_service_data_unit in the LBM is copied to the
LBR’s M_UNITDATA.request (or EM_UNITDATA.request) with the following exceptions:
20.2.3 Loopback Reply reception
When an LBR is received by an MHF (an anomalous occurrence), it is ignored, as the MIP has no receiving
entity for an LBR. When an LBR is received by a MEP Loopback Initiator (19.2.11), it is checked to see
whether the destination_address parameter matches the MAC address of the receiving MEP, and discarded
if not. Next it is checked to see whether its Loopback Transaction Identifier field matches that of a recently
transmitted LBM, and the appropriate counter incremented, either the in-sequence counter [item y) in
12.14.7.1.3] or the out-of-sequence counter [item z) in 12.14.7.1.3].
20.3 Linktrace protocol
Change the second paragraph in 20.3 as shown:
An LTM is transmitted by a MEP Linktrace Initiator in order to perform path discovery and fault isolation.
The LTM carries a target MAC address. It is carried in a frame, with a destination_address taken from
Table 8-16 according to the MD Level of the transmitting MEP, or the ESP-DA field of the appropriate ESP
in the case of a PBB-TE MA (20.31.1), or an individual or group address in the case of an SPBM VID MA,
and is relayed as such through the Bridged Network until it reaches an MP at the appropriate MD Level.
Std 802.1Qbp-2014
That MP intercepts the LTM and deflects it to a Bridge’s Linktrace Responder. The Linktrace Responder
determines whether its Bridge’s MAC Relay Entity would forward an ordinary data frame with the specified
target MAC address and vlan_identifier to an egress Bridge Port, or would filter or flood it. If the single
egress port is found, or if the receiving MP is the terminating MP, or if the MP is associated with a PBB-TE
MA or an SPBM VID MA, the Linktrace Responder sends a unicast Linktrace Reply (LTR) to the originator
of the LTM, whose MAC address was also carried as payload in the LTM. The LTR is sent after a random
delay in the range 0 < delay ≤ 1 s, to mitigate the load on the originating MEP. In addition, if the MP through
which the LTM was received was an MHF, the Linktrace Responder forwards an altered version of the LTM
in the direction of the target MAC address. The MEP Linktrace Initiator that originated the initial LTM
collects the LTRs. These provide sufficient information to construct the sequence of MPs that would be
traversed by a data frame sent to the target MAC address.
20.3.1 Linktrace Message origination
Change the third paragraph in 20.3.1 as shown:
In the case of a VID-based MA, the destination_address of an LTM is the Group MAC address reserved for
LTMs and appropriate to the MD Level of the originating MEP according to Table 8-16. In the case of a
PBB-TE MEP the destination_address of an LTM is the entry in the ESP-DA field of the 3-tuple of the
MA’s ESP that has the MEP’s MAC address in its ESP-SA field. In the case of an SPBM VID MEP, the
destination_address of an LTM is the Individual B-MAC address of a remote system or the SPBM Group
MAC address (27.15) associated with an I-SID associated with the source MEP.
Std 802.1Qbp-2014
20.4 Connectivity Fault Management state machines
Replace Figure 20-1 with the following figure:
BEGIN MEPactive
xconCCMreceived MEP CROSS CONNECT (one per MEP)

MEP CONTINUITY CHECK RECEIVER (one per MEP)
CCMreceivedEqual, CCMequalPDU, CCMreceivedLow, xconCCMreceived, xconCCMlastFailure,
CCMlowPDU, recvdMacAddress, recvdRDI, recvdInterval xconCCMdefects
recvdPortState, recvdInterfaceStatus, recvdFrame, rcvdTrafficBit MEP CROSS CONNECT TIMER
xconCCMwhile
recvdMacAddress, rec- rCCMreceived
vdRDI, recvdPortState, rec-
vdInterfaceStatus
REMOTE MEP (one per MEP per active remote MEP) errorCCMreceived
rMEPCCMdefect, rMEPlastRDI and rMEPlastRDI[i][],
rMEPlastPortState, REMOTE MEP ERROR (one per MEP)
rMEPlastInterfaceStatus, rCCMreceived, errorCCMreceived, errorCCMlastFailure,
CCMsequenceErrors, rMEPmacAddress, errorCCMdefect,
rMEPportStatusDefect, rMEPinterfaceStatusDefect
REMOTE MEP TIMER REMOTE MEP ERROR TIMER
rMEPwhile errorCCMwhile
rMEPCCMdefect, rMEPlastRDI
Npaths and rMEPlastRDI[i], errorCCMdefect xconCCMdefect
pathN rMEPportStatusDefect,
rMEPinterfaceStatusDefect
MEPCONTINUITY CHECK INITIATOR FAULT NOTIFICATION GENERATOR (one per MEP)
CCIenabled, CCIsentCCMs, fngPriority, fngDefect, fngAlarmTime, fngResetTime, someRMEPCCMdefect,
MACstatusChanged, flowHash[], someMACstatusDefect, someRDIdefect, highestDefectPri, highestDefect
Npaths, pathN FAULT GENERATION TIMER
MEP CC INITIATOR TIMER FNGwhile
CCIwhile
someRDIdefect
rcvdTrafficBit
MEP TRAFFIC FIELD MISMATCH (one per MEP) MEP LOCAL MISMATCH (one per MEP)
xconCCMreceived, mmCCMTime, disableLocdefect, mmLocdefect
mmCCMdefect
MEP TRAFFIC FIELD MISMATCH TIMER MEP LOCAL MISMATCH TIMER
mmCCMwhile mmLocwhile
mmCCMdefect mmLocdefect
MEP MISMATCH FAULT NOTIFICATION GENERATOR (one per MEP)

mfngAllowed, mmdefectIndication, fngAlarmTime, fngResetTime
MEP MISMATCH FAULT NOTIFICATION GENERATOR TIMER
mmFNGwhile
LINKTRACE INITIATOR (one per MEP) LOOPBACK INITIATOR TRANSMIT (one per MEP)
nextLTMtransID, ltmReplyList LBMsToSend, nextLBMtransID, LBIactive, xmitReady
LOOPBACK TRANSMIT TIMER

LBIwhile
LINKTRACE DATABASE (one per MEP)
expectedLBRtransID
MEP LINITRACE INITIATOR RECEIVE (one per MEP) LOOPBACK INITIATOR RECEIVE (one per MEP)
LTRreceived, LTRPDU expectedLBRtransID, LBRreceived, LBRPDU
Figure 20-1—MEP state machines—overview and relationships
Std 802.1Qbp-2014
20.9 MEP variables
Insert the following at the end of the introductory text in 20.9:
The following variable is present only in ECMP path MAs, is local to a single ECMP path MEP, and is
accessible by more than one state machine:
l) EpMEP (20.9.12).
Insert 20.9.12 after 20.9.11:
20.9.12 EpMEP
Boolean. This variable is used to condition actions related to ECMP path MEPs. It is true for ECMP path
MEPs and false otherwise.
20.10 MEP Continuity Check Initiator variables
Change the introduction to 20.10 as shown:
The following variables are local to the MEP Continuity Check Initiator state machine:
a) CCIenabled (20.10.1);
b) CCIsentCCMs (20.10.2); and
c) MACstatusChanged (20.10.3);
d) Npaths (20.10.4);
e) flowHash[] (20.10.5);
f) pathN (20.10.6); and
g) CCMcnt (20.10.7).
Insert 20.10.4 through 20.10.7 after 20.10.3:
20.10.4 Npaths
Integer value. The number of paths being tested by this MEP. The value is 1 (default) except in the case of
ECMP path MEPs that may test a set of paths by using one destination address and different flow hash
values.
20.10.5 flowHash[ ]
This variable is only applicable for ECMP path MEPs.
Array of 16-bit values. A set of flow hash values used to test a set of paths to a given destination address.
The default is a single NULL value.
20.10.6 pathN
Integer value in the range 0..(Npaths-1) and all arithmetic using this variable is modulo Npaths. The index of
the current path (flow hash) being used in CCMs sent from the MEP. This value is shared with the Remote
MEP state machine to enable correlation of received RDIs with the cycle of paths being tested.
Std 802.1Qbp-2014
20.10.7 CCMcnt
Integer value in the range 0..3 and all arithmetic using this variable is modulo 4. This variable is a counter
used to send each flowHash[] value in four successive CCMs.
20.11 MEP Continuity Check Initiator procedures
20.11.1 xmitCCM()
xmitCCM() constructs and transmits a CCM on the Active SAP using an M_UNITDATA.request as
follows. xmitCCM():
a) Sets the destination_address parameter to the value from Table 8-15 corresponding to the MEP’s
MD Level. In the case of a PBB-TE associated MEP, SPBM path MEP, or ECMP path MEP, the
destination_address parameter is set to the MAC address indicated by the ESP-DA field of the ESP
having in its ESP-SA field the MAC address of the MEP. In the case of an SPBM VID MEP
(27.18.1) the destination_address parameter is set to the SPBM Group MAC address (27.15)
associated with the source MEP and the SPBM default I-SID. In the case of an SPBM group MEP
the destination_address parameter is set to the SPBM Group MAC address (27.15) assigned to the
source MEP’s CBP for the SPBM group MA’s I-SID;
b) Sets the source_address parameter to the MAC address of the MEP [item i) in 12.14.7.1.3];
c) Sets the priority parameter according to the MEP’s managed objects [item h) in 12.14.7.1.3];
d) Sets the drop_eligible parameter to false;
e) In the case of ECMP with flow filtering, the time_to_live and flow_hash parameters must be set.
The time_to_live parameter is set to the TTL Value in the Flow Filtering Control Table entry on the
CBP for the source MEP’s VID [item d) in 12.16.5.5.2]. In the case of an SPBM VID MEP or
SPBM group MEP the flow_hash parameter is set to zero. In the case of an ECMP path MEP, the
flow_hash parameter is set to the value of flowHash[pathN];
f) Places the MEP’s MD Level (20.7.1) in the MD Level field (21.4.1);
g) Fills the CCM Interval field (21.6.1.3) with the CCM transmission interval (20.8.1, item e) in
12.14.6.1.3);
h) Fills the RDI field (21.6.1.1) with the presentRDI variable (20.9.6);
i) Should copy CCIsentCCMs (20.10.2) to the Sequence Number field of the CCM (21.6.3), else
copies 0 into that field;
j) Places the MEP’s MAID into the appropriate fields of the CCM [item a) in 12.14.1.2.2, item b) in
12.14.5.3.2, and 21.6.5.1 through 21.6.5.6];
k) Places the MEP’s MEPID [item g) in 12.14.6.1.3] into the Maintenance association End Point
Identifier field (21.6.4);
l) As controlled by the managed objects item e) in 12.14.3.1.3, item d) in 12.14.5.1.3, and item d) in
12.14.6.1.3, places a Sender ID TLV (21.5.3) in the CCM, identifying the transmitting system;
m) Optionally, places a Port Status TLV (21.5.4) in the CCM, reporting the status of the Bridge Port;
n) Optionally, places an Interface Status TLV (21.5.5) in the CCM, reporting the status of the Bridge
Port; and
o) Increments CCIsentCCMs by 1, wrapping around from 232 – 1 to 0;
p) Only in the case of a PBB-TE MEP, optionally fills the Traffic field (21.6.1.4) with the
presentTraffic variable (20.9.8); and
q) Only in the case of an Infrastructure Segment MEP, optionally fills the Traffic field (21.6.1.4) with
the value ISpresentTraffic (20.9.10).
Std 802.1Qbp-2014
20.12 MEP Continuity Check Initiator state machine
Change Figure 20-2 as shown:
BEGIN || !MEPactive
CCI_IDLE
k = 0;
if (EpMEP) {pathN=0}
CCIenabled
CCI_WAITING
xmitCCM();
CCIwhile = CCMtime (CCMinterval);
MACstatusChanged = false;
if (EpMEP) {pathN = pathN+CCMcnt/3;
CCMcnt = CCMcnt+1}
CCIenabled && !CCIenabled

(MACstatusChanged
|| (CCIwhile == 0))
Figure 20-2—MEP Continuity Check Initiator state machine
20.17 MEP Continuity Check Receiver procedures
20.17.1 MEPprocessEqualCCM()
Change item b) in 20.17.1 as shown:

b) Otherwise, if the MAID of the received CCM does not exactly match the MAID configured in the
receiving MEP [item a) in 12.14.1.2.2, item b) in 12.14.5.3.2], then MEPprocessEqualCCM() sets
xconCCMreceived (20.23.1) true (this procedural step being optional in the case of a PBB-TE MEP,
SPBM path MEP, or ECMP path MEP), reconstructs the frame containing the CCM into
recvdFrame, and places a timer counter value into recvdInterval corresponding to the value of the
CCM Interval field in the received CCM.
20.19 Remote MEP variables
Change 20.19 as shown:
The following variables are local to the Remote MEP state machine:
a) rMEPCCMdefect (20.19.1);
b) rMEPlastRDI and rMEPlastRDI[i] (20.19.2);
c) rMEPlastPortState (20.19.3);
d) rMEPlastInterfaceStatus (20.19.4);
e) rMEPlastSenderId (20.19.5);
f) rCCMreceived (20.19.6);
g) rMEPmacAddress (20.19.7);
h) rMEPportStatusDefect (20.19.8); and
i) rMEPinterfaceStatusDefect (20.19.9); and
j) lastPathN (20.19.10).
Std 802.1Qbp-2014
20.19.2 rMEPlastRDI and rMEPlastRDI[i]
Boolean flag. Contains the RDI flag from the last-received CCM. This variable is readable as a managed
object [item e) in 12.14.7.6.3]. In the case of an ECMP path MEP, if Npaths > 1 there is a set of variables
rMEPlastRDI[i] of size Npaths (20.10.4). In this case the variable rMEPlastRDI is the logical OR of the
members of the set rMEPlastRDI[i]. Each member of the set rMEPlastRDI[i] is set if an RDI is received
while pathN == i and is reset if no RDI is received while pathN == i in the last CCM cycle of the MEP
Continuity Check Initiator state machine.
Insert 20.19.10 after 20.19.9:
20.19.10 lastPathN
Integer value. The variable lastPathN holds the previous value of the pathN variable.
Std 802.1Qbp-2014
20.20 Remote MEP state machine
The Remote MEP state machine implements the function specified by the state diagram in Figure 20-5 and
the variable declarations in 20.19, and utilizes the procedures in 20.17.
Change Figure 20-5 as shown:
BEGIN || !MEPactive || !enableRmepDefect
RMEP_IDLE
rMEPCCMdefect = false;
rMEPwhile = 0;
UCT
RMEP_START
rCCMreceived = false;
rMEPwhile = 3.5 ∗ CCMtime (CCMinterval);
rMEPmacAddress = FF-FF-FF-FF-FF-FF;
rMEPlastRDI = false;
if (EpMEP) {lastPathN = 0}
rMEPlastPortState = psNoPortStateTLV;
rMEPlastInterfaceStatus = isNoInterfaceStatusTLV;
rMEPlastSenderId = isNoSenderIdTLV;
rCCMreceived && rMEPwhile == 0
rMEPwhile != 0
RMEP_FAILED
rMEPCCMdefect = true;
rCCMreceived
RMEP_OK
rCCMreceived = false;
rMEPCCMdefect = false;
rMEPwhile = 3.5 ∗ CCMtime (CCMinterval);
rMEPmacAddress = recvdMacAddress;
if (Npaths==1) rMEPlastRDI = recvdRDI;
if (EpMEP && Npaths>1) {
if (lastPathN != pathN) { rMEPlastRDI[pathN] = recvdRDI}
if (lastPathN == pathN) {
rMEPlastRDI[pathN] = rMEPlastRDI[pathN] | recvdRDI}
lastPathN = pathN }
rMEPlastPortState = recvdPortState;
rMEPlastInterfaceStatus = recvdInterfaceStatus;
rMEPlastSenderId = recvdSenderId;
rCCMreceived && rMEPwhile == 0

rMEPwhile != 0
Figure 20-5—Remote MEP state machine
20.28 MP Loopback Responder procedures
20.28.1 ProcessLBM()
Called by the MP Loopback Responder state machine whenever an LBM is received. ProcessLBM()
processes the LBM in LBMPDU as follows:
Std 802.1Qbp-2014
a) If
1) the destination_address parameter contains an Individual MAC address that does not match the
MAC address of the receiving MP; and
2) the MP Loopback Responder state machine does not reside in a PBB-TE or SPBM VID MHF;
ProcessLBM() discards the LBM and performs no further processing;
b) If the destination_address parameter contains a Group address and the MP Loopback Responder
state machine resides in a non-PBB-TE associatedan MHF associated with neither PBB-TE nor
SPBM (rather than in a MEP), ProcessLBM() discards the LBM and performs no further processing;
c) If the source_address parameter is a Group, and not an Individual MAC address, ProcessLBM()
discards the frame and performs no further processing.
d) ProcessLBM() shall process the LBM according to 20.51.4.2, and may validate the LBM according
to 20.51.4.3, and discard any frames that fail the validation;
e) If the MP Loopback Responder state machine resides in a PBB-TE MEP and the LBM carries a
PBB-TE MIP TLV, ProcessLBM() discards the LBM and performs no further processing;
f) If the MP Loopback Responder state machine resides in a PBB-TE or SPBM VID MHF and;
1) There is no PBB-TE MIP TLV; or
2) There is a PBB-TE MIP TLV but the address carried in the MIP MAC address field does not
match the MAC address of the receiving MIP;
ProcessLBM() forwards the LBM to the Passive MHF Multiplexer and performs no further
processing;
g) Otherwise, ProcessLBM() calls xmitLBR() to generate and transmit an LBR.
20.28.2 xmitLBR()
Insert item d) after item c) in 20.28.2, renumbering subsequent items as needed:

d) In the case of ECMP with flow filtering, the flow_hash parameter is set to zero and the time_to_live
parameter is set to 63;
20.31 MEP Loopback Initiator transmit procedures
20.31.1 xmitLBM()
xmitLBM() is called by the MEP Loopback Initiator transmit state machine. It constructs and transmits an
LBM on the Active SAP using an M_UNITDATA.request as follows. xmitLBM():
a) Sets the destination_address parameter from the appropriate managed object [item b) in 12.14.7.3.2]
or in the case of an SPBM VID MEP [item g) in 12.14.7.3.2]. If the MEP is configured on a PBB-TE
MA, the destination_address parameter is set to the MAC address indicated by the value of the ESP-
DA field of the MA’s ESP that has the MEP’s MAC address indicated in its ESP-SA field;
b) Sets the source_address parameter to the MAC address of the MEP [item i) in 12.14.7.1.3];
c) Sets the priority and drop_eligible parameters from the appropriate managed object [item e) in
12.14.7.3.2];
d) In the case of ECMP with flow filtering, the flow_hash parameter is set from the appropriate
managed object [item h) in 12.14.7.3.2] and the time_to_live parameter is set to 63;
e) Copies nextLBMtransID (20.30.2) to the Loopback Transaction Identifier field (21.7.3) of the LBM;
f) If the MEP is configured on a PBB-TE MA, constructs a PBB-TE MIP TLV using in the MIP MAC
address field the destinationtarget address parameter from the appropriate managed object [item b)
in 12.14.7.3.2] and in the Reverse VID field the parameter [item f) in 12.14.7.3.2]; if the MEP is a
root in a point-to-multipoint TESI, the Reverse MAC field is also included in the PBB-TE MIP TLV
carrying the ESP-SA value of any of the MA’s point-to-point ESPs; if the MEP is a leaf in a point-to-
multipoint TESI, the Reverse MAC field carries the ESP-DA of the point-to-multipoint ESP; the
Std 802.1Qbp-2014
PBB-TE MIP TLV is not used if the LBM destinationtarget address in 12.14.7.3.2 is associated with
any of the values in the ESP-DA field of the monitored MA’s ESPs;
g) If the MEP is configured on an SPBM VID MA, constructs a PBB-TE MIP TLV using in the MIP
MAC address field the target address parameter from the appropriate managed object [item b) in
12.14.7.3.2];
h) Constructs a Data TLV from the appropriate managed object [item d) in 12.14.7.3.2] if and only if
that managed object has a nonzero length;
i) As controlled by the managed objects item e) in 12.14.3.1.3, item d) in 12.14.5.1.3, and item d) in
12.14.6.1.3, places a Sender ID TLV (21.5.3), identifying the transmitting system, in the LBM; and
j) Increments nextLBMtransID (20.30.2) by 1, wrapping around from 232 – 1 to 0.
20.42 MEP Linktrace Initiator procedures
20.42.1 xmitLTM()
xmitLTM() is called whenever the Transmit Linktrace Message management operation (12.14.7.4) is
invoked. It constructs and transmits an LTM on the Active SAP, or on the MEP LTI SAP if the operation is
invoked on an Up MEP, using an M_UNITDATA.request as follows. xmitLTM():
a) Sets the destination_address parameter to the value from Table 8-16 corresponding to the MEP’s
MD Level. If the MEP is configured on a PBB-TE MA, the destination_address parameter is the
MAC address indicated by the value of the ESP-DA field of the MA’s ESP that has the MEP’s MAC
address indicated in its ESP-SA field. If the MEP is configured on an SPBM VID MA, the
destination_address parameter is set to the value configured in the LTM management request [item
f) in 12.14.7.4.2];
b) Sets the source_address parameter and Original MAC Address field (21.8.5) to the MAC address of
the MEP [item i) in 12.14.7.1.3];
c) If the MEP is configured on a PBB-TE MA, constructs a PBB-TE MIP TLV using in the MIP MAC
address field a null field and in the Reverse VID field the parameter [item e) in 12.14.7.4.2]; if the
MEP is a root in a point-to-multipoint TESI, the Reverse MAC field is also included in the PBB-TE
MIP TLV carrying the ESP-SA value of any of the MA’s point-to-point ESPs; if the MEP is a leaf in
a point-to-multipoint TESI, the Reverse MAC field carries the ESP-DA of the point-to-multipoint
ESP;
d) In the case of ECMP with flow filtering, the flow_hash parameter is set to the value specified in the
appropriate managed object [item g) in 12.14.7.4.2] and the time_to_live parameter is set to 63;
e) Sets the priority parameter to the same value as for CCMs [item h) in 12.14.7.1.3];
f) Copies nextLTMtransID [item ab) in 12.14.7.1.3] to the LTM Transaction Identifier field (21.8.3) of
the LTM;
g) Sets the LTM Egress Identifier TLV (21.8.8) to a value that is unique among all Bridges in the
Management Domain.
h) Sets the Target MAC Address field (21.8.6) from the appropriate managed object [item c) in
12.14.7.4.2];
i) Sets the LTM TTL field (21.8.4) from the appropriate managed object [item d) in 12.14.7.4.2];
j) Sets the UseFDBonly bit of the Flags field (21.8.1) from the appropriate managed object [item b) in
12.14.7.4.2], and sets all other bits of the Flags field to 0;
k) As controlled by the managed objects item e) in 12.14.3.1.3, item d) in 12.14.5.1.3, and item d) in
12.14.6.1.3, places a Sender ID TLV (21.5.3), identifying the transmitting system, in the LTM;
l) Creates a new entry in the ltmReplyList variable (20.41.2) for this LTM, identified by the LTM
Transaction Identifier in nextLTMtransID (20.41.1); and
m) Increments nextLTMtransID (20.41.1) by 1, wrapping around from 232 – 1 to 0.
Std 802.1Qbp-2014
If the addition of this LTM entry would exceed the resources allocated to ltmReplyList, then the oldest LTM
entries in ltmReplyList are deleted until sufficient resources are available to hold the new LTM entry.
20.47 LTM Receiver procedures
20.47.1 ProcessLTM()
Change item c) in 20.47.1 as shown:

c) Otherwise, if the vlan_identifier identifies an ESP-VID or SPBM VID the LTM is valid, and no
further validation steps are performed.
Change 20.47.1.2 as shown:
20.47.1.2 Ingress Port, vlan_identifier, and Egress Port determination
In 20.3.2 and Figure 20-16, case a) through case e) all require ProcessLTM() to determine the Ingress and
Egress Ports for this received LTM. The Ingress Port is the Bridge Port on which the LTM entered the
Bridge, whether through a MEP, an MHF, or an LOM. In case d), where an LTM is generated by an Up
MEP and passed through a MEP LTI SAP to the Linktrace Responder, the Ingress Port is the Bridge Port of
the originating MEP.
If received from an EISS SAP, the vlan_identifier of the received LTM is included in the
EM_UNITDATA.indication. If received from an ISS SAP, the vlan_identifier of the received LTM is that
configured in the MEP, MHF, or LOM that received the LTM, or if none, is the PVID (6.6.1) of the Ingress
Port.
The Egress Port is the Bridge Port on which a data frame whose destination_address is equal to the Target
MAC Address carried in the LTM, or in the case of an MP associated with a PBB-TE MA, the
destination_address of the LTM, and whose vlan_identifier matched that of the LTM, would be forwarded.
This determination is made in two steps:
a) ProcessLTM() first queries the Filtering Database (8.8). The set of potential transmission ports,
normally created by Active topology enforcement (8.6.1), is the set of all Bridge Ports that are both
in the active set of the vlan_identifier of the LTM and that are in the Forwarding state for that
vlan_identifier, except that the Ingress Port is excluded from the set. The query uses the Target
MAC Address field of the LTM as the destination_address of the lookup, the Original MAC
Address field of the LTM as the source_address, and the vlan_identifier of the LTM. In the case of
an MP associated with a PBB-TE or SPBM VID MA, the query uses the destination_address and the
vlan_identifier of the LTM as the corresponding parameters for the lookup. If the MP is associated
with ECMP with flow filtering, the query uses the flow_hash parameter in the lookup process, when
required. The output from this query is a (perhaps reduced) set of potential transmission ports. If the
resultant set contains one and only one Bridge Port, that Bridge Port is the Egress Port, and item b) is
not performed. If the resultant set contains more than one Bridge Port, and the MP is associated with
a PBB-TE MA, those Bridge Ports are all Egress Ports, and step b is not performed.
NOTE 1—If there are only two Bridge Ports that are members of the VID’s member set, the Ingress Port was one of
those two Bridge Ports, and the Ingress Port is not connected to a shared medium, then this step can identify the Egress
Port even if the Filtering Database is not used for this vlan_identifier.
NOTE 2—This query cannot produce an Egress Port that is the same as the Ingress Port, since the Ingress Port is not
included in the set of potential transmission ports.
b) If the Filtering Database could not produce a unique Egress Port, and the MPs serving the
vlan_identifier of the LTM are maintaining a MIP CCM Database, and the UseFDBonly bit of the
Flags field of the LTM is 0, then ProcessLTM() queries the MIP CCM Database to see whether the
Std 802.1Qbp-2014
target MAC address and vlan_identifier have been retained in that database. If so, and if the Port
number in the MIP CCM Database is not the same as the Ingress Port, that Port number identifies the
Egress Port.
It is possible that neither of these two steps are able to determine the Egress Port; when a unique Egress Port
cannot be determined, an LTM is never forwarded by non-PBB-TE MHFsMHFs other than PBB-TE MHFs
or SPBM VID MHFs. PBB-TE MHFs associated with point-to-multipoint TESIs forward LTMs even if
multiple Egress Ports are identified. MHFs associated with SPBM VID MAs forward group addressed
LTMs even if multiple Egress Ports are identified.
20.47.3 ForwardLTM()
Insert item e) after item d) in 20.47.3, renumbering subsequent items as needed:

e) In the case of ECMP with flow filtering, the flow_hash parameter and the time_to_live parameter of
the forwarded LTM are set to values presented with the received LTM.
20.47.4 enqueLTR()
Insert item e) after item d) in 20.47.4, renumbering subsequent items as needed:

e) In the case of ECMP with flow filtering, the flow_hash parameter is set to zero and the time_to_live
parameter is set to 63.
Std 802.1Qbp-2014
22. Connectivity Fault Management in systems
22.2 Maintenance Entity creation
22.2.2 Creating MEPs
There are four kinds of Maintenance Association managed objects: those that are attached to one or more
specific VIDs in the Bridge, those that are attached to no VID, those that are attached to an I-SID, and those
that are attached to a TESI or ECMP path.
Once the appropriate Maintenance Domain and MA have been created, a MEP can be created, modified, or
deleted using the MA managed object defined in 12.14.6. MEPs are always created explicitly. MEP creation
is controlled by creating a Maintenance association End Point managed object using the following
parameters:
a) Whether the MA to which the MEP belongs is associated with specific VID(s), I-SID, or TESI, or
ECMP path, and if so, which parameters [item b) in 12.14.6.1.3], including a specification of the
MA’s Primary VID [12.14.7.1.3:d];
b) Whether the MEP is a Down MEP (pointing away from the MAC Relay Entity), or an Up MEP,
(pointing toward the MAC Relay Entity) [item c) in 12.14.6.3.2].
Given those two values in the MEP managed object, Table 22-1 shows where, in Figure 22-9, the MEP is
created. In Figure 22-9, which shows a PNP or a CNP, the VID selects which of the MEP positions is
selected for Table 22-1 column 3 values 1 and 4. Only one row of MEPs is shown in positions 1, 4, and 5,
even though up to eight rows can exist at each of these points. Because the MEPs are always placed in order
by MD Level, with the highest MD Level nearest the MHFs, at the center of each stack, there is thus no
ambiguity. The third column, starting from the left, in the EISS Multiplex Entity depicted in Figure 22-9
corresponds to an ESP-VID or SPBM VID. Only MIPs can be placed in this column for a PNP. MEPs can be
created on a CBP and PIP as shown in Figure 26-2.
Table 22-1—MEP creation
MA has VID MEP direction Position of MEP

[item b) in 12.14.6.1.3] [item c) in 12.14.7.1.3] in Figure 22-9
Yes Up 1
Down 4
No Up disallowed
Down 5
If any MEPs are configured on an MA, then in any given Bridge, either all of those MEPs are Up MEPs or
all of them are Down MEPs; a Bridge refuses to create an Up (Down) MEPs if a Down (Up) MEP already is
configured in that MA in that Bridge. An MA can be configured with Up MEPs in one Bridge and Down
MEPs in another Bridge or Station. Any given VID can be configured on any number of MAs (including
zero) containing either Down MEPs or no MEPs at all, plus zero or one MA containing Up MEPs. No VID
can be configured on more than one MA on which are configured Up MEPs.
Std 802.1Qbp-2014
The Forwarding Process (8.6) LLC

EISS Multiplex Entity (6.17)
1
2
Port filtering entities
3
4
Bridge Port Transmit and Receive (8.5)
5
IEEE 802.n
LAN
Figure 22-9—Creating MEPs and MIPs
These restrictions, along with the configuration errors in 22.2.4, enable MEPs to be configured so that they
bound an MA, no matter what action is taken by the spanning tree protocols within a Maintenance Domain.
Std 802.1Qbp-2014
27. Shortest Path Bridging (SPB)
Change the introductory text in Clause 27 as shown:
Shortest path bridging (SPB) provides shortest path communication for user data frames in Shortest Path
Tree (SPT) regions (Clause 3). ISIS-SPB interoperates with MSTP and RSTP (Clause 13) and STP
(Clause 8 of IEEE Std 802.1D, 1998 Edition), exchanging BPDUs to determine the extent of each SPT
Region and to configure full, simple, and symmetric connectivity throughout a network comprising
arbitrarily interconnected bridges and individual point-to-point LANs (13.6, 13.7). IS-IS supports point to
point links and shared LANs however only point to point is considered for ISIS-SPB in this specification. A
future revision may add shared media. The Clause 13 SPB description allows for both point to point links
and shared media.
Within an SPT Region (7.4, 13.6), the active topology that supports the frames for any given Base VID can
be chosen (27.4) by the network administrator to be one of the following:
— The internal spanning tree (IST), or

— A multiple spanning tree instance (MSTI), or
— A set of Traffic Engineered service instances (TESIs), or
— A set of shortest path trees (SPT Set), one SPT rooted at each SPT Bridge and supporting frames
transmitted into the region through that bridge, or
— Multiple equal cost unicast paths and multicast trees that spread traffic rooted at each SPT Bridge
over multiple shortest path trees. This ECMP connectivity is only supported by SPT Bridges using
SPBM mode.
Clause 28 specifies the use of ISIS-SPB to calculate the IST and multiple SPT Sets (supporting different
ECTs) within an SPT Region. Clause 13 specifies the use of MSTP to calculate MSTIs, and state machines
that use the results provided by ISIS-SPB for each SPT to prevent loops within and between regions while
maintaining or recovering connectivity as the network reconfigures (13.12, 13.14–13.40, 27.5). The
umbrella term ISIS-SPB refers to the coordinated use of the protocols and algorithms specified in Clause 28
and Clause 13 to support shortest path bridging.
To allow SPB to support plug-and-play operation for some VLANs, while providing the administrative
controls and scalability required for large scale operations, this standard specifies two complementary
modes of SPT Bridges (SPBV and SPBM) for assigning each shortest path bridged frame to the correct SPT.
All the bridges in a given SPT Region agree on the method to be used to support any given VLAN.
Subclause 27.18 describes network scenarios that use one or both of these methods.
If a VLAN is supported by an SPT Bridge using SPBV mode, Shortest Path VIDs (SPVIDs) are
automatically allocated by ISIS-SPB and used in VLAN tags within an SPT Region. Each SPVID identifies
both the VLAN and the SPT supporting transmission of a tagged frame, and Dynamic VLAN Registration
Entries are created to provide connectivity while preventing loops (13.38.2). The SPVIDs for a given VLAN
use a single FID that is associated with the Base VID for that VLAN (Shared VLAN Learning, 7.5, 8.8.8).
VID translation (6.9) at the region boundary (7.4, 13.5, 13.12) maps SPVIDs to and from the associated
Base VID.
If a VLAN is supported by an SPT Bridge in SPBM mode without ECMP, the Base VID is used in each
frame’s VLAN tag within the SPT Region and identifies the VLAN and the SPT Set. Each bridge mitigates
and prevents loops (6.5.4, 13.38.2) by using the source and destination MAC Address of each frame with
Dynamic Filtering Entries for the Base VID, MAC Address tuples. The source MAC Address identifies the
particular SPT from the SPT Set, and supports active topology enforcement (13.38.2, 8.6.1). When
forwarding unicast frames it is not necessary to consider the particular SPT since all the SPTs in a given set
transiting a given bridge en route to a destination take the same path from that given bridge to the destination
Std 802.1Qbp-2014
(in other words they are all reverse path congruent with the SPT rooted at that destination). Therefore for
unicast frames the destination MAC address is used for egress filtering as normal. SPT Bridging using
SPBM mode requires the use of SPT specific destination Group MAC Addresses, so loop-free multicast
forwarding is also supported without requiring the source MAC Address or source Bridge Port to be part of
the Filtering Database query. ISIS-SPB automatically allocates SPSourceIDs (27.10) that are used as part of
each Group Address. Since an SPT Bridge using SPBM mode inspects source MAC Addresses as a loop
mitigation mechanism, those addresses have to be known before forwarding can take place and are
advertised using ISIS-SPB. Learning of B-MAC addresses is not enabled when SPBM mode is used, and
frames destined for unknown addresses are discarded and not flooded. The Individual MAC Addresses used
are those of the SPT Bridges themselves, or are associated with functions provided by Provider Bridges or
Backbone Edge Bridge (BEB) functions that include an SPT Bridge component. SPBM group multicast
addresses are local to the SPT Bridge domain [using the Locally administered (U/L) address MAC address
flag (IEEE-802 2001)], so the use of SPT specific Group MAC addresses does not intrude on the well
known global multicast space.
With ECMP (Clause 44), ISIS-SPB can configure multiple potential forwarding Ports for each individual
MAC address and forwarding port selection is performed dynamically. Forwarding Port selection is
controlled by a deterministic hash function whose inputs are the SPB System Identifier and the Flow Hash
carried in an F-TAG. This tends to spread traffic flows over the set of equal cost paths between the source
Bridge and destination Bridge in the SPT Region while preserving frame ordering of individual flows. As a
substitute for the loop prevention and mitigation techniques mentioned above, an alternative loop quenching
mechanism for ECMP is realized with a time-to-live (TTL) field included in the F-TAG. With ECMP,
bidirectional and unicast-multicast congruence is no longer guaranteed (since there is no longer a single path
in use between a source and destination). This enables each BSI group address to be independently routed
and multicast traffic to be spread over a set of equal cost SPTs.
ISIS-SPB uses the same mechanism to allocate SPVIDs (for SPBV) and SPSourceIDs (for SPBM) (27.10).
The MST Configuration Identifier (MCID) (8.9, 13.8) is used to ensure that all the bridges in an SPT Region
agree on the method used to support each shortest path VLAN and on the pool of SPVIDs, as well as on the
other uses of VIDs (27.4). An SPSourceID is allocated to each bridge in an SPT Region, independently of
SPBM mode VLANs, while an SPVID for a given SPBV VLAN is only allocated to the SPT rooted at a
given bridge if VLAN Registration Entries and controls allow that bridge to transmit frames assigned to that
VLAN into the region (8.8, 13.6).
An SPT Bridge using SPBV mode is typically used to support a C-VLAN or S-VLAN for a single customer.
An SPT Bridge using SPBM mode is typically used to support B-VLANs in Provider Backbone Bridged
Networks (Clause 25). Each B-VLAN can support many backbone service instances, each requiring
connectivity between a subset of the BEBs participating in the B-VLAN, and each identified by an I-SID
that is not processed by Backbone Core Bridges (BCBs). An SPT Bridge using SPBM mode does not use
source address learning, so unicast B-MAC frames conveying customer data are never flooded throughout
the B-VLAN. Multicast frames and flooding of unknown unicast frames for a given backbone service
instance are confined to paths that reach the BEBs supporting that service instance by including the I-SID in
the SPT specific destination Group MAC Addresses (Figure 27-3). The destination address filtering in each
BCB prunes transmission of the encapsulated customer multicast frames as well as preventing loops.
MVRP (11.2) is not used within SPT Regions, as ISIS-SPB communicates VLAN registration information
for VLANs supported by SPB from the SPT Bridges that provide ingress to and egress from the region to the
other bridges, thus allowing SPT Bridges using SPBV and SPBM to configure Dynamic VLAN Registration
Entries for Bridge Ports within the region to provide correct VLAN connectivity when SPTs are
recalculated—instead of waiting for registration information to propagate on those SPTs. SPT Bridges can
use the registration information communicated within the SPT Region to participate in MVRP with bridges
outside the region (27.13) by supporting MVRP interfaces on the Region boundaries.
Std 802.1Qbp-2014
This clause specifies the following:
a) Protocol design and support requirements (27.1, 27.2) and design goals (27.3).
This clause further specifies how:
b) Each bridge’s configuration mechanisms specify the supporting method (SPBV, SPBM, MSTI,
CIST, or PBB-TE) and SPT Set (for SPBV and SPBM) for each VLAN (27.4).
c) The boundaries of each SPT Region and ISIS-SPB adjacencies are determined dynamically by ISIS-
SPB (Clause 28).
d) The information exchanged by ISIS-SPB is used (27.5), including CIST calculation (27.6, 27.7),
SPT calculations (27.8), allocating SPVIDs and SPSourceIDs (27.10), and controlling the
connectivity supporting each VLAN (27.13) and Backbone Service Instance (27.15, 27.16).
e) The results of ISIS-SPB’s CIST and SPT calculations are used by the Clause 13 state machines to
determine when to discard frames to ensure the calculated trees are loop-free (27.9).
f) SPVIDs are allocated to FIDs (27.11) and translated to and from Base VIDs at the boundary of an
SPT Region (6.9, 13.6).
g) VLAN Registration Entries are used to forward or discard frames for each VLAN (27.13).
h) Filtering Database (FDB) entries for Individual Addresses are used to prevent or mitigate loops for
VLANs supported by SPBM (27.14).
i) SPBM Group Addresses are assigned, and FDB entries for those addresses used to forward or
discard frames for each backbone service instance for B-VLANs supported by SPBM (27.15,
27.16).
j) The SPT calculations choose between equal cost trees (ECTs), making different choices for different
SPT Sets, each associated with a different VLAN, enabling load spreading (27.17, 28.9.2).
This clause also:
k) Provides examples of when and how SPT Bridges using SPBV and SPBM modes can be used
(27.18).
27.1 Protocol design requirements
Change 27.1 as shown:
ISIS-SPB configures entries in each SPT Bridge’s Filtering Database (8.8) to meet the following
requirements:
a) The active topology will fully connect all physically connected LANs and bridges, and stabilize
(with high probability) within a short, known bounded interval after any change in the physical
topology, maximising service availability (8.4).
b) TExcept in the case of ECMP, the active topology for any given frame remains simply connected at
all times (6.5.3, 6.5.4).
c) The same symmetric active topology is used, in a stable network, for all frames for the same VLAN,
i.e., between any two individual LANs those frames are forwarded through the same Bridge Ports.
d) The active topology supporting a given VLAN within an SPT Region can be chosen by the network
administrator to be shortest path, the IST, or an MSTI.
e) Each active topology is predictable and reproducible, and may be influenced by management, thus
allowing the application of Configuration Management following traffic analysis, to meet the goals
of Performance Management (6.5 and 6.5.10).
f) The configured network can support VLAN-unaware end stations, such that they are unaware of
their attachment to a single LAN or a bridged network, or their use of a VLAN (6.3).
Std 802.1Qbp-2014
g) The SPB mode, SPBV or SPBM, can be chosen by the network administrator independently for
each VLAN using shortest paths.
SPBV mode meets the following requirements:
h) No additional constraint is placed on the values of the Individual or Group MAC Addresses used,
and those addresses do not have to be known before being used in data frames.
i) SPVIDs are allocated to every SPT Bridge that is a potential source of frames on VLANs supported
by SPBV.
j) Filtering database entries for a given SPVID will only be populated if they are on the shortest path to
a participating boundary node.
SPBM mode meets the following requirements:
k) Multicast flooding for each backbone service instance supported by a PBBN is restricted to paths
necessary to reach BEBs supporting that service instance.
l) ECMP operation enables multiple equal cost paths in the SPT Region to carry a share of unicast and
multicast traffic.
NOTE—The ECMP ECT Algorithm supports multicast load spreading over up to 16 source trees per node and up to 16
shared trees.
Additionally, SPB algorithms and protocols meet the following goals, which limit the complexity of Bridges
and their configuration:
m) The memory requirements associated with each Bridge Port are either a constant or a linear function
of the number of Bridges and LANs in the network.
n) The communications bandwidth consumed by ISIS-SPB on any particular LAN is always a small
fraction of the total available bandwidth (6.5.10).
o) Bridges do not have to be individually configured before being added to a network, other than
having their MAC Addresses assigned through normal procedures.
27.8 Calculating SPT connectivity
Change the introductory text in 27.8 as shown:
Each SPT Bridge uses ISIS-SPB to calculate the shortest paths from each of the bridges (27.6(h)) in its own
SPT Region including itself, to each of the other bridges in that region. The information used by ISIS-SPB to
perform the necessary Dijkstra calculations is a subset of that used for the CIST calculation [items a), b1)
c1) in 27.6]. The following information is computed for each SPT and retained for use by the state machines
specified in Clause 13 and 27.9, 13.17, 13.36, and 13.29.34:
a) The root priority vector for the bridge;
and for each of the bridge’s ports that is not a Boundary Port:
b) The Port Role;

c) The designated priority vector;
and for each of the bridge’s ports that is not a Boundary Port and has a Port Role of Designated Port.
d) The best root path priority vector out of those that would be calculated, using the same ISIS-SPB
information, by the other SPT Bridges.
Std 802.1Qbp-2014
There can be several equal cost shortest paths between any given pair of bridges but unless ECMP is in use
only one path between the pair can be used in a given SPT Set. Ties are broken using an algorithm (27.17,
28.5) that is independent of the order of SPT computation, that ensures that the SPTs in each SPT Set are
symmetric, that allows path selection to be managed using the same variables that are used to manage active
topologies in the absence of multiple paths, and that is likely to select different equal cost paths for different
SPT Sets if configuration defaults are used.
When a VLAN is supported by an SPT Bridge using SPBM mode and loop mitigation (6.5.4.2, 27.14) is
being used, each of the FDB entries that control forwarding for unicast frames can be created or modified as
soon as the port providing the shortest path to the bridge or end station using that address is known, without
the need to use additional protocol or to complete the SPT computation. In that case, restoration of unicast
connectivity after a physical topology failure is most rapidly achieved by beginning the SPT
(re)computation with the SPT rooted at the calculating bridge.
27.15 SPBM Group Addressing
Change 27.15 as shown, inserting Figure 27-4 and renumbering subsequent figures as
necessary:
When a B-VLAN is supported by an SPT Bridge using SPBM, the individual destination and source MAC
addresses of each frame are those used by entities within SPT Bridges or within systems that include an SPT
Bridge Component, such as Backbone Edge Bridges (BEB, Clause 3, Clause 25). SPBM mode assigns
Group Addresses of local significance to the SPT Domain, each including an SPSourceID (27.10), for use
by those entities. For symmetric ECT Algorithms (28.8.1) group addresses are assigned to source rooted
trees and include an SPSourceID (27.10). Taken together each frame’s B-VID and SPSourceID identify the
source rooted SPT used to forward the frame., while For the ECMP ECT Algorithm (28.8.2) group
addresses may be assigned to one of 16 source rooted trees per bridge or to one of 16 shared trees. Group
addresses assigned to source rooted trees include an SPSourceID and I-SID, and the I-SID may be
associated with a Tie-Break Mask. Together the B-VID, SPSourceID and Tie-Break Mask identify the
source rooted SPT used to forward the frame. Group addresses assigned to a shared tree include the Tie-
Break Mask used in root node selection, and the I-SID. The B-VID and Tie-Break Mask together identify a
particular shared tree used to forward the frame. In all cases ISIS-SPB’s knowledge of the addressed group
and its assigned tree allows it to create a MAC Address Registration Entry (8.8.4) for the address, restricting
propagation to the pruned subset of the SPTtree that reaches the group’s members.
In particular, a distinct Group MAC Address is assigned to each Virtual Instance Port (VIP, Clause 3) for use
as the B-DA of the multicast frames that it transmits into an SPT Domain. Each VIP supports a single
backbone service instance, so the B-DA identifies the I–SID for each customer frame that is multicast and its
transmission is confined to LANs providing connectivity between BEBs supporting that service instance.
Figure 27-2 illustrates the general format of SPBM Group MAC Addresses. The octet and bit ordering and
identification conventions used in this figure follow those of IEEE Std 802-2001 Figure 8. The conventions
used to encode parameters with numeric values, such as the SPSourceID or I–SID, are those used elsewhere
in this standard (14.1.1): the number is encoded as an unsigned binary numeral with bit positions in lower
octet numbers having more significance. The least significant and the next to least significant bits of the first
octet of the address, the Individual/Group and Universally/Locally administered bits, are both set denoting a
locally administered group address. The two next most significant bits compose an SPBM address type,
permitting alternative uses of the remaining bits of the address.
This standard encodes the I–SID in the last three octets, and the value 0 or 1 in the address type field (Figure
27-3). Other values (1, 2, and 3) are reserved for future standardization. The address format for group
addresses assigned to a source rooted SPT is shown in Figure 27-3. In this format the SPSourceID is
encoded in the first three octets.
Std 802.1Qbp-2014
Octet: 0 1 2 3 4 5
LSB MSB LSB MSB LSB MSB LSB MSB LSB MSB LSB MSB
11tt xxxx xxxx xxxx xxxx xxxx xxxx xxxx xxxx xxxx xxxx xxxx
SPBM address
SPBM address type type specific
U/L address bit
I/G address bit
Figure 27-2—SPBM Group MAC Address—general format
Octet: 0 1 2 3 4 5
1100 ssss ssss ssss ssss ssss iiii iiii iiii iiii iiii iiii
SPSourceID I-SID
SPBM address type
U/L address bit
I/G address bit
Figure 27-3—SPBM Group MAC Addresses—source rooted SPTused
by this standard
Figure 27-4 shows the format for group addresses assigned to a shared tree. Four bits of octet 2 are used to
encode the Tie-Break Mask identifying the shared tree. If the same group address were to be used in two
shared trees, forwarding loops could be created. The Tie-Break Mask is included in the group address so that
the addresses used in different shared trees are distinct and forwarding loops are not created. The remaining
bits are set to zero, leaving a substantial portion of the SPBM type 1 address space available for future
use.
Octet: 0 1 2 3 4 5
1110 0000 0000 0000 mmmm 0000 iiii iiii iiii iiii iiii iiii
I-SID
SPBM address type
Tie-Break Mask
U/L address bit
I/G address bit
Figure 27-4—SPBM Group MAC Addresses—shared tree
Std 802.1Qbp-2014
The use of locally assigned Group MAC Addresses by SPBM mode does not affect the use of the same or
different Group MAC Addresses for other VLANs. In addition to creating and managing the required
Filtering Database entries for each specific group address (GASPBM) for any given Base VID (VSPBM, say)
that identifies an SPBM mode supported VLAN, an SPT Bridge using SPBM mode also manages the
following entries:
— If the Filtering Database contains a static entry specifying Forward (for any Bridge Port) for the
wildcard VID and any specific Group MAC Address not required by this clause (27.15) then an entry
specifying Filter (for all Bridge Ports) is also created for that Group Address and each Base VID
supported by SPBM mode.
— A Static Filtering Entry for All Group Addresses (for which no more specific Static Filtering Entry
exists, (8.8.1) is created for each Base VID supported by SPBM mode, specifying that those
addresses are to be filtered.
27.17 Equal cost shortest paths, ECTs, and load spreading
Change the second paragraph of 27.17 as shown:
The capability to support multiple VLANs using different ECTs allows a network administrator to choose
different equal cost paths for different services by assigning services to selected VLANs. ECMP (Clause 44)
provides the capability to spread load across equal cost shortest paths using a single SPBM VID.
Insert the following subclause 27.18, after 27.17, and renumber the subsequent subclauses in
Clause 27 accordingly:
27.18 Connectivity Fault Management for SPBM
Connectivity Fault Management (CFM) as specified in Clause 18 through Clause 22, provides capabilities
useful in detecting, isolating, and reporting connectivity faults in VID-based service instances, backbone
service instances, and TESIs. As with PBB-TE, SPBM disables flooding of frames with unknown
destination address. This and other changes in behavior with SPBM require some modification to VLAN
CFM functions. The modifications related to SPBM are summarized here.
In particular, this subclause summarizes SPBM considerations related to the following:
a) SPBM Maintenance Association types (27.18.1)

b) SPBM MEP placement in a Bridge Port (27.18.2)
c) SPBM MIP placement in a Bridge Port (27.18.3)
d) SPBM modifications of the CFM protocols (27.18.4)
27.18.1 SPBM Maintenance Association types
SPBM CFM uses three types of Maintenance Association: SPBM VID MAs, SPBM path MAs, and SPBM
group MAs.
An SPBM VID MA operates like a VLAN MA. For example, SPBM MEPs multicast CCM frames to all
other MEPs and expect to receive CCM frames from all other MEPs in an SPBM VID MA. There are minor
differences from VLAN MAs, primarily in the destination addresses used for CFM frames. SPBM VID
MAs can be used to monitor and diagnose SPBM connectivity.
SPBM specifies two MA types for testing forwarding state installed by ISIS-SPB for specific addresses. In
SPBM path MA CCMs are used to test the path for an individual destination MAC address between a pair of
Std 802.1Qbp-2014
endpoints. This type of MA has only two MEPs, at two SPT Region boundary ports. An SPBM path MA is
identified by a TE-SID comprising an ESP in each direction between the two endpoints. In an SPBM group
MA CCMs are used to test a set of multicast trees used by a BSI. This type of MA has multiple MEPs, each
located at a CBP supporting the BSI whose multicast trees are to be tested. An SPBM group MA is
identified by the I-SID whose multicast trees it tests. The path taken by CCM frames depends on the current
state of the network (i.e., paths are subject to rerouting triggered by topology changes). A CCM defect
detected by an SPBM path MA or SPBM group MA may indicate a problem with the forwarding state for
the MAC addresses being tested. This standard does not specify the mechanisms that would be necessary to
support Loopback and Linktrace on an SPBM path MA or SPBM group MA since full Loopback and
Linktrace coverage can be provided by an SPBM VID MA. Therefore there are no MHFs associated with an
SPBM path MA or SPBM group MA.
27.18.2 SPBM MEP placement in a Bridge Port
SPBM MEPs are always Up MEPs and can only be placed on CBPs as these correspond to the demarcation
points of the SPT Region. The SPBM MEPs are placed between the Frame filtering entity (8.6.3) and the
Port filtering entities (8.6.1, 8.6.2, and 8.6.4) in the VID space identified by the EISS Multiplex Entity
(6.17). An SPBM VID MEP is placed in the same location as a VLAN MEP as shown in Figure 27-5.
Since SPBM path MEPs and SPBM group MEPs must only see traffic using specific addresses, these MEPs
need to be further differentiated by the TESI Multiplex Entity (6.19). This locates an SPBM path MEP or
SPBM group MEP so that it receives CCMs only from the other MEPs in its MA. Figure 27-5 also shows an
example of an SPBM path MEP and SPBM group MEP on a CBP.
27.18.3 SPBM MIP placement in a Bridge Port
SPBM MIP creation is based on the algorithm described in 22.2.3. SPBM MIPs are created per identified
VIDs on PNPs. Figure 22-9 depicts an example of a pair of SPBM MHFs on a PNP.
27.18.4 SPBM modifications of the CFM protocols
27.18.4.1 Continuity Check protocol in an SPBM MA
The Continuity Check protocol is described in 20.1 and the corresponding state machines in Clause 20. The
modifications required to realize SPBM MAs include the following:
a) In the case of an SPBM VID MEP, the destination_address parameter is set to the group MAC
address for the SPBM default I-SID (Table 9-3) for the Bridge on which the MEP is configured. In
the case of an SPBM path MEP, the destination_address parameter is set to the MAC address
indicated by the ESP-DA field of the ESP having in its ESP-SA field the MAC address of the MEP.
In the case of an SPBM group MEP the destination_address parameter is set to the SPBM Group
MAC address assigned to the source MEP’s CBP for the SPBM group MA’s I-SID [item a) in
20.11.1].
b) In the case of ECMP with flow filtering, the flow_hash and time_to_live parameters are set [item e)
in 20.11.1].
All other Continuity Check processes are the same as those for a VID-based MA.
Std 802.1Qbp-2014
Frame filtering (8.6.3) LLC

EISS EISS MS
(other EISS Multiplex Entity (6.17)
ports) VID 2 SPBM VID other VIDs
(E)ISS
SPBM VID
Level 4
MEP
ISS (E)ISS
Level 2
TESI Multiplex Entity (6.19)
ISS (E)ISS (E)ISS

SPBM
Level 3
Level 5
Level 5
path MEP
and SPBM
ISS (E)ISS (E)ISS group MEP
Up MEPs
Level 5
DoSAPs ISS (E)ISS EISS

EISS
Port filtering entities (8.6.1, 8.6.2, 8.6.4)
EISS
Linktrace Output Multiplexer (19.5)
EISS
Queuing entities (8.6.6, 8.6.7, 8.6.8)
EISS
F-TAG processing (44.2.2)
EISS
Support of the EISS for CBPs (6.11)
ISS
ISS
Figure 27-5—SPBM MEP placement in a CBP
27.18.4.2 Loopback protocol in an SPBM MA
The Loopback protocol is described in 20.2 and the corresponding state machines in Clause 20. The
modifications required to realize the SPBM MA are summarized below:
a) To enable intermediate MIPs to selectively intercept LBMs that are targeting them, the PBB-TE
MIP TLV (21.7.5) is inserted as the first TLV [item g) in 20.31.1] in an LBM. The format of
the PBB-TE MIP TLV is described in 21.7.5 and is constructed as follows:
1) The MIP MAC address field contains the MAC address of the MIP to which the LBM is
targeted [item b) in 12.14.7.3.2];
2) The Reverse VID field and Reverse MAC field are not used in SPBM.
b) An SPBM MHF forwards all received LBMs except those carrying a PBB-TE MIP TLV containing
in their MIP MAC address field the MAC address of the MIP associated with that SPBM MHF [item
f) in 20.28.1];
Std 802.1Qbp-2014
c) In the case of ECMP with flow filtering, the flow_hash and time_to_live parameters are set [item d)
in 20.31.1].
NOTE—The MIP MAC address for an LBM does not have to be advertised by ISIS-SPB since it is only used locally to
match the value provided in a PPB-TE MIP TLV.
All other Loopback processes are the same as those for a VID-based MA.
27.18.4.3 Linktrace protocol in an SPBM MA
The Linktrace protocol is described in 20.3 and the corresponding state machines in Clause 20. The
modifications required to realize the SPBM MA are summarized as follows:
a) The LTMs transmitted by a MEP associated with an SPBM MA use as the destination_address
parameter the MAC address indicated in the LTM management request [item c) in 12.14.7.4.2].
b) No special destination_address validation tests are performed by the ProcessLTM() procedure in the
case of SPBM MAs [item c) in 20.47.1].
c) To identify a possible egress port, an SPBM MIP queries the filtering database of its associated
bridge using the destination_address and the vlan_identifier of the LTM as the parameters for the
lookup (20.47.1.2). In the case of ECMP with flow filtering, the flow_hash value of the LTM is also
used for the lookup, if required. For group addresses, LTMs can be further forwarded by SPBM
MIPs even if the lookup identifies more than one Egress port.
d) In the case of ECMP with flow filtering, the flow_hash and time_to_live parameters are set [item d)
in 20.42.1].
All other Linktrace processes are the same as those for a VID-based MA.
Std 802.1Qbp-2014
28. ISIS-SPB Link State Protocol
28.5 Symmetric shortest path tie breaking
Insert the following paragraph after the NOTE in 28.5:
Two mechanisms are used to provide for symmetric and congruent SPT calculation. The first mechanism
addresses the possibility that different ends (nodes) of an adjacency advertise different values for the SPB
Link Metric (28.12.7). To maintain determinism the SPB shortest path calculation always uses the maximum
of the two advertised SPB Link Metric values when accumulating path costs. The second mechanism
addresses the situation in which two equal cost paths are found. To maintain determinism in this case a tie
breaking algorithm is required that achieves the same result regardless of order of computation.
Change the title and initial text of 28.8 as shown:
28.8 Predefined ECT Algorithm details
This standard defines a set of symmetric ECT Algorithms used to calculate SPT Sets for SPBV or SPBM
VLANs and one ECMP ECT Algorithm (44.1.2) used to calculate SPTs and shared trees for ECMP (Clause
44).
Each of the predefined symmetric ECT-ALGORITHMs is formed using the OUI=00-80-C2 and the
Index=1..16.
28.12 ISIS-SPB TLVs
28.12.6 SPB Instance Opaque ECT Algorithm sub-TLV
Insert new 28.12.6.1 at the end of 28.12.6:
28.12.6.1 ECMP ECT Algorithm sub-TLV
This TLV is not required for SPBM symmetric ECT operation, and is optional for SPBM ECMP. This sub-
TLV can be used to advertise a Bridge Priority value (two most significant bytes of the Bridge Identifier) to
be used in shared tree root Bridge selection (44.1.2) when using the normal Bridge Priority (13.26.2) will not
produce the desired result. Since Bridge Priority influences both source rooted tree structure and shared tree
root selection, this optional sub-TLV is provided for situations in which the desired outcome for both of
these selections cannot be achieved using a single Bridge Priority. This sub-TLV associates an alternate
Bridge Priority [item c) in 12.25.14.1.2] with a node for use with a particular Tie-Break Mask. The alternate
Bridge Priority is used instead of the normal Bridge Priority when the associated Tie-Break Mask is used to
select a shared tree root Bridge. This enables greater control over root Bridge selection for shared trees,
Std 802.1Qbp-2014
when needed. This sub-TLV is carried in an MT-Capability TLV in a Link State PDU (along with a valid
SPB Instance sub-TLV).
Octet Length
Type (2) 1 1
Length 2 1
ECT-ALGORITHM (00-80-C2-11) 3–6 4
Tie-Break Mask 7 4-bits
reserved 7 4-bits
Bridge Priority 8–9 2
...
Tie-Break Mask (3n+4) 4-bits
reserved (3n+4) 4-bits
(3n+5) –
Bridge Priority 2
(3n+6)
Figure 28-6—ECMP ECT-ALGORITHM sub-TLV
a) Type (8-bit) Value 2

b) Length (8-bits)
Total number of bytes contained in the value field.
c) ECT-ALGORITHM (4-bytes)
ECT-ALGORITHM is 00-80-C2-11 for ECMP.
d) Tie-Break Mask (4-bits)
A 4-bit mask that is repeated to form a 64-bit mask used in selecting the low Bridge Identifier
from a set of Bridge Identifiers. This selection process is used to select a shared tree root
Bridge.
e) Bridge Priority (16-bits)
Bridge priority is the 16 bits that together with the low 6 bytes of the SPB System Identifier
form the Bridge Identifier. This Bridge Priority is used to form the Bridge Identifier used to
select a shared tree root bridge using the mask identified by the accompanying Tie-Break Mask
field.
28.12.7 SPB Link Metric Sub TLV
Insert the following note after the first paragraph of 28.12.7:
NOTE—In ECMP the elimination of symmetry requirements could allow the use of a different metric for each link
direction; however, to maintain consistency ECMP shortest path algorithms continue to use the maximum metric value
in cases where the metrics advertised by adjacent nodes for a given link are different.
28.12.10 SPBM Service Identifier and Unicast Address (ISID-ADDR) sub-TLV
This sub-TLV declares an individual B-MAC address and maps I-SIDs in the context of a B-VID to that B-
MAC, allowing automatic creation of efficient group trees that are subsets of the SPT rooted at the node
identified by that individual B-MAC address. In an symmetric ECT environment, the I-SIDs are mapped to
a B-VID whichthat is associated with an ECT-ALGORITHM symmetric ECT Algorithm specifying the SPT
Set. In ECMP the I-SIDs are mapped to a B-VID that is associated with the ECMP ECT Algorithm, which
Std 802.1Qbp-2014
may specify a source rooted SPT or a shared tree for group addressed frames. Multicast trees can be selected
per I-SID for maximum diversity. This sub-TLVIt is carried in an MT-Capability TLV in a Link State PDU.
Octet Length
Type (3) 1 1
Length 2 1
B-MAC Address 3-8 6
reserved 9 4 bits
Base VID 9-10 12 bits
T 11 1 bit
R 11 1 bit
I-SID Ts 11 1 bit
Tuple 1 reserved 11 61 bits
Tie-Break Mask 11 4 bits
I-SID 12-14 3
...
T (4n+7) 1 bit
R (4n+7) 1 bit
Ts (4n+7) 1 bit
I-SID
Tuple n reserved (4n+7) 61 bits
Tie-Break Mask (4n+7) 4 bits
(4n+8)-
I-SID 3
(4n+10)
Figure 28-7—SPBM Service Identifier and Unicast Address sub-TLV
a) Type (8-bit) Value 3

b) Length (8-bits)
Total number of bytes contained in the value field.
c) B-MAC Address(48-bits)
B-MAC ADDRESS is an Individual MAC Address on this bridge. It may be either the single
nodal address, or may address a port or any other level of granularity relative to the bridge. In
the case where the bridge only has one B-MAC address this may be the same as the MAC
address portion SPB System Identifier of the bridge. To add multiple B-MACs this sub-TLV
shall be repeated for each additional B-MAC.
Each Individual MAC Address has one or more I-SIDs that are associated with this address. In
PBB terms this corresponds to a PIP B-MAC. All B-MACs that are used for Individual MAC
addresses and for the Sources of Group MACs shall be associated with at least one I-SID. This
sub-TLV is initiated by IB-BEBs.
d) Base VID (12-bits)
The Base VID identifies the B-VID and by association the ECT-ALGORITHM and SPT Set
that the I-SIDs defined below will use.
e) T Bit (1-bit)
This is the Transmit allowed Bit for the following I-SID. This is an indication that a Group
MAC Addresses Registration Entry (8.8.4) for this I-SID as source should be constructed and
installed (for the bridge advertising this I-SID), and installed in the FDB of transit a bridges,
whenif the bridge computing the trees is on the corresponding ECT-ALGORITHM shortest
path between the bridge advertising this I-SID with the T bit set, and any receiver of this I-SID.
A bridge that does not advertise this bit or the Ts bit set for an I-SID should have no forwarding
state installed for traffic originating from that bridge on other transit bridges in the network.
f) R Bit (1-bit)
Std 802.1Qbp-2014
This is the Receive allowed Bit for the following I-SID. This is an indication that a Group
MAC Addresses Registration Entry (8.8.4) for this I-SID as receiver should be constructed and
installed (for bridges advertising this I-SID with the T bit or Ts bit set) and installed when if a
the bridge computing the trees lies on the corresponding shortest path for this ECT-
ALGORITHM between this receiver and any transmitter on this I-SID. An entry that does not
have this bit set for an I-SID is prevented from receiving on this Group MAC Addresses for this
I-SID because transit bridges will not install multicast forwarding state towards it in their
FDBs.
g) Ts Bit (1-bit)
The Ts bit indicates that this I-SID source uses a shared tree for multicast frames. The Group
MAC Address for this I-SID source is constructed using the Tie-Break Mask and the I-SID
(27.15, Figure 27-4). A group MAC Address Registration Entry (8.8.4) is installed in any
bridge on the shared tree, selected by the Tie-Break Mask, between the advertising bridge and
bridges that have the R bit set for the same I-SID. If both the T bit and Ts bit are set, the Ts bit
takes precedence. This bit is ignored by ECT-ALGORITHMs in Table 28-1.
h) Tie-Break Mask (4-bits)
A 4-bit mask that is repeated to form a 64-bit mask used in selecting the low Bridge Identifier
from a set of Bridge Identifiers. This selection process is used in multicast tree calculations to
select a shared tree root Bridge and parent nodes in SPTs where equal cost paths are available.
This field is ignored by ECT-ALGORTITHMs in Table 28-1.
i) I-SID (24-bits)
I-SID is the 24-bit group service membership identifier. If two bridges have an I-SID in
common, intermediate bridges on the unique shortest path between them will create forwarding
state for the related B-MAC addresses. They will also construct multicast forwarding state
using the I-SID and the bridge’s SPSourceID to construct a multicast DA. Each I-SID has a
Transmit (T) and Receive (R) bit which indicates if the membership is as a Transmitter/
Receiver or both (with both bits set). In the case where the Transmit (T) and Receive (R) bits
are both zero, the I-SID is ignored (this forces a point to point capability that does not require
Group address installation, but the advertised individual B-MAC address shall be processed
and installed if required on the SPT). If more I-SIDs are associated with a particular B-MAC
than can fit in a single sub-TLV, this sub-TLV can be repeated with the same B-MAC and
(MTID) but with additional I-SID values. I-SID values can be in any order. Duplicate I-SIDs
for a B-MAC are allowed (within a sub-TLV, across two or more sub-TLVs, across two or more
LSP fragments, or even across two or more LSPs). If the duplicates are in different B-VIDs
they are processed, otherwise the T and R bits processed are the logical- OR of the T and R bits
of the two entries and it is processed as a single entry. (I-SID=0 is an exception that is always
ignored, and allows a fast method to remove an I-SID without restructuring all the LSPs).
Repacking an LSP (when I-SID=0 entries should be collapsed) can be done by moving entries
from the high end into the empty I-SID=0 entries. To avoid outages temporary duplicates are
allowed during this repacking and the entry further up in the LSP may later be removed without
impact. The I-SID value 0x0000ff is reserved for SPB broadcast to all bridges.
Items d), h), and i) are set to zero on transmit and ignored on receipt for SPBM symmetric ECT operation.
Std 802.1Qbp-2014
Insert new Clause 44 as shown:
44. Equal Cost Multiple Paths
SPB supports two approaches to spreading traffic load. The first approach, ECT VLANs, spreads traffic by
assigning each service instance to a VLAN configured to use one of the supported SPT Sets. This approach
is applicable to both SPBV and SPBM. Each Base VID is assigned to an ECT-ALGORITHM (tie-breaker)
that defines the SPT Set for that VLAN, and different ECT Algorithms may thus be used to select different
shortest paths in the SPT Region. In case of a PBBN, each I-SID is assigned to a Base VID. This approach
can spread traffic load while maintaining traffic path congruence in each VLAN.
The second approach, ECMP, spreads traffic by employing multiple equal cost paths with a single VID. This
approach is only applicable to SPBM. Unicast frame filtering dynamically selects a next hop from the set of
equal cost next hops for the frame’s destination MAC address. Multicast frame filtering is controlled by
selecting a multicast routing mode and a tie-break mask for each Backbone Service Instance and advertising
that selection in ISIS-SPB. Multicast filtering entries for the BSI are generated by calculations that select a
multicast tree from the set of equal cost trees in the SPT Region based on the advertised multicast mode and
tie-break mask.
44.1 SPBM ECMP
44.1.1 ECMP Operation
SPBM equal cost multiple paths (ECMP) provides a mechanism to spread traffic load across a set of equal
cost shortest paths in an SPT Region using a single VID. Rather than using one equal cost tie-breaking
function to create a single SPT for all individual addresses, ECMP uses a hash function to spread individual
address forwarding over a set of equal cost forwarding ports.
If flow filtering (44.2) is not supported, the ECMP ECT Algorithm selects one port from the set of equal cost
forwarding ports for each individual address (28.8.2) and creates a Dynamic Filtering Entry for the address
indicating the selected port.
If flow filtering (44.2) is supported, a set of equal cost forwarding ports may be recorded in the FDB in a
Dynamic Filtering Entry (8.8.3). During unicast frame filtering the MAC Relay Entity selects one
forwarding port from the applicable set using a dynamic port selection process (44.2.3).
The individual address forwarding port selection processes, both with and without flow filtering, are
designed to
a) Spread traffic (i.e., make varied choices) for different flows traversing the SPT Region, and
b) Maintain frame ordering for each flow by making the same choice for all frames belonging to any
single flow.
ECMP is supported by Dynamic Filtering Entries in the filtering database and, optionally, the Flow Filtering
tag (F-TAG, 44.2.1) that carries Flow Hash and TTL information. The flow hash serves both to distinguish
frames belonging to different flows and to identify frames that belong to (or may belong to) the same flow.
The flow hash is used as input to the dynamic port selection process to support the design goals noted above.
The TTL is used to mitigate traffic loops, if they happen to occur (44.2.4).
While unicast frames are spread across equal cost paths, multicast frames cannot be treated this way. Instead
multicast traffic load is spread by assigning a multicast mode and tie-breaker to each group address. This
selection enables the use of varied SPTs for each group address or set of group addresses. The default ECMP
Std 802.1Qbp-2014
ECT Algorithm selects a source rooted SPT for each node that may transmit multicast traffic. This default
source rooted SPT is used for all group addresses assigned to that node. Finer grained control of multicast
load spreading is done by selecting a multicast mode and tie-break mask for a particular I-SID. This
selection governs the multicast routing used for that I-SID’s assigned group address. The selectable
multicast modes include the following:
c) Source rooted SPT;

d) Shared tree; and
e) Head-end replication.
Up to 16 source rooted SPTs can be supported per node by using one of 16 different tie-break masks in
calculating the SPT. During SPT calculation the tie-break mask is used to select one from the set of equal
cost parents (neighbor nodes closer to the root) for each node (28.8.2). The default multicast treatment is
equivalent to using a tie-break mask of zero. An I-SID on a CBP can be assigned to a specific SPT by
configuring the Tie-Break Mask for that I-SID [item h) in 12.25.8.1.2 and item h) in 28.12.10].
To reduce the amount of multicast forwarding state required, shared (spanning) trees are supported. Up to 16
shared trees can be configured using the 16 tie-break masks. For shared trees the tie-break mask is used both
to select a shared tree root Bridge and to select from the set of equal cost parents for each node in the tree.
The shared tree root for a given tie-break mask is determined by selecting the best (least) masked Bridge ID
(i.e., the Bridge ID value masked using the tie-break mask). The SPT calculation from the shared tree root
also uses the tie-break mask to select between equal cost parents (again selecting the least masked Bridge
ID). Each I-SID on a CBP can be assigned to a shared tree by setting a shared tree transmit indicator bit and
configuring the tie-break mask to identify the shared tree (28.12.10). All CBPs for a given I-SID that
transmit on a shared tree use the same group address (Figure 27-4), and share the forwarding state for this
address in the FDB.
It is possible to avoid using group addresses altogether and handle multicast frames by head-end replication.
An I-SID on a CBP using head-end replication sends a unicast frame to each destination instead of sending a
group addressed frame. If an I-SID is using head-end replication it is configured to indicate no multicast
transmission from that CBP. In this case no group address forwarding state will be installed for that I-SID’s
assigned address at that CBP (28.8.2). An I-SID using head-end replication at a CBP should nevertheless
indicate that it wishes to receive multicast frames since other CBPs supporting the same I-SID may still use
multicast.
NOTE—ISIS-SPB does not check for the use of the same tree type for all endpoints of an I-SID, but use of different tree
types within a single I-SID is not recommended.
44.1.2 ECMP ECT Algorithm
The content of FDB entries for individual addresses in ECMP depends on whether or not flow filtering
(44.2) is supported by a Bridge.
If flow filtering is not supported or the ECT_ALGORITHM value indicates no flow filtering (Table 44-2),
then for each individual address the ECMP ECT Algorithm selects one port from the set of equal cost
forwarding ports using a form of the FNV non-cryptographic hash algorithm and creates a Dynamic
Filtering Entry (8.8.3) indicating that port as forwarding. The forwarding port is selected by the following
process:
For a set of k equal cost forwarding Ports, let P be an ordered list of the forwarding Ports sorted from
greatest to least neighbor SPB System Identifier and Pi be the ith Port in P. Thus P0 is the Port whose
neighbor has the greatest SPB System Identifier and Pk-1 is the Port whose neighbor has the least SPB
System Identifier. The following algorithm is used to select a value for i for the individual MAC address,
thus selecting Port Pi to be the forwarding port:
Std 802.1Qbp-2014
a) Set a 32-bit variable bestHash32 to 0xFFFFFFFF,

b) Set i to 0 (zero),
c) For each n in 0..k-1 (in order) perform the following steps 1) through 5)
1) Set a 32-bit variable hash32 to 0x811C9DC5;
2) For each octet Oj (extended to 32 bits with leading 0’s) in the Bridge’s SPB System Identifier
(8.13.8), starting with the least significant octet (octet 5) and progressing to the most significant
octet (octet 0), set hash32 to ((hash32 xor Oj) × 0x01000193);
3) For each octet Oj (extended to 32 bits with leading 0’s) in the neighbor SPB System Identifier
for Port Pn, starting with the least significant octet (octet 5) and progressing to the most
significant octet (octet 0), set hash32 to ((hash32 xor Oj) × 0x01000193);
4) For each octet Oj (extended to 32 bits with leading 0’s) in the individual MAC address, starting
with the least significant octet (octet 5) and progressing to the most significant octet (octet 0),
set hash32 to ((hash32 xor Oj) × 0x01000193);
5) If hash32 < bestHash32, set i to n and set bestHash32 to hash32.
If flow filtering (44.2) is supported and the ECT_ALGORITHM value indicates flow filtering (Table 44-2),
ISIS-SPB configures the Flow Filtering Control Table (44.2.2) for each port on which the ECMP SPBM
VID is registered (27.13). For CBPs the Base VID is configured with both Flow Filtering and Flow Hash
Generation enabled. For PNPs the Base VID is configured with Flow Filtering enabled and Flow Hash
Generation disabled. For each individual address the ECMP ECT Algorithm calculates a Port Map
specifying forwarding for a set of equal cost hops to that address and creates a corresponding Dynamic
Filtering Entry (8.8.3). These Dynamic Filtering Entries are used in the dynamic selection of forwarding
ports by the flow filtering process (44.2.3).
For each I-SID on a CBP transmitting multicast frames the ECMP ECT Algorithm may calculate a source
rooted SPT. If equal cost paths are found to any node on the tree, the path whose parent node (neighbor node
toward the root) has the least Bridge Identifier is selected. A group MAC Address Registration Entry (8.8.4)
is created for the I-SID’s source rooted tree SPBM Group MAC Address (Figure 27-3) if the node
performing the calculation is located between the source node and any multicast receiver(s) for the I-SID.
The group MAC Registration Entry indicates forwarding for each port that leads to at least one multicast
receiver for the I-SID on the calculated SPT (except the port from the source).
The ECMP ECT Algorithm supports two additional parameters that control multicast forwarding state
calculation. First, a Tie-Break Mask value may be specified for an I-SID on a CBP [item h) in 28.12.10 and
item h) in 12.25.8.1.2]. When a non-zero Tie-Break Mask is advertised, a 64-bit mask (formed by repeating
the 4-bit Tie-Break Mask value in each nibble) is applied to (xor’ed with) each Bridge Identifier before
selecting the lowest value as described in the SPT calculation in the paragraph above. Thus the default
behavior described above is equivalent to using a Tie-Break Mask of zero. This parameter enables up to 16
different SPTs to be calculated from a given source node. Each I-SID on a CBP may be assigned
independently to one of these 16 source trees.
The second parameter controlling multicast forwarding state calculation is the shared tree indicator. An
I-SID on a CBP may be configured to use a shared tree instead of a source specific SPT [item g) in 28.12.10
and item g) in 12.25.8.1.2]. There may be up to 16 shared trees, corresponding to the 16 Tie-Break Mask
values. Each shared tree is calculated by selecting a root Bridge using the least masked Bridge Identifier. If a
node advertises a Bridge Priority for the given Tie-Break Mask (28.12.6.1) the advertised value is used
instead of the normal Bridge Priority in forming its Bridge Identifier (before masking). In calculating the
SPT from the selected root the same Tie-Break Mask is used to form masked Bridge Identifiers (using the
normal Bridge Priority) and the least value of masked Bridge Identifier is used to choose between equal cost
parents for any node. If an I-SID on a CBP is configured to use a shared tree, the group address used
in the group MAC Address Registration Entry is constructed using the Tie-Break Mask and the
I-SID (27.15, Figure 27-4). In this case the ECMP ECT Algorithm creates a group MAC Address
Registration Entry if the node performing the calculation is between the CBP and any multicast
Std 802.1Qbp-2014
receivers on the SPT calculated from the selected root node. The Port Map indicates forwarding for all Ports
that lead from a multicast transmitter to at least one multicast receiver for the I-SID.
If an I-SID on a CBP does not indicate transmission of multicast frames (e.g., head-end replication is to be
used instead) then no group MAC Address Registration Entry is configured for multicast from that CBP for
that I-SID.
Table 44-2 shows the ECT-ALGORITHM values for the ECMP ECT Algorithm.
Table 44-2—ECMP ECT-ALGORITHM values
ECT-ALGORITHM ECMP behavior
00-80-C2-11 ECMP without flow filtering
00-80-C2-12 ECMP with flow filtering
44.1.3 Loop prevention for ECMP
Loop prevention for unicast ECMP operates as specified in Clause 13 with the extension of allowing
multiple Root Ports in case of multiple equal cost paths in order to support the per frame tie-breaking of
ECMP. The ECMP connectivity to a destination bridge is comprised of the shortest paths destined to that
bridge when the topology is Agreed in the meaning of the Agreement Protocol. If a bridge is not the
destination bridge, then the one or more ports that ISIS-SPB has calculated as respectively providing a
shortest path to the destination is a Root Port in the ECMP connectivity. Each port, other than a Root Port, is
a Designated Port if ISIS-SPB has calculated that the port provides a shortest path for frames forwarded
from the attached bridge to the destination in the ECMP connectivity. With these extensions to the
definitions of Port Roles, Clause 13 specifications apply to ECMP as well.
NOTE 1—Despite of allowing more than one Root Port for an SPT Bridge, a single Root Port is enforced on per frame
basis as ECMP operation ensures that a frame is only forwarded through one of the Root Ports towards the destination.
Loop prevention for the shared trees used for ECMP multicast operates as specified by Clause 13 for shared
spanning trees except for that instead of a spanning tree protocol entity it is ISIS-SPB that configures the per
tree Port States and Roles based on its calculations and the operation of the Agreement Protocol;
furthermore, the Learning Process (8.7) neither creates nor deletes Dynamic Filtering Entries.
NOTE 2—The per tree Port States and Roles do not belong to an MSTI having a distinct MSTID because an ECMP B-
VID is assigned to the SPBM MSTI. The Port States and Roles are associated with a single SPT used as a shared
spanning tree supporting bidirectional forwarding (not as a unidirectional tree as for SPB).
44.2 Support for Flow Filtering
Flow filtering support enables Bridges to distinguish frames belonging to different client flows and to use
this information in the forwarding process. Information related to client flows may be used at the boundary
of an SPT Domain to generate a flow hash value. The flow hash, carried in an F-TAG, serves to distinguish
frames belonging to different flows and can be used in the forwarding process to distribute frames over
equal cost paths. This provides for finer granularity load spreading while maintaining frame order for each
client flow.
Flow filtering behavior is controlled by ISIS-SPB. To allow Bridges that support flow filtering to be used
alongside Bridges that do not support flow filtering, ISIS-SPB requires that all Bridges at the SPT Domain
Std 802.1Qbp-2014
boundary that advertise I-SIDs for an ECMP Base VID using flow filtering support F-TAG processing.
Bridges that do not advertise I-SIDs for that Base VID are not required to support flow filtering. Therefore
network operators are able to upgrade selected bridges to support flow filtering and use flow filtering for
selected VIDs without requiring the simultaneous upgrade of all bridges in the SPT Domain.
NOTE—Support for F-TAG processing is indicated in I-SID advertisements and so is only available via ISIS-SPB once
I-SIDs are assigned to the Base-VID. A “dummy” ISID configuration can be used to discover via ISIS-SPB whether or
not F-TAG processing is supported on a Bridge.
This clause specifies
a) A flow filtering tag (F-TAG) that carries a flow hash value (44.2.1);
b) F-TAG processing on Bridge ports (44.2.2);
c) A forwarding process using the flow hash to select one forwarding port from a set of equal cost
options (44.2.3);
d) TTL loop mitigation (44.2.4); and
e) Operation of bridged LANs with selective support for flow filtering (44.2.6).
44.2.1 Flow filtering tag
A flow filtering tag is specified to carry additional information in support of flow filtering functions. The
flow filtering tag comprises a Tag Protocol Identifier (EtherType) and Tag Control Information (TCI).
Table 44-3—F-TAG EtherType
Tag Type Name Value
Flow Filtering Tag IEEE 802.1Q Flow Filtering Tag EtherType 89-4b
The F-TAG TCI field (Figure 9-4) is 4 octets in length and encodes priority, drop_eligible, TTL, and flow
hash information for a service primitive.
Octets: 1 2 3 4
DEI
PCP Reserved TTL Flow Hash
Bits: 8 6 5 4 1 8 7 6 1 8 1 8 1
Figure 44-8—Flow FilteringTCI format
The F-TAG TCI contains the following fields:
a) Priority Code Point (PCP)—This 3-bit field encodes the priority and drop_eligible parameters of the
service request primitive associated with this frame using the same encoding as specified for VLAN
tags in 6.9.3.
b) Drop Eligible Indicator (DEI)—This 1-bit field carries the drop_eligible parameter of the service
request primitive associated with this frame.
c) Reserved—This 6-bit field may be used for future format variations. The Reserved field contains a
value of zero when the tag is encoded, and is ignored when the tag is decoded.
Std 802.1Qbp-2014
d) Time To Live (TTL)—This 6-bit field holds a counter value that is decremented each time the F-TAG
is read (44.2.2.1) and provides a mechanism to limit the number of network hops a frame may take.
e) Flow Hash—This 16-bit field carries a flow hash value used in the dynamic port selection process
for ECMP (8.8.3).
44.2.2 F-TAG processing
This standard specifies flow filtering behavior for SPBM ECMP (44.2). To support this behavior a flow hash
may be conveyed in a mac_service_data_unit using an F-TAG (44.2.1). This clause specifies a Support for
Flow Filtering shim that produces and processes F-TAG information. The shim has two EISS SAPs—a
lower EISS toward a LAN and an upper EISS toward the MAC Relay Entity.
At the boundary of a flow filtering SPT Domain, for example at Customer Backbone Ports, the flow hash is
generated for EM_UNITDATA.indication primitives. At intermediate ports, for example Provider Network
Ports, the F-TAG is generated using the flow hash in EM_UNITDATA.request primitives, or processed to
retrieve the flow hash value from EM_UNITDATA.indication primitives. The F-TAG also includes a TTL
field, used for loop mitigation, and PCP and DEI fields that are processed by this shim.
Flow filtering support is governed by a Flow Filtering Control Table for each port containing an entry for
each VID with the following fields:
a) Flow Filtering (enabled/disabled). This field indicates whether or not flow filtering behavior is
enabled on the port for the VID. The default value is disabled.
b) Flow Hash Generation (enabled/disabled). This field indicates whether or not flow hash generation
is enabled on the port for the VID. The default value is disabled.
c) TTL Value (1..63). This field is the initial TTL value for frames entering the flow filtering SPT
Domain [item d) in 12.16.5.5.2]. The default value is 8.
The Flow Filtering Control Table is provisioned by ISIS-SPB (28.8.2). For flow filtering, a CBP will have
both the Flow Filtering field and the Flow Hash Generation field set to enabled and the TTL Value field set
to provide the initial time_to_live value for indication primitives. For flow filtering, a PNP will have the
Flow Filtering field set to enabled and the Flow Hash Generation field set to disabled. The TTL Value field
(initial TTL value) is not used on a PNP.
NOTE—Based on the description above, for flow filtering the condition “Flow Hash Generation field indicates enabled”
is equivalent to indicating a CBP and the condition “Flow Hash Generation field indicates disabled” is equivalent to
indicating a PNP.
44.2.2.1 Data indications
On receipt of an EM_UNITDATA.indication primitive from the lower EISS on a PNP, the received frame
shall be discarded if
a) For the vlan_identifier in the Flow Filtering Control Table the Flow Filtering field indicates enabled
and the initial octets of the mac_service_data_unit do not contain a valid F-TAG; or
b) The value in the TTL field in the F-TAG is 0.
NOTE 1—A frame received with a TTL value of 0 will be discarded, i.e., not relayed, even if it is addressed to another
port on the receiving Bridge.
Otherwise, an EM_UNITDATA.indication primitive is invoked at the upper EISS with parameter values
determined from the received primitive based on the Flow Filtering Control Table for the received
vlan_identifier as follows:
Std 802.1Qbp-2014
If the Flow Filtering field indicates disabled the invoked primitive is identical to the received primitive.
If the Flow Filtering field indicates enabled the destination_address, source_address, vlan_identifier, and
connection_identifier in the invoked primitive are identical to those parameters in the received primitive.
If the Flow Filtering field indicates enabled and the Flow Hash Generation field indicates disabled, the
mac_service_data_unit in the invoked primitive is created by removing the F-TAG from the received
mac_service_data_unit, otherwise the mac_service_data_unit in the invoked primitive is identical to the
received primitive.
The value of the flow_hash and time_to_live parameters are determined as follows:
a) If the Flow Hash Generation field indicates enabled, the value of flow_hash is generated from the
received primitive (using a process selected by the implementation). Time_to_live is set to the TTL
Value from the Flow Filtering Control Table for the received vlan_identifier.
NOTE 2—Procedures for calculating the flow hash are not covered by this standard. The procedure is typically a
protocol-dependent hash of the client protocol header being carried within the mac_service_data_unit.
NOTE 3—There is often a compromise between the speed of a hash calculation and the quality of value spreading. This
standard makes no assurances regarding the quality of the distribution of flow_hash values.
b) If the Flow Hash Generation field indicates disabled, the value of flow_hash is taken from the Flow
Hash field in the received F-TAG and time_to_live is set to the TTL value in the received F-TAG
decremented by 1.
The value of the drop_eligible and priority parameters are determined as follows:
c) If the mac_service_data_unit was tagged with an F-TAG, the value of the drop_eligible parameter
and the received priority value are decoded as described in 6.9.3, using the PCP and DEI values
from the F-TAG. Otherwise;
d) The received priority value and the drop_eligible parameter value are the values in the
EM_UNITDATA.indication.
e) The value of the priority parameter is then regenerated from the received priority, as specified in
6.9.4.
44.2.2.2 Data requests
On invocation of an EM_UNITDATA.request primitive at the upper EISS, an EM_UNITDATA.request

primitive is invoked at the lower EISS, with parameter values determined based on the Flow Filtering
Control Table for the received vlan_identifier.
If the Flow Filtering field indicates disabled or the Flow Hash Generation field indicates enabled the
invoked primitive is identical to the received primitive.
If the Flow Filtering field indicates enabled and the Flow Hash Generation field indicates disabled all
parameters in the invoked primitive match those in the received primitive except the mac_service_data_unit.
The mac_service_data_unit in the invoked primitive is formed by inserting an F-TAG as the initial octets to
the received mac_service_data_unit. The values of the flow_hash, time_to_live, priority, and
drop_eligible parameters are used to determine the contents of the F-TAG, in accordance with 44.2.1.
Std 802.1Qbp-2014
44.2.3 Forwarding process extension for flow filtering
Frame filtering (8.6.3) reduces the set of potential transmission ports in accordance with applicable Filtering
Database entries. When flow filtering is enabled the ISIS-SPB control plane creates Dynamic Filtering
Entries with multiple forwarding Ports in the Port Map when there are multiple equal cost hops to a given
individual address. Frame filtering must select only one of these forwarding ports on which to transmit each
frame with a matching destination_address and VID.
Selection of one Port from a set indicated by the Port Map shall be performed using a form of the FNV non-
cryptographic hash algorithm as follows:
For a Port Map specifying k potential forwarding Ports, let P be an ordered list of potential forwarding Ports
sorted from greatest to least neighbor SPB System Identifier and Pi be the ith Port in P. Thus P0 is the Port
whose neighbor has the greatest SPB System Identifier and Pk-1 is the Port whose neighbor has the least SPB
System Identifier. The following dynamic port selection process is used to select a value for i, thus selecting
Port Pi to be the transmission port:
a) Set a 32-bit variable hash32 to 0x811C9DC5;

b) For each octet Oj (extended to 32 bits with leading 0’s) in the Bridge’s SPB System Identifier
(8.13.8), starting with the least significant octet (octet 5) and progressing to the most significant
octet (octet 0), set hash32 to ((hash32 xor Oj) × 0x01000193);
c) For each octet Oj (extended to 32 bits with leading 0’s) in the flow_hash parameter, starting with the
least significant octet (octet 4 of Figure 44-8) and progressing to the most significant octet (octet 3
of Figure 44-8), set hash32 to ((hash32 xor Oj) × 0x01000193);
d) Set a 16-bit variable hash16 to ((hash32 and 0x0000FFFF) xor (hash32 / 0x00010000));
e) Set i to (hash16 mod k), selecting Port Pi.
44.2.4 TTL Loop mitigation
The F-TAG contains a TTL field whose value is decremented each time a frame is forwarded by an SPT
Bridge supporting flow filtering [item b) in 44.2.2]. A frame is filtered (discarded) if it is received with a
TTL value of 0. This mechanism mitigates the impact of looping frames by limiting the number of hops
these frames may travel in the network. This method of loop mitigation protects network resources by
ensuring frames are forwarded at most a fixed number of times.
NOTE—The TTL carried in the F-TAG is decremented for all frames; however, the Flow Hash is only applicable to
unicast frames. The Flow Hash has no effect on the filtering of group addressed frames.
44.2.5 Connectivity Fault Management for ECMP with flow filtering
Connectivity Fault Management (CFM) as specified in Clause 18 through Clause 22, provides capabilities
useful in detecting, isolating, and reporting connectivity faults. SPBM MAs (27.18) can be used with an
ECMP VID and provide most of the necessary CFM functionality. One additional MA type is specified for
ECMP, the ECMP path MA, because an SPBM path MA can test only one path between a pair of endpoints.
An ECMP path MA is used to continuously test multiple paths between two endpoints. This type of MA has
only two MEPs at two SPT Region boundary ports. The MA is identified by a TE-SID comprising an ESP in
each direction between the two endpoints. An ECMP path MEP cycles through a set of flow hash values
intended to direct the CCM frames along (and thus test) different paths to the other MEP in the MA. Each
flow hash is used in multiple consecutive CCM frames so that a fault on a particular path will be detected
and reported back via an RDI signal. This standard does not specify the mechanisms that would be necessary
to support Loopback and Linktrace on an ECMP path MA since full Loopback and Linktrace coverage can
be provided by an SPBM VID MA. Therefore there are no MHFs associated with an ECMP path MA.
Std 802.1Qbp-2014
44.2.5.1 ECMP path MEP placement in a Bridge Port
Since ECMP path MEPs must only see traffic from one other endpoint, these MEPs need to be further
differentiated by the TESI Multiplex Entity (6.19). This locates an ECMP path MEP so that it receives
CCMs only from the other MEP in its MA. Figure 44-9 shows an example of ECMP path MEPs on a CBP.
Frame filtering (8.6.3) LLC

EISS EISS MS
(other EISS Multiplex Entity (6.17)
ports) VID 2 SPBM VID other VIDs
(E)ISS
Level 4
SPBM VID
MEP
ISS (E)ISS
Level 2
ISS (E)ISS (E)ISS

ECMP
Level 5
Level 3
Level 5 path MEPs
ISS (E)ISS (E)ISS

Up MEPs
Level 5
DoSAPs ISS (E)ISS EISS

EISS
Port filtering entities (8.6.1, 8.6.2, 8.6.4)
EISS
Linktrace Output Multiplexer (19.5)
EISS
Queuing entities (8.6.6, 8.6.7, 8.6.8)
EISS
F-TAG processing (44.2.2)
EISS
Support of the EISS for CBPs (6.11)
ISS
ISS
Figure 44-9—SPBM VID MEP and ECMP path MEP placement in a CBP
44.2.5.2 Continuity Check protocol in an ECMP path MA
The Continuity Check protocol is described in 20.1 and the corresponding state machines in Clause 20. The
modifications required to realize ECMP path MAs include the following:
a) The MEP Continuity Check Initiator state machine adds three variables for controlling ECMP path
testing (20.10.4, 20.10.5, 20.10.6) and shares two of these with the Remote MEP state machine
(Figure 20-1);
b) The destination_address parameter is set to the individual MAC address of the other MEP in the MA
[item a) in 20.9.12];
Std 802.1Qbp-2014
c) The flow_hash parameter is set to one of the values to be tested and the time_to_live parameter is set
as specified in item e) in 20.9.12;
d) The MEP Continuity Check initiator state machine is modified to support a cycle of path tests for an
ECMP path MEP (20.12);
e) The Remote MEP state machine is modified to track a cycle of path test RDI values and report
rMEPlastRDI as set if any RDI has been seen in the last path test cycle for an ECMP path MEP
(20.19.2, 20.20).
NOTE—In an ECMP path MEP testing a set of paths, the RDI signal reflects back the state of far end CCM reception.
Using the current CCM sending cycle position (pathN), the CCM sending rate, and the path round trip delay one can
calculate roughly the position in the sending cycle corresponding to a received RDI. This approach makes minimal
changes to the CCM state machines at the CCM sending MEP and no changes at the CCM receiving MEP. It is subject to
some ambiguity based on differences in path delay, the sending rate, and cycle length. In the case of ambiguous results
further testing would be required to identify a faulty path.
SPBM MAs may also implement the following enhancements to the Continuity Check protocol:
f) The procedure MEPprocessEqualCCM() on ECMP path MEPs does not include the check of the
MAID on received CCMs [item b) in 20.17.1].
All other Continuity Check processes are the same as those for a VID-based MA.
44.2.6 Operation with selective support for flow filtering
When adding new capabilities to a network it is desirable to make changes incrementally rather than perform
a wholesale upgrade (e.g., incur a “flag day” event). Flow filtering is optional functionality that can be used
with selected Base-VIDs while not adversely affecting other services in the network. However, flow filtering
changes frame encoding (i.e., adds new header information in an F-TAG) and therefore requires that a
Base-VID using ECMP with flow filtering have all its boundary points capable of processing the F-TAG. To
enable incremental incorporation of flow filtering, ISIS-SPB requires F-TAG support for any Bridges with a
CBP associated with a Base VID using ECMP with flow filtering while allowing other Bridges in the SPT
region to operate without flow filtering support.
When the ECMP ECT-ALGORITHM value indicates support for flow filtering (Table 28-2) an I-SID cannot
be configured to use a Base VID using ECMP with flow filtering unless the Bridge supports flow filtering
(12.16.5.2). Requiring all Bridges advertising service instances using ECMP with flow filtering to support
F-TAG processing provides for proper handling of F-tagged frames at the boundary of the SPT Domain.
Within the SPT Domain it is possible to use Bridges that support the ECMP ECT Algorithm but do not
support flow filtering (i.e., do not recognize F-TAGs). In this case, the ECMP ECT Algorithm (28.8.2)
selects one port from the set of equal cost forwarding ports for each individual address and creates a
Dynamic Filtering Entry for the address indicating the selected port.
NOTE—Bridges that do not support flow filtering should not change PCP and DEI values for frames carrying F-TAGs
as this may not provide the desired behavior. If the PCP and DEI values are changed in the VLAN tag only, the PCP and
DEI values carried in the F-TAG will be reasserted when the F-TAG is next processed.
These ECMP behaviors enable incremental upgrade of edge bridges to support flow filtering and selective
use of this capability with I-SIDs registered only at these upgraded edge bridges. ECMP operation with
selective support for flow filtering enables incremental introduction of flow filtering capabilities into an
existing network and earlier introduction of flow filtering support for selected services.
Std 802.1Qbp-2014
Annex A
(normative)
PICS proforma—Bridge implementations1
A.5 Major capabilities

Insert the following items in A.5 at the end of the table:
Item Feature Status References Support
ECMP Is Equal Cost Multiple Paths supported? SPBM:O 5.4.5.1, 44.1 Yes [ ] No [ ]
FF Is flow filtering supported, including ECMP:O 5.4.5.2, 44.2 Yes [ ] No [ ]

inserting, modifying, and removing
F-TAGs from relayed frames?
FF-S Does the S-VLAN component support PB AND FF:M 5.6.4, 44.2.2 Yes [ ] No [ ]
F-TAG processing on each PNP?
FF-B Does the B-component support F-TAG BEB AND FF:M 5.8.4, 44.2.2 Yes [ ] No [ ]
processing on each CBP and PNP?
A.7 Relay and filtering of frames

Insert the following item in A.7 at the end of the table:
RLY-?? Is the forwarding process for flow filtering FF:M 5.4.5.2, 44.2.3 Yes [ ] No [ ]
supported? N/A [ ]
A.14 Bridge management

In A.14 insert the following items at the end of the table:
MGT-?? Discard TTL expired counter MGT AND 12.6.1.1.3 Yes [ ] No [ ]

FF:M N/A [ ]
MGT-?? Flow filtering control table MGT AND 12.16.5.4, Yes [ ] No [ ]

FF:M 12.16.5.5 N/A [ ]
1
Copyright release for PICS proformas: Users of this standard may freely reproduce the PICS proforma in this annex so that it can be
used for its intended purpose and may further publish the completed PICS.
Std 802.1Qbp-2014
A.23 Connectivity Fault Management

Insert the following items in A.23 at the end of the table?
CFM-?? Are SPBM VID MAs supported? SPBM:O 27.18, 20 Yes [ ] No [ ]

N/A [ ]
CFM-?? Are SPBM group MAs supported? SPBM:O 27.18, 20 Yes [ ] No [ ]

N/A [ ]
CFM-?? Are SPBM path MAs supported? SPBM:O 27.18, 20 Yes [ ] No [ ]

N/A [ ]
CFM-?? Are ECMP path MAs supported? FF:O 44.2.5, 20 Yes [ ] No [ ]

N/A [ ]
A.24 Management Information Base (MIB)

Insert the following items in A.24 at the end of the table:
MIB-?? Are the IEEE8021-ECMP-MIB module MIB AND 5.4.5.1, 17.7.21 Yes [ ] No [ ]
objects ieee8021EcmpEctStaticTable and ECMP:O N/A [ ]
ieee8021EcmpTopSrvTable supported?
MIB-?? Is the IEEE8021-ECMP-MIB module MIB AND FF:O 5.4.5.2, 17.7.21 Yes [ ] No [ ]
fully supported (per its MODULE-COM- N/A [ ]
PLIANCE)?

802 1Qbp-2014

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

802 1Qbp-2014

Uploaded by

Copyright:

Available Formats

Media Access Control (MAC) Bridges and

Amendment 22: Equal Cost Multiple Path (ECMP)

IEEE Computer Society

IEEE Standard for

Media Access Control (MAC) Bridges and

Amendment 22: Equal Cost Multiple Path (ECMP)

Approved 27 March 2014

The Institute of Electrical and Electronics Engineers, Inc.

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

PDF: ISBN 978-0-7381-9001-3 STD98585

Notice and Disclaimer of Liability Concerning the Use of IEEE Standards

Copyright © 2014 IEEE. All rights reserved. iii

Comments on standards should be submitted to the following address:

Secretary, IEEE-SA Standards Board

Laws and regulations

iv Copyright © 2014 IEEE. All rights reserved.

Updating of IEEE Standards documents

Copyright © 2014 IEEE. All rights reserved. v

Tony Jeffree, Chair

Ting Ao Craig Gunther David Olsen

vi Copyright © 2014 IEEE. All rights reserved.

Peter Balma Michael Janezic Ron Peterson

Richard DeBlasio, DOE Representative

Copyright © 2014 IEEE. All rights reserved. vii

viii Copyright © 2014 IEEE. All rights reserved.

6.Support of the MAC Service ........................................................................................................................ 7

8.Principles of bridge operation....................................................................................................................... 9

12.Bridge management ...................................................................................................................................11

17.Management Information Base (MIB) ..................................................................................................... 20

19.Connectivity Fault Management Entity operation.................................................................................... 71

20.Connectivity Fault Management protocols............................................................................................... 73

Copyright © 2014 IEEE. All rights reserved. ix

22.Connectivity Fault Management in systems ............................................................................................. 86

27.Shortest Path Bridging (SPB) ................................................................................................................... 88

28.ISIS-SPB Link State Protocol................................................................................................................... 98

44.Equal Cost Multiple Paths ...................................................................................................................... 102

Annex A (normative)PICS proforma—Bridge implementations ................................................................ 112

x Copyright © 2014 IEEE. All rights reserved.

Figure 12-3 SPB Management objects ................................................................................................ 15

Copyright © 2014 IEEE. All rights reserved. xi

Table 17-1 Structure of the MIB modules .............................................................................................. 20

xii Copyright © 2014 IEEE. All rights reserved.

Media Access Control (MAC) Bridges and

Amendment 22: Equal Cost Multiple Path (ECMP)

Copyright © 2014 IEEE. All rights reserved. 1

2 Copyright © 2014 IEEE. All rights reserved.

Copyright © 2014 IEEE. All rights reserved. 3

Add the following abbreviations to Clause 4 in the appropriate location:

4 Copyright © 2014 IEEE. All rights reserved.

5.4 VLAN-aware Bridge component requirements

Change 5.4.5 as shown:

5.4.5 Shortest Path Bridging operation (optional)

5.4.5.1 SPBM Equal Cost Multiple Paths operation (optional)

a) Support SPBM ECMP as specified in 44.1;

c) Support the IEEE8021-ECMP-MIB module objects ieee8021EcmpEctStaticTable and

a) Support SPBM ECMP as specified in 44.1;

Copyright © 2014 IEEE. All rights reserved. 5

c) Support the management functionality specified in Clause 12.

5.6 S-VLAN component conformance

Insert new subclause 5.6.4 after 5.6.3:

5.6.4 S-VLAN component requirements for ECMP with flow filtering

a) Support F-TAG processing as specified in 44.2.2 on each PNP.

5.8 B-component conformance