802.1Q-2014

IEEE Standard for Local and metropolitan area networks—

Bridges and Bridged Networks

IEEE Computer Society

IEEE Standard for

Local and metropolitan area networks—

Bridges and Bridged Networks

Sponsor

LAN/MAN Standards Committee

of the

IEEE Computer Society

Approved 3 November 2014

IEEE-SA Standards Board

Abstract: This standard specifies how the Media Access Control (MAC) Service is supported by Bridged Networks, the principles of operation of those networks, and the operation of MAC Bridges and VLAN Bridges, including management, protocols, and algorithms

Keywords: Bridged Network, IEEE 802.1Q™, LAN, local area network, MAC Bridge, metropolitan area networks, MSTP, Multiple Spanning Tree Protocol, Rapid Spanning Tree Protocol, RSTP, PBN, Provider Bridged Network, Shortest Path Bridging Protocol, SPB Protocol, Virtual Bridged Network, virtual LAN, VLAN Bridge

The Institute of Electrical and Electronics Engineers, Inc.

3 Park Avenue, New York, NY 10016-5997, USA

IEEE and 802 are registered trademarks in the U.S. Patent & Trademark Office, owned by The Institute of Electrical and Electronics Engineers, Incorporated.

<table><tr><td>PDF:</td><td>ISBN 978-0-7381-9433-2</td><td>STD20044</td></tr><tr><td>Print:</td><td>ISBN 978-0-7381-9434-9</td><td>STDPD20044</td></tr></table>

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.

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 on 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.

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.

Participants

At the time this standard was submitted to the IEEE-SA Standards Board for approval, the IEEE 802.1 Working Group had the following membership:

Glenn Parsons, Chair

John Messenger, Vice Chair

Tony Jeffree, Editor

Stephen Haddock, Chair, Interworking Task Group

Ting Ao

Christian Boiger

Paul Bottorff

David Chen

Feng Chen

Weiying Cheng

Diego Crupnicoff

Rodney Cummings

Patrick Diamond

Aboubacar Kader Diarra

Janos Farkas

Norman Finn

Geoffrey Garner

Anoop Ghanwani

Mark Gravel

Eric W. Gray

Craig Gunther

Hitoshi Hayakawa

Jeremy Hitt

Rahil Hussain

Michael Johas Teener

Peter Jones

Hal Keen

Marcel Kiessling

Yongbum Kim

Philippe Klein

Jouni Korhonen

Jeff Lynch

Ben Mack-Crane

Christophe Mangin

James McIntosh

Eric Multanen

Donald Pannell

Karen Randall

Maximilian Riegel

Dan Romascanu

Jessy V. Rouyer

Panagiotis Saltsidis

Behcet Sarikaya

Michael Seaman

Daniel Sexton

Johannes Specht

Kevin B. Stanton

Wilfried Steiner

Vahid Tabatabaee

Patricia Thaler

Jeremy Touve

Karl Weber

Yuehua Wei

Brian Weis

Jordon Woods

Juan-Carlos Zuniga

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

Thomas Alexander

Butch Anton

Hugh Barrass

Christian Boiger

William Byrd

Juan Carreon

Keith Chow

Charles Cook

Rodney Cummings

Darold Davis

Sourav Dutta

Donald Eastlake

Richard Edgar

Donald Fedyk

Yukihiro Fujimoto

Randall Groves

Robert Grow

Craig Gunther

Chris Guy

Marek Hajduczenia

Werner Hoelzl

Rahil Hussain

Noriyuki Ikeuchi

Atsushi Ito

Tony Jeffree

Michael Johas Teener

Peter Jones

Shinkyo Kaku

Piotr Karocki

Stuart Kerry

Jeff Koftinoff

Bruce Kraemer

Hyeong Ho Lee

John Lemon

Elvis Maculuba

Roger Marks

Jeffery Masters

Jonathon Mclendon

John Messenger

Jose Morales

Michael Newman

Nick S. A. Nikjoo

Satoshi Obara

David Olsen

Glenn Parsons

Jean Pierre Picard

Maximilian Riegel

Robert Robinson

Benjamin Rolfe

Dan Romascanu

Jessy Rouyer

John Santhoff

Peter Saunderson

Bartien Sayogo

Michael Seaman

Shusaku Shimada

Kapil Sood

Kevin Stanton

Thomas Starai

Rene Struik

Walter Struppler

Joseph Tardo

William Taylor

Patricia Thaler

Dmitri Varsanofiev

Prabodh Varshney

Hung-Yu Wei

Andreas Wolf

Michael Wright

Oren Yuen

Daidi Zhong

Zhen Zhou

When the IEEE-SA Standards Board approved this standard on 3 November 2014, it had the following membership:

John Kulick, Chair

Jon Walter Rosdahl, Vice-chair

Richard H. Hulett, Past Chair

Konstantinos Karachalios, Secretary

Peter Balma

Farooq Bari

Ted Burse

Clint Chaplain

Stephen Dukes

Jean-Phillippe Faure

Gary Hoffman

Michael Janezic

Jeffrey Katz

Joseph L. Koepfinger*

David Law

Hung Ling

Oleg Logvinov

T. W. Olsen

Glenn Parsons

Ron Peterson

Adrian Stephens

Peter Sutherland

Yatin Trivedi

Phil Winston

Don Wright

Yu Yuan

*Member Emeritus

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

Richard DeBlasio, DOE Representative

Michael Janezic, NIST Representative

Michelle Turner

IEEE-SA Content Publishing

Kathryn M. Bennett

IEEE-SA Standards Technical Community

Historical participants

Since the initial publication, many IEEE standards have added functionality or provided updates to material included in this standard. The following is a historical list of participants who have dedicated their valuable time, energy, and knowledge to the creation of this material:

<table><tr><td>IEEE 802.1Q Standard</td><td>Date approved by IEEE</td><td>Officers at the time of Working Group Letter Ballot</td></tr><tr><td>IEEE Std 802.1Q-1998</td><td>8 December 1998</td><td>William P. Lidinsky, ChairMick Seaman, Chair, Interworking Task GroupTony Jeffree, Coordinating EditorAnil Rijsinghani, Richard Hausmann, Michele Wright, Paul Langille, P. J. Singh, Editorial Team</td></tr><tr><td>IEEE Std 802.1u-2001</td><td>17 March 2001</td><td>Tony Jeffree, ChairNeil Jarvis, Vice ChairMick Seaman, Chair, Interworking Task Group</td></tr><tr><td>IEEE Std 802.1v-2001</td><td>17 March 2001</td><td>Tony Jeffree, ChairNeil Jarvis, Vice ChairMick Seaman, Chair, Interworking Task GroupDavid Delany, EditorAndrew Smith, Editor</td></tr><tr><td>IEEE Std 802.1s-2002</td><td>11 December 2002</td><td>Tony Jeffree, ChairNeil Jarvis, Vice ChairMick Seaman, Chair, Interworking Task GroupNorman W. Finn, Editor</td></tr><tr><td>IEEE Std 802.1ad-2005</td><td>28 March 2005</td><td>Tony Jeffree, ChairPaul Congdon, Vice ChairMick Seaman, Chair, Interworking Task GroupStephen R. Haddock, Editor</td></tr><tr><td>IEEE Std 802.1Q-2005</td><td>7 December 2005</td><td>Tony Jeffree, Chair and EditorPaul Congdon, Vice ChairMick Seaman, Chair, Interworking Task Group</td></tr><tr><td>IEEE Std 802.1ak-2007</td><td>22 March 2007</td><td>Tony Jeffree, Chair and EditorPaul Congdon, Vice ChairMick Seaman, Chair, Interworking Task Group</td></tr><tr><td>IEEE Std 802.1ag-2007</td><td>27 September 2007</td><td>Tony Jeffree, ChairPaul Congdon, Vice ChairStephen R. Haddock, Chair, Interworking Task GroupNorman W. Finn, Editor-in-ChiefDavid V. Elie-Dit-Cosaque, Dinesh Mohan, Oscar Rodriguez, and Ali Sajassi, Assistant Editors</td></tr><tr><td>IEEE Std 802.1ah-2008</td><td>12 June 2008</td><td>Tony Jeffree, ChairPaul Congdon, Vice ChairStephen R. Haddock, Chair, Interworking Task GroupPaul Bottorff, Stephen Haddock, and Muneyoshi Suzuki, Editors</td></tr><tr><td>IEEE Std 802.1Q-2005/ Cor-1-2008</td><td>26 September 2008</td><td>Tony Jeffree, Chair and EditorPaul Congdon, Vice ChairStephen R. Haddock, Chair, Interworking Task Group</td></tr><tr><td>IEEE Std 802.1ap-2008</td><td>10 December 2008</td><td>Tony Jeffree, ChairPaul Congdon, Vice ChairStephen R. Haddock, Chair, Interworking Task GroupGlenn Parsons, EditorDavid Levi, Assistant Editor</td></tr><tr><td>IEEE Std 802.1Qaw-2009</td><td>17 June2009</td><td>Tony Jeffree, ChairPaul Congdon, Vice ChairStephen R. Haddock, Chair, Interworking Task GroupLinda Dunbar, Editor</td></tr><tr><td>IEEE Std 802.1Qay-2009</td><td>17 June2009</td><td>Tony Jeffree, ChairPaul Congdon, Vice ChairStephen R. Haddock, Chair, Interworking Task GroupPanagiotis Saltsidis, Editor</td></tr><tr><td>IEEE Std 802.1aj-2009</td><td>9 December 2009</td><td>Tony Jeffree, ChairPaul Congdon, Vice ChairStephen R. Haddock, Chair, Interworking Task GroupJohn Messenger, EditorBrian Hassink, MIB Editor</td></tr><tr><td>IEEE Std 802.1Qav-2009</td><td>9 November 2009</td><td>Tony Jeffree, Chair and EditorPaul Congdon, Vice ChairMichael Johas Teener, Chair, Audio Video Bridging Task Group</td></tr><tr><td>IEEE Std 802.1Qau-2010</td><td>25 March 2010</td><td>Tony Jeffree, ChairPaul Congdon, Vice ChairPatricia Thaler, Chair, Data CenterBridgingTask GroupNorman W. Finn, Editor</td></tr><tr><td>IEEE Std 802.1Qat-2010</td><td>30 September 2010</td><td>Tony Jeffree, ChairPaul Congdon, Vice ChairMichael Johas Teener, Chair, AudioVideo Bridging Task GroupCraig Gunther, Editor</td></tr><tr><td>IEEE Std 802.1Qbe-2011</td><td>16 June 2011</td><td>Tony Jeffree, ChairPaul Congdon, Vice ChairStephen Haddock, Chair, Interworking Task GroupNorman Finn, Editor</td></tr><tr><td>IEEE Std 802.1Qbc-2011</td><td>16 June 2011</td><td>Tony Jeffree, ChairPaul Congdon, Vice ChairStephen Haddock, Chair, Interworking Task GroupThomas Mack-Crane, Editor</td></tr><tr><td>IEEE Std 802.1Qbb-2011</td><td>16 June 2011</td><td>Tony Jeffree, ChairPaul Congdon, Vice ChairPatricia Thaler, Chair, Data CenterBridging Task GroupClaudio DeSanti, Editor</td></tr><tr><td>IEEE Std 802.1Qaz-2011</td><td>16 June 2011</td><td>Tony Jeffree, ChairPaul Congdon, Vice ChairPatricia Thaler, Chair, Data CenterBridging Task GroupCraig W. Carlson, Editor</td></tr><tr><td>IEEE Std 802.1Qbf-2011</td><td>7 December 2011</td><td>Tony Jeffree, ChairPaul Congdon, Vice ChairStephen Haddock, Chair, Interworking Task GroupRobert Sultan, Editor</td></tr><tr><td>IEEE Std 802.1aq-2012</td><td>29 March 2012</td><td>Tony Jeffree, ChairGlenn Parsons, Vice ChairStephen Haddock, Chair, Interworking Task GroupDonald Fedyk and Michael Seaman, Editors</td></tr><tr><td>IEEE Std 802.1Qbg-2012</td><td>14 May 2012</td><td>Tony Jeffree, Chair and EditorPaul Congdon, Vice ChairPatricia Thaler, Chair, Data CenterBridging Task GroupPaul Bottorff, Editor, Clauses 12 and 17</td></tr><tr><td>IEEE Std 802.1Q-2011/Cor-2-2012</td><td>19 October 2012</td><td>Tony Jeffree, Chair and EditorGlenn Parsons, Vice Chair and Chair, Maintenance Task Group</td></tr><tr><td>IEEE Std 802.1Qbp-2014</td><td>27 March 2014</td><td>Tony Jeffree, ChairGlenn Parsons, Vice ChairStephen Haddock, Chair, Interworking Task GroupBen Mack-Crane, Editor</td></tr></table>

IEEE 802.1Q Standard

IEEE Std 802.1D-2004

Date approved by IEEE

9 February 2004

Officers at the time of

Working Group Letter Ballot

Tony Jeffree, Chair and Editor

Paul Congdon, Vice Chair

Mick Seaman, Chair, Interworking Task

Group and Editor

Osama Aboul-Magd

Steve Adams

Stephen Ades

Fumio Akashi

Zehavit Alon

Ken Alonge

Ann Ambler

Paul D. Amer

Yafan An

Ting Ao

Charles Arnold

Peter Ashwood-Smith

Siamack Ayandeh

Floyd Backes

Ann Ballard

Richard Bantel

John Bartlett

Sy Bederman

Alexei Beliaev

Les Bell

Amatzia Ben-Artzi

Avner Ben-Dor

Michael Berger

Caitlin Bestler

Jan Bialkowski

James S. Binder

Robert Bledsoe

Rob Boatright

Kwami Boakaye

Christian Boiger

Brad Booth

Jean-Michel Bonnamy

Mike Borza

Paul Bottorff

David Brady

Rudolf Brandner

Martin Brewer

Frank Bruns

Juan Bulnes

Bill Bunch

Jim Burns

Peter Carbone

Bob Cardinal

Craig W. Carlson

Paul Carroll

Marco Carugi

Jeffrey Catlin

Dennis Cave

Dirceu Cavendish

Alan Chambers

Steve Chan

David W. Chang

Xin Chang

Frank Chao

Ken Chapman

Alice Chen

Weiying Cheng

Rao Cherukuri

Taesik Cheung

Jade Chien

Hon Wah Chin

Jin-Seek Choi

Chi Chong

Chris Christ

Marc Cochran

Paul Congdon

Glenn Connery

Alex Conta

Jim Corrigan

Diego Crupnicoff

David Cullerot

Rodney Cummings

Uri Cummings

Ted Davies

Andy Davis

Peter Dawe

Stan Degen

Arjan de Heer

Frank Deignan

David Delaney

Prakash Desai

Claudio DeSanti

Ron Dhondy

Jeffrey Dietz

Russell Dietz

Zhemin Ding

Kurt Dobbins

Eiji Doi

Barbara J. Don Carlos

Linda Dunbar

Craig Easley

Donald Eastlake, III

Peter Ecclesine

J. J. Ekstrom

Anush Elangovan

Hesham M. Elbakoury

Walter Eldon

David Elie-Dit-Cosaque

Janos Farkas

Donald W. Fedyk

Eldon D. Feist

Felix Feifei Feng

Norman Finn

Len Fishler

Kevin Flanagan

Yishai Fraenkel

Paul Frantz

David Frattura

Robert Frazier

Lars Henrik Frederiksen

Andre Fredette

John Fuller

Ilango Ganga

Geoffrey Garner

Anoop Ghanwani

Franz Goetz

Pat Gonia

Gerrard Goubert

Richard Graham

Mark Gravel

Michael A. Gravel

Eric Gray

Karanvir Grewal

John Grinham

Yingjie Gu

Craig Gunther

Mitch Gusat

Stephen Haddock

Sharam Hakimi

Mogens Hansen

Harold Harrington

John Hart

Scott Harvell

Mike Harvey

Takashi Hasegawa

Brian Hassink

Wayne Hathaway

Brian Hausauer

Richard Hausman

Hitoshi Hayakawa

Vic Hayes

Asif Hazarika

David Head

Gaby Hecht

Deepak Hegde

Ariel Hendel

Bob Herbst

John Hickey

David Hollender

Steve Horowitz

Bob Hott

Michelle Hsiung

Charles Hudson

Jack R. Hung

Rita Hunt

David Husak

Altaf Hussain

Thomas Hytry

Romain Insler

Ran Ish-Shalom

Jay Israel

Atsushi Iwata

Vipin K. Jain

Neil Jarvis

Tony Jeffree

Paul Hongkyu Jeong

Pankaj Jha

Markus Jochim

Michael Johas Teener

Girault Jones

Shyam Kaluve

Daya Kamath

Abhay Karandikar

Allen Kasey

Prakash Kashyap

Toyayuki Kato

Manu Kaycee

Hal Keen

Srikanth Keesara

Daniel Kelley

Kevin Ketchum

Keti Kilcrease

Doyeon Kim

Yongbum Kim

Alan Kirby

Kimberly Kirkpatrick

Keith Klamm

Steve Kleiman

Philippe Klein

Oliver Kleinberg

Bruce Kling

Walter Knitl

Mike Ko

Raghu Kondapalli

Michael Krause

Dan Krent

James Kristof

Vinod Kumar

Paul Kummer

Bruce Kwan

Paul Lachapelle

Kari Laihonen

Ashvin Lakshmikantha

Bill Lane

Paul Langille

Roger Lapuh

H. Eugene Latham

Loren Larsen

Yannick Le Goff

Marcus Leech

John Lemon

Michael Lerer

Lin Li

Bing Liao

George Lin

William P Lidinsky

Johann Lindmeyr

Marina Lipshteyn

Gary Littleton

Robert D. Love

Yuanqui Luo

Andy Luque

Jeff Lynch

Gael Mace

Thomas Mack-Crane

Phillip Magnuson

Mahalingam Mani

David Martin

Peter Martini

Riccardo Martinotti

Marco Mascitto

Keith McCloghrie

Bruce McClure

Tom McGowan

Alan McGuire

James McIntosh

Martin McNealis

Menucher Menuchery

Milan Merhar

Margaret A. Merrick

John Messenger

Colin Mick

Amol Mitra

Dinesh Mohan

Gabriel Montenegro

Jim Montrose

Matthew Mora

John Morris

Bob Moskowitz

Eric Multanen

Yaron Nachman

Yukihiro Nakagawa

Krishna Narayanaswamy

Lawrence Ng

Henry Ngai

Paul Nikolich

Kevin Nolish

Don O'Connor

Karen O'Donoghue

Jerry O'Keefe

Eugene O'Neil

Satoshi Obara

Hiroshi Ohta

David Olsen

Toshio Ooka

Jörg Ottensmeyer

Shlomo Ovadia

Vijoy Pandey

Don Pannell

Luc Pariseau

Glenn W. Parsons

Richard Patti

Ken Patton

Mark Pearson

Joseph Pelissier

Yonadav Perry

David Peterson

Roger Pfister

Thomas L. Phinney

John Pickens

Daniel Pitt

Hayim Porat

Gideon Prat

Kirk Preiss

Ron L. G. Prince

Max Pritikin

Ray Qiu

Rene Raeber

Ananda Rajagopal

Steve Ramberg

Nigel Ramsden

Karen Randall

Shlomo Reches

Frank Reichstein

Dick Reohr

Trudy Reusser

James Richmond

Anil Rijsinghani

Robert Roden

Edouard Rocher

Guenter Roeck

John J. Roese

Josef Roese

Derek J. Rohde

Allyn Romanow

Dan Romascanu

Paul Rosenblum

Moran Roth

Jessy V. Rouyer

Doug Ruby

Eric Ryu

Jonathan Sadler

Ali Sajassi

Dolors Sala

Joseph Salowey

John Salter

Panagiotis Saltsidis

Sam Sambasivan

Ray Samora

Alan Sarsby

Satish Sathe

John M. Sauer

Ayman Sayed

Susan Schanning

Ted Schroeder

Benjamin Schultz

Michael J. Seaman

Gerry Segal

Rich Seifert

Lee Sendelbach

Koichiro Seto

Himanshu Shah

Rakesh Sharma

Ravi Shenoy

Howard Sherry

K. Karl Shimada

Fred Shu

Wu-Shi Shung

Taeshi Shimizu

Phil Simmons

Curtis Simonson

Paramjeet Singh

Rosemary V. Slager

Alexander Smith

Andrew Smith

Michel Soerensen

M. Soha

Stuart Soloway

Nurit Sprecher

Kevin B. Stanton

Larry Stefani

Dan Stokesberry

Sundar Subramaniam

Robert Sultan

Muneyoshi Suzuki

Yoshihiro Suzuki

George Swallow

Lennart Swartz

Richard Sweatt

Attila Takacs

Kenta Takumi

Francois Tallet

Robin Tasker

Angus Telfer

John Terry

Patricia A. Thaler

Jonathan Thatcher

Dave Thompson

Geoff Thompson

Oliver Thorp

Michel Thorsen

Fouad Tobagi

Nathan Tobol

Jeremy Touve

Naoki Tsukutari

Fred Tuck

Chait Tumuluri

Wendell Turner

Paul Unbehagen

Dhadesugoor Vaman

Steve Van Seters

Dono van-Mierop

Peter Videcranz

John Viega

Maarten Vissers

Dennis Volpano

Manoj Wadekar

Paul Wainwright

Scott Wasson

Daniel Watts

Yuehua Wei

John Wakerly

Peter Wang

Philip Wang

Y. C. Wang

Yan Wang

Trevor Warwick

Bob Watson

Karl Weber

Brian Weis

Alan Weissberger

Glenn Wenig

Martin White

Bert Wijnen

Deborah Wilbert

Keith Willette

Robert Williams

Val Wilson

Ludwig Winkel

Robert Winter

Michael Witkowski

Edward Wong

Michael D. Wright

Michele Wright

Chien-Hsien Wu

Min Xiao

Ken Young

Allen Yu

Wayne Zakowski

Igor Zhovnirovsky

Carolyn Zimmer

Glen Zorn

Nick Zucchero

Introduction

This introduction is not part of IEEE Std 802.1Q-2014, IEEE Standard for Local and metropolitan area networks—Bridges and Bridged Networks.

IEEE Std 802.1Q-2014 incorporates the text of the following amendments into IEEE Std 802.1Q-2011.

<table><tr><td>IEEE Std 802.1QbeTM-2011</td><td>Multiple I-SID Registration Protocol</td></tr><tr><td>IEEE Std 802.1QbcTM-2011</td><td>Provider Bridging—Remote Customer Service Interfaces</td></tr><tr><td>IEEE Std 802.1QbbTM-2011</td><td>Priority-based Flow Control</td></tr><tr><td>IEEE Std 802.1QazTM-2011</td><td>Enhanced Transmission Selection for Bandwidth Sharing Between Traffic Classes</td></tr><tr><td>IEEE Std 802.1QbfTM-2011</td><td>PBB-TE Infrastructure Segment Protection</td></tr><tr><td>IEEE Std 802.1QbgTM-2012</td><td>Edge Virtual Bridging</td></tr><tr><td>IEEE Std 802.1aqTM-2012</td><td>Shortest Path Bridging</td></tr><tr><td>IEEE Std 802.1Q-2011/Cor 2-2012</td><td>Technical and editorial corrections</td></tr><tr><td>IEEE Std 802.1QbpTM-2014</td><td>Equal Cost Multiple Paths (ECMP)</td></tr></table>

The 2011 revision of this standard incorporated the text of the following amendments into IEEE Std 802.1Q-2005.

<table><tr><td>IEEE Std 802.1adTM-2005</td><td>Provider Bridges</td></tr><tr><td>IEEE Std 802.1akTM-2007</td><td>Multiple Registration Protocol</td></tr><tr><td>IEEE Std 802.1agTM-2007</td><td>Connectivity Fault Management</td></tr><tr><td>IEEE Std 802.1ahTM-2008</td><td>Provider Backbone Bridges</td></tr><tr><td>IEEE Std 802-1Q-2005/Cor-1-2008</td><td>Corrections to the Multiple Registration Protocol</td></tr><tr><td>IEEE Std 802.1apTM-2008</td><td>Management Information Base (MIB) Definitions for VLAN Bridges</td></tr><tr><td>IEEE Std 802.1QawTM-2009</td><td>Management of Data Driven and Data Dependent Connectivity Faults</td></tr><tr><td>IEEE Std 802.1QayTM-2009</td><td>Provider Backbone Bridge Traffic Engineering</td></tr><tr><td>IEEE Std 802.1ajTM-2009</td><td>Two-Port Media Access Control (MAC) Relay</td></tr><tr><td>IEEE Std 802.1QavTM-2009</td><td>Forwarding and Queuing Enhancements for Time-Sensitive Streams</td></tr><tr><td>IEEE Std 802.1QauTM-2010</td><td>Congestion Notification</td></tr><tr><td>IEEE Std 802.1QatTM-2010</td><td>Stream Reservation Protocol</td></tr></table>

Clause 13 of IEEE Std 802.1Q-2011 was also revised to include an updated specification of the Rapid Spanning Tree Algorithm and Protocol (RSTP), superseding references to IEEE Std 802.1D $^{TM}$ -2004 [B10]. $^{a}$

The 2005 revision of this standard incorporated the text of the following amendments into IEEE Std 802.1Q-1998.

<table><tr><td>IEEE Std 802.1uTM-2001</td><td>Technical and Editorial Corrections</td></tr><tr><td>IEEE Std 802.1vTM-2001</td><td>VLAN Classification by Protocol and Port</td></tr><tr><td>IEEE Std 802.1sTM-2002</td><td>Multiple Spanning Trees</td></tr></table>

This standard was first published as IEEE Std 802.1Q-1998, making use of the concepts and mechanisms of LAN Bridging that were introduced by IEEE Std 802.1D and defining additional mechanisms to allow the implementation of Virtual Bridged Networks.

For an introduction to this standard that details each of the provisions introduced by amendments and revisions throughout its development, refer to 1.3.

This standard contains state-of-the-art material. The area covered by this standard is undergoing evolution. Revisions are anticipated within the next few years to clarify existing material, to correct possible errors, and to incorporate new related material. Information on the current revision state of this and other IEEE 802 standards may be obtained from

Secretary, IEEE-SA Standards Board

445 Hoes Lane

Piscataway, NJ 08854-4141

USA

1 Overview.... 1

1.1 Scope....2

1.2 Purpose.... 2

1.3 Introduction....2

2 Normative references....9

3 Definitions.... 12

4 Abbreviations....32

5 Conformance....37

5.1 Requirements terminology....37

5.2 Conformant components and equipment 37

5.3 Protocol Implementation Conformance Statement (PICS).... 38

5.4 VLAN Bridge component requirements.... 38

5.4.1 VLAN Bridge component options 39

5.4.2 Multiple VLAN Registration Protocol (MVRP) requirements 43

5.4.3 VLAN Bridge requirements for congestion notification 44

5.4.4 Multiple Stream Registration Protocol (MSRP) requirements 44

5.4.5 Shortest Path Bridging (SPB) operation (optional) 45

5.5 C-VLAN component conformance....46

5.5.1 C-VLAN component options 46

5.6 S-VLAN component conformance 46

5.6.1 S-VLAN component options 47

5.6.2 S-VLAN component requirements for Provider Backbone Bridge Traffic Engineering (PBB-TE) 47

5.6.3 S-VLAN component requirements for PBB-TE IPS 47

5.6.4 S-VLAN component requirements for ECMP with flow filtering 48

5.7 I-component conformance 48

5.7.1 I-component options 48

5.8 B-component conformance....48

5.8.1 B-component options 49

5.8.2 B-component requirements for PBB-TE 49

5.8.3 B-component requirements for PBB-TE IPS 49

5.8.4 B-component requirements for ECMP with flow filtering 50

5.9 C-VLAN Bridge conformance.... 50

5.9.1 C-VLAN Bridge options 50

5.10 Provider Bridge conformance 50

5.10.1 S-VLAN Bridge conformance 50

5.10.2 Provider Edge Bridge conformance 51

5.11 System requirements for Priority-based Flow Control (PFC) 51

5.12 Backbone Edge Bridge (BEB) conformance 51

5.12.1 BEB requirements for PBB-TE 52

5.13 MAC Bridge component requirements.... 52

5.13.1 MAC Bridge component options 52

5.14 MAC Bridge conformance....53

5.14.1 MAC Bridge options 53

5.15 TPMR component conformance 53

5.15.1 TPMR component options 53

5.16 TPMR conformance....54

5.16.1 TPMR options 54

5.17 T-component conformance 54

5.17.1 T-component options 54

5.18 End station requirements for MMRP, MVRP, and MSRP 54

5.18.1 MMRP requirements and options 55

5.18.2 MVRP requirements and options 55

5.18.3 MSRP requirements and options 56

5.19 VLAN-aware end station requirements for CFM 56

5.20 End station requirements—FQTSS....57

5.21 End station requirements for congestion notification 57

5.22 MAC-specific bridging methods.... 58

5.23 EVB Bridge requirements....58

5.24 EVB station requirements 59

5.24.1 Edge relay (ER) requirements 59

Support of the MAC Service....61

6.1 Basic architectural concepts and terms 62

6.2 Provision of the MAC Service....62

6.2.1 Point-to-point, multipoint-to-multipoint, and rooted-multipoint connectivity ..... 63

6.3 Support of the MAC Service....63

6.4 Preservation of the MAC Service 64

6.5 Quality of service (QoS) maintenance....64

6.5.1 Service availability 64

6.5.2 Frame loss 65

6.5.3 Frame misordering 65

6.5.4 Frame duplication 66

6.5.5 Transit delay 67

6.5.6 Frame lifetime 68

6.5.7 Undetected frame error rate 68

6.5.8 Maximum Service Data Unit Size 68

6.5.9 Priority 68

6.5.10 Throughput 69

6.6 Internal Sublayer Service (ISS) 70

6.6.1 Control primitives and parameters 70

6.7 Support of the ISS by specific MAC procedures.... 70

6.7.1 Support of the ISS by IEEE Std 802.3 (Ethernet) 70

6.8 Enhanced Internal Sublayer Service (EISS) 70

6.8.1 Service primitives 71

6.8.2 Status parameters 72

6.8.3 Point-to-point parameters 72

6.8.4 Control primitives and parameters 72

6.9 Support of the EISS 72

6.9.1 Data indications 74

6.9.2 Data requests 75

6.9.3 Priority Code Point encoding 75

6.9.4 Regenerating priority 77

6.10 Support of the ISS/EISS by PIPs 78

6.10.1 Data indications 80

6.10.2 Data requests 81

6.10.3 Priority Code Point encoding 81

6.11 Support of the EISS by CBPs 82

6.11.1 Data indications 83

6.11.2 Data requests 84

6.11.3 Priority Code Point decoding 85

6.11.4 Regenerating priority 85

6.12 Protocol VLAN classification....85

6.12.1 Protocol Templates 87

6.12.2 Protocol Group Identifiers 87

6.12.3 Protocol Group Database 87

6.13 Support of the ISS for attachment to a PBN 88

6.13.1 Data requests 89

6.13.2 Data indications 90

6.14 Support of the ISS within a system....90

6.15 Support of the ISS by additional technologies....90

6.16 Filtering services in Bridged Networks 91

6.16.1 Purpose(s) of filtering service provision 91

6.16.2 Goals of filtering service provision 91

6.16.3 Users of filtering services 91

6.16.4 Basis of service 92

6.16.5 Categories of service 92

6.16.6 Service configuration 92

6.16.7 Service definition for Extended Filtering Services 93

6.17 EISS Multiplex Entity 94

6.18 Backbone Service Instance Multiplex Entity 95

6.18.1 Demultiplexing direction 96

6.18.2 Multiplexing direction 97

6.18.3 Priority Code Point encoding 98

6.18.4 Status parameters 98

6.19 TESI Multiplex Entity 98

6.20 Support of the ISS with signaled priority 99

6.20.1 Data indications 100

6.20.2 Data requests 100

6.21 Infrastructure Segment Multiplex Entity 100

Principles of Virtual Bridged Network operation.... 102

7.1 Network overview.... 102

7.2 Use of VLANs 103

7.3 Active topology.... 103

7.4 VLAN topology 104

7.5 Locating end stations 105

7.6 Ingress, forwarding, and egress rules.... 105

Principles of Bridge operation....107

8.1 Bridge operation.... 107

8.1.1 Relay 107

8.1.2 Filtering and relaying information 108

8.1.3 Duplicate frame prevention 108

8.1.4 Traffic segregation 108

8.1.5 Traffic reduction 109

8.1.6 Traffic expediting 109

8.1.7 Conversion of frame formats 109

8.2 Bridge architecture.... 110

8.3 Model of operation.... 112

8.4 Active topologies, learning, and forwarding.... 115

8.5 Bridge Port Transmit and Receive.... 117

8.5.1 Bridge Port connectivity 117

8.5.2 TPMR Port connectivity 118

8.5.3 Support of Higher Layer Entities 118

8.6 The Forwarding Process 119

8.6.1 Active topology enforcement 120

8.6.2 Ingress filtering 121

8.6.3 Frame filtering 121

8.6.4 Egress filtering 124

8.6.5 Flow classification and metering 124

8.6.6 Queuing frames 125

8.6.7 Queue management 126

8.6.8 Transmission selection 127

8.7 The Learning Process.... 129

8.7.1 Default filtering utility criteria 130

8.7.2 Enhanced filtering utility criteria 130

8.7.3 Ageing of Dynamic Filtering Entries 130

8.8 The Filtering Database (FDB) 131

8.8.1 Static Filtering Entries 134

8.8.2 Static VLAN Registration Entries 135

8.8.3 Dynamic Filtering Entries 136

8.8.4 MAC Address Registration Entries 136

8.8.5 Dynamic VLAN Registration Entries 137

8.8.6 Default Group filtering behavior 137

8.8.7 Dynamic Reservation Entries 139

8.8.8 Allocation of VIDs to FIDs 139

8.8.9 Querying the FDB 140

8.8.10 Determination of the member set for a VID 143

8.8.11 Permanent Database 144

8.8.12 Connection Identifier 144

8.9 MST, SPB, and ESP configuration information 144

8.9.1 MST Configuration Table 145

8.9.2 MST configuration identification 146

8.9.3 FID to MSTI Allocation Table 146

8.9.4 SPT Configuration Identification 146

8.10 Spanning Tree Protocol Entity.... 147

8.11 MRP entities 147

8.12 Bridge Management Entity 147

8.13 Addressing 148

8.13.1 End stations 148

8.13.2 Bridge Ports 148

8.13.3 Use of LLC by Spanning Tree Protocol Entities 148

8.13.4 Reserved MAC addresses 149

8.13.5 Group MAC addresses for spanning tree entity 149

8.13.6 Group MAC addresses for MRP Applications 151

8.13.7 Bridge Management Entities 151

8.13.8 Unique identification of a Bridge 152

8.13.9 Points of attachment and connectivity for Higher Layer Entities 152

8.13.10 VLAN attachment and connectivity for Higher Layer Entities 155

8.13.11 CFM entities 156

9 Tagged frame format....158

9.1 Purpose of tagging 158

9.2 Representation and encoding of tag fields 158

9.3 Tag format....159

9.4 TPID formats 159

9.5 Tag Protocol identification 159

9.6 VLAN Tag Control Information (TCI).... 160

9.7 Backbone Service Instance Tag Control Information (I-TAG TCI).... 161

10 Multiple Registration Protocol (MRP) and Multiple MAC Registration Protocol (MMRP) ...... 163

10.1 MRP overview 163

10.2 MRP architecture 166

10.3 MRP Attribute Propagation (MAP) 167

10.3.1 MAP Context 168

10.4 Requirements to be met by MRP 169

10.5 Requirements for interoperability between MRP Participants 170

10.6 Protocol operation.... 171

10.7 Protocol specification.... 175

10.7.1 Notational conventions and abbreviations 176

10.7.2 Registrar Administrative Controls 178

10.7.3 Applicant Administrative Controls 178

10.7.4 Protocol timers 178

10.7.5 Protocol event definitions 179

10.7.6 Protocol Action definitions 182

10.7.7 Applicant state machine 184

10.7.8 Registrar state machine 185

10.7.9 LeaveAll state machine 185

10.7.10 PeriodicTransmission state machine 186

10.7.11 Timer values 186

10.7.12 Operational reporting and statistics 187

10.7.13 Interoperability considerations 187

10.8 Structure and encoding of Multiple Registration Protocol Data Units (MRPDUs)...... 188

10.8.1 Structure 188

10.8.2 Encoding of MRPDU parameters 190

10.8.3 Packing and parsing MRPDUs 193

10.9 Multiple MAC Registration Protocol (MMRP)—Purpose 195

10.10 Model of operation.... 196

10.10.1 Propagation of Group Membership information 197

10.10.2 Propagation of Group service requirement information 198

10.10.3 Source pruning 198

10.10.4 Use of Group service requirement registration by end stations 198

10.11 Default Group filtering behavior and MMRP propagation.... 198

10.12 Definition of the MMRP application 200

10.12.1 Definition of MRP elements 200

10.12.2 Provision and support of Extended Filtering Services 202

10.12.3 Use of “new” declaration capability 204

10.12.4 Attribute value support requirements 204

10.12.5 Registrar Administrative Controls 205

11 VLAN topology management....206

11.1 Static and dynamic VLAN configuration 206

11.2 Multiple VLAN Registration Protocol (MVRP).... 207

11.2.1 MVRP overview 207

11.2.2 VLAN registration service definition 209

11.2.3 Definition of the MVRP application 210

11.2.4 VID translation table 213

11.2.5 Use of “new” declaration capability 213

11.2.6 New-Only Participant and Registrar Administrative Controls 213

11.2.7 Attribute value support requirements 213

12 Bridge management 214

12.1 Management functions.... 214

12.1.1 Configuration Management 214

12.1.2 Fault Management 215

12.1.3 Performance Management 215

12.1.4 Security Management 215

12.1.5 Accounting Management 215

12.2 VLAN Bridge objects 215

12.3 Data types.... 216

12.4 Bridge Management Entity 217

12.4.1 Bridge Configuration 217

12.4.2 Port configuration 220

12.5 MAC entities 222

12.5.1 ISS Port Number table managed object (optional) 222

12.6 Forwarding process.... 222

12.6.1 The Port Counters 223

12.6.2 Priority handling 223

12.6.3 Traffic Class Table 231

12.7 Filtering Database (FDB) 232

12.7.1 The Filtering Database object 232

12.7.2 A Static Filtering Entry object 233

12.7.3 A Dynamic Filtering Entry object 234

12.7.4 A MAC Address Registration Entry object 234

12.7.5 A VLAN Registration Entry object 234

12.7.6 Permanent Database object 234

12.7.7 General FDB operations 235

12.8 Bridge Protocol Entity 237

12.8.1 The Protocol Entity 237

12.8.2 Bridge Port 240

12.9 MRP Entities 244

12.9.1 The MRP Timer object 244

12.9.2 The MRP Attribute Type object 245

12.9.3 Periodic state machine objects 246

12.10 Bridge VLAN managed objects.... 247

12.10.1 Bridge VLAN Configuration managed object 247

12.10.2 VLAN Configuration managed object 252

12.10.3 The VID to FID allocation managed object 254

12.11 MMRP entities....256

12.11.1 MMRP Configuration managed object 256

12.12 MST configuration entities 258

12.12.1 The MSTI List 258

12.12.2 The FID to MSTID Allocation Table 259

12.12.3 The MST Configuration Table 260

12.13 Provider Bridge management 262

12.13.1 Provider Bridge Port Type managed object 263

12.13.2 Customer Edge Port Configuration managed object 264

12.13.3 Remote Customer Access Port Configuration managed object 267

12.14 CFM entities 269

12.14.1 Maintenance Domain list managed object 270

12.14.2 CFM Stack managed object 272

12.14.3 Default MD Level managed object 272

12.14.4 Configuration Error List managed object 274

12.14.5 Maintenance Domain managed object 274

12.14.6 Maintenance Association managed object 277

12.14.7 Maintenance association Endpoint managed object 279

12.15 Backbone Core Bridge (BCB) management.... 286

12.16 Backbone Edge Bridge (BEB) management.... 286

12.16.1 BEB configuration managed object 288

12.16.2 BEB/PB/VLAN Bridge Port configuration managed object 291

12.16.3 VIP configuration managed object 292

12.16.4 PIP configuration managed object 293

12.16.5 CBP Configuration managed object 300

12.17 DDCFM entities....302

12.17.1 DDCFM Stack managed object 303

12.17.2 Reflection Responder managed object 303

12.17.3 RFM Receiver managed object 307

12.17.4 Decapsulator Responder managed object 308

12.17.5 SFM Originator managed object 310

12.18 PBB-TE Protection Switching managed objects 313

12.18.1 TE protection group list managed object 313

12.18.2 TE protection group managed object 314

12.19 TPMR managed objects 316

12.19.1 TPMR management entity 317

12.19.2 MAC and PHY entities 319

12.19.3 Forwarding Process 319

12.19.4 MAC Status Propagation Entity (MSPE) 324

12.20 Management entities for FQTSS 326

12.20.1 The Bandwidth Availability Parameter Table 326

12.20.2 The Transmission Selection Algorithm Table 327

12.20.3 The Priority Regeneration Override Table 327

12.21 Congestion Notification managed objects 327

12.21.1 CN component managed object 328

12.21.2 CN component priority managed object 328

12.21.3 CN Port priority managed object 329

12.21.4 Congestion Point managed object 330

12.21.5 Reaction Point port priority managed object 331

12.21.6 Reaction Point group managed object 331

12.22 Stream Reservation Protocol (SRP) entities 332

12.22.1 SRP Bridge Base Table 332

12.22.2 SRP Bridge Port Table 332

12.22.3 SRP Latency Parameter Table 333

12.22.4 SRP Stream Table 333

12.22.5 SRP Reservations Table 333

12.23 Priority-based Flow Control objects 334

12.24 1:1 PBB-TE IPS managed objects 335

12.24.1 IPG list managed object 335

12.24.2 IPG managed object 336

12.25 Shortest Path Bridging managed objects 339

12.25.1 The SPB System managed object 340

12.25.2 The SPB MTID Static managed object 342

12.25.3 The SPB Topology Instance Dynamic managed object 343

12.25.4 The SPB ECT Static Entry managed object 344

12.25.5 The SPB ECT Dynamic Entry managed object 345

12.25.6 The SPB Adjacency Static Entry managed object 346

12.25.7 The SPB Adjacency Dynamic Entry managed object 347

12.25.8 The SPBM BSI Static Entry managed object 348

12.25.9 The SPB Topology Node Table managed object 349

12.25.10 The SPB Topology ECT Table managed object 350

12.25.11 The SPB Topology Edge Table managed object 351

12.25.12 The SPBM Topology Service Table managed object 352

12.25.13 The SPBV Topology Service Table managed object 353

12.25.14 The ECMP ECT Static Entry managed object 354

12.26 Edge Virtual Bridging (EVB) management.... 355

12.26.1 EVB system base table 358

12.26.2 SBP table entry 360

12.26.3 VSI table entry 361

12.26.4 S-channel configuration and management 363

12.26.5 ER management 366

12.27 Edge Control Protocol (ECP) management 367

12.27.1 ECP table entry 367

Spanning tree protocols.... 368

13.1 Protocol design requirements.... 369

13.2 Protocol support requirements 370

13.2.1 MSTP support requirements 370

13.2.2 SPB support requirements 370

13.3 Protocol design goals 371

13.4 RSTP overview 371

13.4.1 Computation of the active topology 372

13.4.2 Example topologies 373

13.5 MSTP overview 376

13.5.1 Example topologies 377

13.5.2 Relationship of MSTP to RSTP 380

13.5.3 Modeling an MST or SPT Region as a single Bridge 380

13.6 SPB overview.... 381

13.7 Compatibility and interoperability.... 382

13.7.1 Designated Port selection 382

13.7.1 Designated Port selection ....

13.7.1 Designated Port selection 382

13.8 MST Configuration Identifier (MCID) 383

13.9 Spanning tree priority vectors.... 384

13.10 CIST Priority Vector calculations.... 386

13.11 MST Priority Vector calculations 388

13.12 Port Role assignments.... 390

13.13 Stable connectivity.... 391

13.14 Communicating spanning tree information 392

13.15 Changing spanning tree information.... 393

13.16 Changing Port States with RSTP or MSTP 394

13.16.1 Subtree connectivity and priority vectors 395

13.16.2 Root Port transition to Forwarding 395

13.16.3 Designated Port transition to Forwarding 395

13.16.4 Master Port transition to Forwarding 397

13.17 Changing Port States with SPB 399

13.17.1 Agreement Digest 402

13.18 Managing spanning tree topologies 402

13.19 Updating learned station location information 403

13.20 Managing reconfiguration....405

13.21 Partial and disputed connectivity 406

13.22 In-service upgrades 406

13.23 Fragile Bridges 408

13.24 Spanning tree protocol state machines.... 408

13.25 State machine timers 410

13.25.1 edgeDelayWhile 411

13.25.2 fdWhile 411

13.25.3 helloWhen 411

13.25.4 mdelayWhile 411

13.25.5 rbWhile 411

13.25.6 rcvdInfoWhile 411

13.25.7 rrWhile 412

13.25.8 tcDetected 412

13.25.9 tcWhile 412

13.25.10 pseudoInfoHelloWhen 412

13.26 Per Bridge variables 412

13.26.1 agreementDigest 413

13.26.2 BridgeIdentifier 413

13.26.3 BridgePriority 413

13.26.4 BridgeTimes 413

13.26.5 ForceProtocolVersion 414

13.26.6 MigrateTime 414

13.26.7 MstConfigId 414

13.26.8 AuxMstConfigId 414

13.26.9 rootPortId 414

13.26.10 rootPriority 414

13.26.11 rootTimes 414

13.26.12 TxHoldCount 414

13.27 Per port variables 414

13.27.1 AdminEdge 417

13.27.2 ageingTime 417

13.27.3 agree 417

13.27.4 agreed 417

13.27.5 agreedAbove 417

13.27.6 agreedDigest 417

13.27.7 agreedDigestValid 417

13.27.8 agreeDigest 417

13.27.9 agreeDigestValid 417

13.27.10 agreedMisorder 418

13.27.11 agreedN 418

13.27.12 agreedND 418

13.27.13 agreedPriority 418

13.27.14 agreedTopology 418

13.27.15 agreementOutstanding 418

13.27.16 agreeN 418

13.27.17 agreeND 418

13.27.18 AutoEdge 418

13.27.19 AutoIsolate 419

13.27.20 designatedPriority 419

13.27.21 designatedTimes 419

13.27.22 disputed 419

13.27.23 enableBPDUrx 419

13.27.24 enableBPDUtx 419

13.27.25 ExternalPortPathCost 419

13.27.26 isL2gp 419

13.27.27 isolate 420

13.27.28fdbFlush 420

13.27.29 forward 420

13.27.30 forwarding 420

13.27.31 infoInternal 420

13.27.32 infoIs 420

13.27.33 InternalPortPathCost 420

13.27.34 learn 421

13.27.35 learning 421

13.27.36 master 421

13.27.37 mastered 421

13.27.38 mcheck 421

13.27.39 msgPriority 421

13.27.40 msgTimes 421

13.27.41 neighbourPriority 422

13.27.42 newInfo 422

13.27.43 newInfoMsti 422

13.27.44 operEdge 422

13.27.45 portEnabled 422

13.27.46 portId 422

13.27.47 portPriority 422

13.27.48 portTimes 423

13.27.49 proposed 423

13.27.50 proposing 423

13.27.51 pseudoRootId 423

13.27.52 rcvdBPDU 423

13.27.53 rcvdInfo 423

13.27.54 rcvdInternal 423

13.27.55 rcvdMsg 423

13.27.56 rcvdRSTP 423

13.27.57 rcvdSTP 423

13.27.58 rcvdTc 423

13.27.59 rcvdTcAck 423

13.27.60 rcvdTcn 424

13.27.61 reRoot 424

13.27.62 reselect 424

13.27.63 restrictedDomainRole 424

13.27.64 restrictedRole 424

13.27.65 restrictedTcn 424

13.27.66 role 424

13.27.67 selected 424

13.27.68 selectedRole 424

13.27.69 sendRSTP 425

13.27.70 sync 425

13.27.71 synced 425

13.27.72 tcAck 425

13.27.73 tcProp 425

13.27.74 tick 425

13.27.75 txCount 425

13.27.76 updtInfo 425

13.28 State machine conditions and parameters 425

13.28.1 allSptAgree 426

13.28.2 allSynced 426

13.28.3 allTransmitReady 426

13.28.4 BestAgreementPriority 426

13.28.5 cist 426

13.28.6 cistRootPort 426

13.28.7 cistDesignatedPort 427

13.28.8 EdgeDelay 427

13.28.9 forwardDelay 427

13.28.10 FwdDelay 427

13.28.11 HelloTime 427

13.28.12 MaxAge 427

13.28.13 msti 427

13.28.14 mstiDesignatedOrTCpropagatingRootPort 427

13.28.15 mstiMasterPort 427

13.28.16 operPointToPoint 427

13.28.17 rcvdAnyMsg 427

13.28.18 rcvdCistMsg 427

13.28.19 rcvdMstiMsg 428

13.28.20 reRooted 428

13.28.21 rstpVersion 428

13.28.22 spt 428

13.28.23 stpVersion 428

13.28.24 updtCistInfo 428

13.28.25 updtMstiInfo 428

13.29 State machine procedures 428

13.29.1 betterorsameInfo(newInfoIs) 429

13.29.2 clearAllRcvdMsgs() 429

13.29.3 clearReselectTree() 429

13.29.4 disableForwarding() 430

13.29.5 disableLearning() 430

13.29.6 enableForwarding() 430

13.29.7 enableLearning() 430

13.29.8 fromSameRegion() 430

13.29.9 newTcDetected() 430

13.29.10 newTcWhile() 430

13.29.11 pseudoRcvMsgs() 431

13.29.12 rcvInfo() 431

13.29.13 rcvMsgs() 432

13.29.14 rcvAgreements() 432

13.29.15 recordAgreement() 432

13.29.16 recordDispute() 433

13.29.17 recordMastered() 433

13.29.18 recordPriority() 433

13.29.19 recordProposal() 433

13.29.20 recordTimes() 433

13.29.21 setReRootTree() 434

13.29.22 setSelectedTree() 434

13.29.23 setSyncTree() 434

13.29.24 setTcFlags() 434

13.29.25 setTcPropTree() 434

13.29.26 syncMaster() 434

13.29.27 txConfig() 434

13.29.28 txRstp() 435

13.29.29 txTcn() 435

13.29.30 updtAgreement() 435

13.29.31 updtBPDUVersion() 436

13.29.32 updtDigest() 436

13.29.33 updtRcvdInfoWhile() 437

13.29.34 updtRolesTree() 438

13.29.35 uptRolesDisabledTree() 439

13.30 The Port Timers state machine 440

13.31 Port Receive state machine 440

13.32 Port Protocol Migration state machine 441

13.33 Bridge Detection state machine 441

13.34 Port Transmit state machine 442

13.35 Port Information state machine 443

13.36 Port Role Selection state machine.... 444

13.37 Port Role Transitions state machine 444

13.38 Port State Transition state machine.... 449

13.38.1 Port State transitions for the CIST and MSTIs 450

13.38.2 Port State transitions for SPTs 450

13.39 Topology Change state machine 451

13.40 Layer 2 Gateway Port Receive state machine.... 452

13.41 CEP spanning tree operation.... 452

13.41.1 PEP operPointToPointMAC and operEdge 452

13.41.2 updtRolesTree() 453

13.41.3 setReRootTree(), setSyncTree(), setTcPropTree() 453

13.41.4 allSynced, reRooted 453

13.41.5 Configuration parameters 453

13.42 Virtual Instance Port (VIP) spanning tree operation.... 454

Encoding of Bridge Protocol Data Units (BPDUs) 455

14.1 BPDU Structure 455

14.1.1 Transmission and representation of octets 455

14.1.2 Common BPDU fields 457

14.2 Encoding of parameter types 457

14.2.1 Encoding of Protocol Identifiers 457

14.2.2 Encoding of Protocol Version Identifiers 457

14.2.3 Encoding of BPDU types 457

14.2.4 Encoding of flags 457

14.2.5 Encoding of Bridge Identifiers 457

14.2.6 Encoding of External Root Path Cost and Internal Root Path Cost 458

14.2.7 Encoding of Port Identifiers 458

14.2.8 Encoding of Timer Values 459

14.2.9 Encoding of Port Role values 459

14.2.10 Encoding of Length Values 459

14.2.11 Encoding of Hop Counts 459

14.3 Transmission of BPDUs 459

14.4 Encoding and decoding of STP Configuration, RST, MST, and SPT BPDUs.... 460

14.4.1 MSTI Configuration Messages 461

14.5 Validation of received BPDUs.... 462

14.6 Validation and interoperability 463

Support of the MAC Service by PBNs 465

15.1 Service transparency 465

15.2 Customer service interfaces 466

15.3 Port-based service interface 466

15.4 C-tagged service interface.... 467

15.5 S-tagged service interface 468

15.6 Remote customer service interfaces (RCSIs) 469

15.7 Service instance segregation 472

15.8 Service instance selection and identification 472

15.9 Service priority selection 473

15.10 Service access protection 474

Principles of Provider Bridged Network (PBN) operation 475

16.1 PBN overview 475

16.2 Provider Bridged Network (PBN) 476

16.3 Service instance connectivity....479

16.4 Service provider learning of customer end station addresses 480

16.5 Detection of connectivity loops through attached networks 480

16.6 Network management 481

Management Information Base (MIB)......482

17.1 Internet Standard Management Framework 482

17.2 Structure of the MIB 482

17.2.1 Structure of the IEEE8021-TC-MIB 483

17.2.2 Structure of the IEEE8021-BRIDGE-MIB 485

17.2.3 Structure of the IEEE8021-SPANNING-TREE MIB 490

17.2.4 Structure of the IEEE8021-Q-BRIDGE-MIB 492

17.2.5 Structure of the IEEE8021-PB-MIB 499

17.2.6 Structure of the IEEE8021-MSTP-MIB 500

17.2.7 Structure of the IEEE8021-CFM-MIB 503

17.2.8 Structure of the IEEE8021-PBB-MIB 509

17.2.9 Structure of the IEEE8021-DDCFM-MIBs 512

17.2.10 Structure of the IEEE8021-PBBTE-MIB 514

17.2.11 Structure of the TPMR MIB 517

17.2.12 Structure of the IEEE8021-FQTSS-MIB 519

17.2.13 Structure of the Congestion Notification MIB 520

17.2.14 Structure of the IEEE8021-SRP-MIB 522

17.2.15 Structure of the MVRP extension MIB 524

17.2.16 Structure of the MIRP MIB 524

17.2.17 Structure of the PFC MIB 525

17.2.18 Structure of the IEEE80221-TEIPS MIB 525

17.2.19 Structure of the IEEE8021-SPB-MIB 527

17.2.20 Structure of the IEEE8021-EVB-MIB 531

17.2.21 Structure of the IEEE8021-ECMP-MIB 534

17.3 Relationship to other MIBs....535

17.3.1 Relationship of the IEEE8021-TC-MIB to other MIB modules 535

17.3.2 Relationship of the IEEE8021-BRIDGE-MIB to other MIB modules ..... 536

17.3.3 Relationship of the IEEE8021-RSTP MIB to other MIB modules 538

17.3.4 Relationship of the IEEE8021-Q-BRIDGE-MIB to other MIB modules ..... 538

17.3.5 Relationship of the IEEE8021-PB-BRIDGE MIB to other MIB modules ..... 540

17.3.6 Relationship of the IEEE8021-MSTP-MIB to other MIB modules 540

17.3.7 Relationship of the IEEE8021-CFM-MIB to other MIB modules 540

17.3.8 Relationship of the IEEE8021-PBB-MIB to other MIB modules 541

17.3.9 Relationship of the IEEE8021-DDCFM to other MIB modules 543

17.3.10 Relationship of the IEEE8021-PBBTE-MIB to other MIB modules 543

17.3.11 Relationship of the TPMR MIB to other MIB modules 543

17.3.12 Relationship of the IEEE8021-FQTSS-MIB to other MIB modules 544

17.3.13 Relationship of the IEEE802-CN-MIB to other MIB modules 544

17.3.14 Relationship of the IEEE8021-SRP-MIB to other MIB modules 544

17.3.15 Relationship of the IEEE8021-MVRPX-MIB to other MIB modules ..... 544

17.3.16 Relationship of the IEEE8021-MIRP-MIB to other MIB modules 545

17.3.17 Relationship of the PFC MIB to other MIB modules 545

17.3.18 Relationship of the IEEE8021-TEIPS-MIB to other MIB modules 545

17.3.19 Relationship of the of the IEEE8021-SPB-MIB to other MIB modules ..... 545

17.3.20 Relationship of the IEEE8021-EVB-MIB to other MIB modules 545

17.3.21 Relationship of the of the IEEE8021-ECMP-MIB to other MIB modules ..... 545

17.4 Security considerations 546

17.4.1 Security considerations of the IEEE8021-TC-MIB 546

17.4.2 Security considerations of the IEEE8021-BRIDGE-MIB 546

17.4.3 Security considerations of the IEEE8021-SPANNING-TREE MIB 547

17.4.4 Security considerations of the IEEE8021-Q-BRIDGE-MIB 548

17.4.5 Security considerations of the IEEE8021-PB-MIB 549

17.4.6 Security considerations of the IEEE8021-MSTP-MIB 549

17.4.7 Security considerations of the IEEE8021-CFM-MIB 549

17.4.8 Security considerations of the IEEE8021-PBB-MIB 552

17.4.9 Security considerations of the IEEE8021-DDCFM-MIB 552

17.4.10 Security considerations of the IEEE8021-PBBTE-MIB 553

17.4.11 Security considerations of the TPMR MIB 554

17.4.12 Security considerations of the IEEE8021-FQTSS-MIB 554

17.4.13 Security considerations of the Congestion Notification MIB 555

17.4.14 Security considerations of the IEEE8021-SRP-MIB 556

17.4.15 Security considerations of the IEEE8021-MVRPX-MIB 557

17.4.16 Security considerations of the IEEE8021-MIRP-MIB 557

17.4.17 Security considerations for the PFC MIB 558

17.4.18 Security considerations of the IEEE8021-TEIPS-MIB 558

17.4.19 Security considerations of the IEEE8021-SPB-MIB 558

17.4.20 Security considerations of the IEEE8021-EVB-MIB 559

17.4.21 Security considerations of the IEEE8021-ECMP-MIB 560

17.5 Dynamic component and Port creation.... 561

17.5.1 Overview of the dynamically created Bridge entities 561

17.5.2 Component creation 562

17.5.3 Port creation 563

17.6 MIB operations for service interface configuration....573

17.6.1 Provisioning PBN service interfaces 573

17.6.2 Provisioning Backbone Bridged Network service interfaces 576

17.7 MIB modules, 582

17.7.1 Definitions for the IEEE8021-TC-MIB module 582

17.7.2 Definitions for the IEEE8021-BRIDGE-MIB module 593

17.7.3 Definitions for the IEEE8021-SPANNING-TREE-MIB module 633

17.7.4 Definitions for the IEEE8021-Q-BRIDGE-MIB module 651

17.7.5 Definitions for the IEEE8021-PB-MIB module 697

17.7.6 Definitions for the IEEE8021-MSTP-MIB module 715

17.7.7 Definitions for the CFM MIB modules 744

17.7.8 Definitions for the IEEE8021-PBB-MIB module 826

17.7.9 Definitions for the IEEE8021-DDCFM-MIB module 849

17.7.10 Definitions for the IEEE8021-PBBTE-MIB module 867

17.7.11 Definitions for the IEEE8021-TPMR-MIB module 884

17.7.12 Definitions for the IEEE8021-FQTSS-MIB module 898

17.7.13 Definitions for the IEEE8021-CN-MIB module 909

17.7.14 Definitions for the IEEE8021-SRP-MIB module 945

17.7.15 Definitions for the IEEE8021-MVRPX-MIB module 961

17.7.16 Definitions for the IEEE8021-MIRP-MIB module 966

17.7.17 Definitions for the IEEE8021-PFC-MIB module 972

17.7.18 Definitions for the IEEE8021-TEIPS-V2-MIB module 976

17.7.19 Definitions for the IEEE8021-SPB-MIB module 990

17.7.20 Definitions for the IEEE8021-EVB-MIB module 1027

17.7.21 Definitions for the IEEE8021-ECMP-MIB module 1056

Principles of Connectivity Fault Management operation 1064

18.1 Maintenance Domains and DoSAPs.... 1065

18.2 Service instances and MAs 1067

18.3 Maintenance Domain Levels 1068

CFM entity operation.... 1072

19.1 Maintenance Points.... 1072

19.2 MA Endpoints (MEPs) 1073

19.2.1 MEP identification 1073

19.2.2 MEP functions 1074

19.2.3 MEP architecture 1074

19.2.4 MP Type Demultiplexer 1076

19.2.5 MP Multiplexer 1076

19.2.6 MP Level Demultiplexer 1076

19.2.7 MP OpCode Demultiplexer 1076

19.2.8 MEP Continuity Check Receiver 1077

19.2.9 MEP Continuity Check Initiator 1077

19.2.10 MP Loopback Responder 1078

19.2.11 MEP Loopback Initiator 1078

19.2.12 MEP Linktrace Initiator 1078

19.2.13 MEP LTI SAP 1078

19.2.14 MEP Linktrace SAP 1078

19.2.15 MEP CCM Database 1078

19.2.16 MEP Fault Notification Generator 1078

19.2.17 MEP Decapsulator Responder (DR) 1079

19.2.18 MEP RFM Receiver 1079

19.3 MIP Half Function 1079

19.3.1 MHF identification 1079

19.3.2 MHF functions 1079

19.3.3 MHF architecture 1080

19.3.4 MHF Level Demultiplexer 1080

19.3.5 MHF Type Demultiplexer 1080

19.3.6 MHF OpCode Demultiplexer 1080

19.3.7 MHF Multiplexer 1080

19.3.8 MHF Loopback Responder 1080

19.3.9 MHF Continuity Check Receiver 1081

19.3.10 MIP CCM Database 1081

19.3.11 MHF Linktrace SAP 1082

19.3.12 MHF DR 1082

19.3.13 MHF RFM Receiver 1082

19.4 MP addressing.... 1082

19.5 Linktrace Output Multiplexer (LOM).... 1083

19.6 Linktrace Responder 1083

CFM protocols 1085

20.1 Continuity Check protocol 1086

20.1.1 MAC status reporting in the CCM 1088

20.1.2 Defects and Fault Alarms 1088

20.1.3 CCM reception 1089

20.2 Loopback protocol 1089

20.2.1 LBM transmission 1090

20.2.2 LBM reception and LBR transmission 1090

20.2.3 LBR reception 1091

20.3 Linktrace protocol 1091

20.3.1 LTM origination 1092

20.3.2 LTM reception, forwarding, and replying 1093

20.3.3 LTR reception 1094

20.4 CFM state machines 1095

20.5 CFM state machine timers 1095

20.5.1 LTFwhile 1097

20.5.2 CCIwhile 1097

20.5.3 errorCCMwhile 1097

20.5.4 xconCCMwhile 1097

20.5.5 LBIwhile 1097

20.5.6 FNGwhile 1097

20.5.7 mmCCMwhile 1097

20.5.8 mmLocwhile 1097

20.5.9 mmFNGwhile 1097

20.5.10 rMEPwhile 1097

20.6 CFM procedures 1098

20.6.1 CCMtime() 1098

20.7 Maintenance Domain variable 1098

20.7.1 mdLevel 1098

20.8 MA variables 1098

20.8.1 CCMinterval 1098

20.9 MEP variables 1098

20.9.1 MEPactive 1099

20.9.2 enableRmepDefect 1099

20.9.3 MAdefectIndication 1100

20.9.4 allRMEPsDead 1100

20.9.5 lowestAlarmPri 1100

20.9.6 presentRDI 1100

20.9.7 MEPprimaryVID 1100

20.9.8 presentTraffic 1100

20.9.9 presentmmLoc 1100

20.9.10 ISpresentTraffic 1101

20.9.11 ISpresentmmLoc 1101

20.9.12 EpMEP 1101

20.10 MEP Continuity Check Initiator variables.... 1101

20.10.1 CCIenabled 1101

20.10.2 CCIsentCCMs 1101

20.10.3 MACstatusChanged 1101

20.10.4 Npaths 1101

20.10.5 flowHash[] 1102

20.10.6 pathN 1102

20.10.7 CCMcnt 1102

20.11 MEP Continuity Check Initiator procedures 1102

20.11.1 xmitCCM() 1102

20.12 MEP Continuity Check Initiator state machine 1103

20.13 MHF Continuity Check Receiver variables 1103

20.13.1 MHFrecvdCCM 1104

20.13.2 MHFCCMPDU 1104

20.14 MHF Continuity Check Receiver procedures 1104

20.14.1 MHFprocessCCM() 1104

20.15 MHF Continuity Check Receiver state machine 1104

20.16 MEP Continuity Check Receiver variables 1104

20.16.1 CCMreceivedEqual 1105

20.16.2 CCMequalPDU 1105

20.16.3 CCMreceivedLow 1105

20.16.4 CCMlowPDU 1105

20.16.5 recvdMacAddress 1105

20.16.6 recvdRDI 1105

20.16.7 recvdInterval 1105

20.16.8 recvdPortState 1106

20.16.9 recvdInterfaceStatus 1106

20.16.10 recvdSenderId 1106

20.16.11 recvdFrame 1106

20.16.12 CCMsequenceErrors 1106

20.16.13 rcvdTrafficBit 1106

20.17 MEP Continuity Check Receiver procedures 1106

20.17.1 MEPprocessEqualCCM() 1106

20.17.2 MEPprocessLowCCM() 1107

20.18 MEP Continuity Check Receiver state machine 1107

20.19 Remote MEP variables 1108

20.19.1 rMEPCCMdefect 1108

20.19.2 rMEPlastRDI and rMEPlastRDI[i] 1108

20.19.3 rMEPlastPortState 1109

20.19.4 rMEPlastInterfaceStatus 1109

20.19.5 rMEPlastSenderId 1109

20.19.6 rCCMreceived 1109

20.19.7 rMEPmacAddress 1109

20.19.8 rMEPportStatusDefect 1109

20.19.9 rMEPinterfaceStatusDefect 1109

20.19.10 lastPathN 1109

20.20 Remote MEP state machine 1110

20.21 Remote MEP Error variables 1110

20.21.1 errorCCMreceived 1111

20.21.2 errorCCMlastFailure 1111

20.21.3 errorCCMdefect 1111

20.22 Remote MEP Error state machine 1111

20.23 MEP Cross Connect variables 1111

20.23.1 xconCCMreceived 1112

20.23.2 xconCCMlastFailure 1112

20.23.3 xconCCMdefect 1112

20.24 MEP Cross Connect state machine 1112

20.25 MEP Mismatch variables.... 1113

20.25.1 mmCCMreceived 1113

20.25.2 mmCCMdefect 1113

20.25.3 mmCCMTime 1113

20.25.4 disableLocdefect 1113

20.25.5 mmLocdefect 1113

20.26 MEP Mismatch state machines.... 1114

20.27 MP Loopback Responder variables 1115

20.27.1 LBMreceived 1115

20.27.2 LBMPDU 1115

20.28 MP Loopback Responder procedures 1115

20.28.1 ProcessLBM() 1115

20.28.2 xmitLBR() 1116

20.29 MP Loopback Responder state machine 1116

20.30 MEP Loopback Initiator variables 1117

20.30.1 LBMsToSend 1117

20.30.2 nextLBMtransID 1117

20.30.3 expectedLBRtransID 1117

20.30.4 LBIactive 1117

20.30.5 xmitReady 1117

20.30.6 LBRreceived 1117

20.30.7 LBRPDU 1117

20.31 MEP Loopback Initiator transmit procedures 1118

20.31.1 xmitLBM() 1118

20.32 MEP Loopback Initiator transmit state machine 1119

20.33 MEP Loopback Initiator receive procedures 1119

20.33.1 ProcessLBR() 1119

20.34 MEP Loopback Initiator receive state machine 1120

20.35 MEP Fault Notification Generator variables 1120

20.35.1 fngPriority 1120

20.35.2 fngDefect 1121

20.35.3 fngAlarmTime 1121

20.35.4 fngResetTime 1121

20.35.5 someRMEPCCMdefect 1121

20.35.6 someMACstatusDefect 1121

20.35.7 someRDIdefect 1121

20.35.8 highestDefectPri 1121

20.35.9 highestDefect 1121

20.36 MEP Fault Notification Generator procedures 1122

20.36.1 xmitFaultAlarm() 1122

20.37 MEP Fault Notification Generator state machine 1122

20.38 MEP Mismatch Fault Notification Generator variables 1123

20.38.1 mfngAllowed 1123

20.38.2 mmdefectIndication 1123

20.38.3 mfngAlarmTime 1123

20.38.4 mfngResetTime 1123

20.39 MEP Mismatch Fault Notification Generator procedures 1123

20.39.1 xmitFaultAlarm() 1123

20.40 MEP Mismatch Fault Notification Generator state machine 1124

20.41 MEP Linktrace Initiator variables 1124

20.41.1 nextLTMtransID 1124

20.41.2 ltmReplyList 1125

20.42 MEP Linktrace Initiator procedures 1126

20.42.1 xmitLTM() 1127

20.43 MEP Linktrace Initiator receive variables 1127

20.43.1 LTRreceived 1127

20.43.2 LTRPDU 1128

20.44 MEP Linktrace Initiator receive procedures 1128

20.44.1 ProcessLTR() 1128

20.45 MEP Linktrace Initiator receive state machine 1128

20.46 Linktrace Responder variables 1129

20.46.1 nPendingLTRs 1129

20.46.2 LTMreceived 1129

20.46.3 LTMPDU 1129

20.47 LTM Receiver procedures 1129

20.47.1 ProcessLTM() 1129

20.47.2 clearPendingLTRs() 1133

20.47.3 ForwardLTM() 1134

20.47.4 enqueLTR() 1134

20.48 LTM Receiver state machine 1136

20.49 LTR Transmitter procedure 1136

20.49.1 xmitOldestLTR() 1136

20.50 LTR Transmitter state machine 1136

20.51 CFM PDU validation and versioning 1137

20.51.1 Goals of CFM PDU versioning 1137

20.51.2 PDU transmission 1137

20.51.3 PDU validation 1138

20.51.4 Validation pass 1138

20.51.5 Execution pass 1139

20.51.6 Future extensions 1140

20.52 PDU identification 1140

20.53 Use of transaction IDs and sequence numbers 1141

Encoding of CFM PDUs 1142

21.1 Structure, representation, and encoding 1142

21.2 CFM encapsulation 1142

21.3 CFM request and indication parameters 1143

21.3.1 destination_address parameter 1143

21.3.2 source_address parameter 1143

21.4 Common CFM Header 1144

21.4.1 MD Level 1144

21.4.2 Version 1144

21.4.3 OpCode 1144

21.4.4 Flags 1145

21.4.5 First TLV Offset 1145

21.5 TLV format 1145

21.5.1 General format for CFM TLVs 1145

21.5.2 Organization-Specific TLV 1146

21.5.3 Sender ID TLV 1147

21.5.4 Port Status TLV 1149

21.5.5 Interface Status TLV 1149

21.5.6 Data TLV 1150

21.5.7 End TLV 1150

21.6 CCM format 1151

21.6.1 Flags 1151

21.6.2 First TLV Offset 1152

21.6.3 Sequence Number 1152

21.6.4 Maintenance association Endpoint Identifier 1153

21.6.5 Maintenance Association Identifier 1153

21.6.6 Defined by ITU-T Y.1731 (02/2008) 1155

21.6.7 Optional CCM TLVs 1155

21.7 LBM and LBR formats 1156

21.7.1 Flags 1156

21.7.2 First TLV Offset 1156

21.7.3 Loopback Transaction Identifier 1156

21.7.4 Additional LBM/LBR TLVs 1156

21.7.5 PBB-TE MIP TLV 1157

21.8 LTM format 1158

21.8.1 Flags 1158

21.8.2 First TLV Offset 1158

21.8.3 LTM Transaction Identifier 1158

21.8.4 LTM TTL 1159

21.8.5 Original MAC Address 1159

21.8.6 Target MAC Address 1159

21.8.7 Additional LTM TLVs 1159

21.8.8 LTM Egress Identifier TLV 1159

21.9 LTR format 1160

21.9.1 Flags 1160

21.9.2 First TLV Offset 1161

21.9.3 LTR Transaction Identifier 1161

21.9.4 Reply TTL 1161

21.9.5 Relay Action 1161

21.9.6 Additional LTR TLVs 1161

21.9.7 LTR Egress Identifier TLV 1162

21.9.8 Reply Ingress TLV 1162

21.9.9 Reply Egress TLV 1163

CFM in systems 1166

22.1 CFM shims in Bridges 1166

22.1.1 Preliminary positioning of MPs 1166

22.1.2 CFM and the Forwarding Process 1167

22.1.3 Up/Down separation of MPs 1169

22.1.4 Service instances over multiple Bridges 1171

22.1.5 Multiple VID service instances 1173

22.1.6 Untagged CFM PDUs 1173

22.1.7 MPs and non-VLAN aware Bridges 1173

22.1.8 MPs and other standards 1174

22.1.9 CFM and IEEE 802.3-2012 Clause 57 OAM 1176

22.2 Maintenance Entity creation 1176

22.2.1 Creating Maintenance Domains and MAs 1177

22.2.2 Creating MEPs 1177

22.2.3 Creating MIPs 1179

22.2.4 CFM configuration errors 1180

22.3 MPs, Ports, and MD Level assignment.... 1181

22.4 Stations and CFM 1181

22.5 Scalability of CFM.... 1182

22.6 CFM in Provider Bridges.... 1183

22.6.1 MPs and C-VLAN components 1183

22.6.2 Maintenance C-VLAN on a Port-based service interface 1184

22.6.3 Maintenance C-VLAN on a C-tagged service interface 1185

22.6.4 MPs and Port-mapping S-VLAN components 1185

22.7 Management Port MEPs and CFM in the enterprise environment.... 1187

22.8 Implementing CFM on Bridges that implement earlier revisions of IEEE Std 802.1Q .... 1188

MAC status propagation 1190

23.1 Model of operation.... 1191

23.1.1 MAC Status Shim (MSS) 1192

23.1.2 Relationship of CFM to the MSS 1193

23.2 MAC Status Protocol (MSP) overview.... 1193

23.3 MSP state machines 1198

23.4 State machine timers....1199

23.4.1 linkNotifyWhen 1199

23.4.2 linkNotifyWhile 1199

23.4.3 macNotifyWhile 1199

23.4.4 macRecoverWhile 1199

23.5 MSP performance parameters.... 1199

23.5.1 LinkNotify 1200

23.5.2 LinkNotifyWait 1200

23.5.3 LinkNotifyRetry 1200

23.5.4 MACNotify 1200

23.5.5 MACNotifyTime 1200

23.5.6 MACRecoverTime 1200

23.6 State machine variables.... 1200

23.6.1 BEGIN 1200

23.6.2 addConfirmed 1200

23.6.3 disableMAC 1200

23.6.4 disabledMAC 1200

23.6.5 disableMSS 1201

23.6.6 lossConfirmed 1201

23.6.7 macOperational 1201

23.6.8 mssOperational 1201

23.6.9 prop 1201

23.6.10 rxAck 1201

23.6.11 rxAdd 1201

23.6.12 rxAddConfirm 1201

23.6.13 rxLoss 1201

23.6.14 rxLossConfirm 1201

23.6.15 txAck 1201

23.6.16 txAdd 1201

23.6.17 txAddConfirm 1202

23.6.18 txLoss 1202

23.6.19 txLossConfirm 1202

23.7 State machine procedures 1202

23.8 Status Transition state machine (STM).... 1202

23.9 Status Notification state machine (SNM) 1203

23.10 Receive Process 1203

23.11 Transmit Process.... 1203

23.12 Management of MSP 1203

23.13 MSPDU transmission, addressing, and protocol identification 1204

23.13.1 Destination MAC Address 1204

23.13.2 Source MAC Address 1204

23.13.3 Priority 1205

23.13.4 EtherType use and encoding 1205

23.14 Representation and encoding of octets 1205

23.15 MSPDU structure.... 1205

23.15.1 Protocol Version 1206

23.15.2 Packet Type 1206

23.16 Validation of received MSPDUs 1206

23.17 Other MSP participants.... 1206

Bridge performance 1207

24.1 Guaranteed Port Filtering Rate 1207

24.2 Guaranteed Bridge Relaying Rate 1207

24.3 RSTP performance requirements.... 1207

Support of the MAC Service by PBBNs.... 1209

25.1 Service transparency 1211

25.2 Customer service interface.... 1211

25.3 Port-based service interface 1212

25.4 S-tagged service interface 1213

25.5 I-tagged service interface.... 1215

25.6 Service instance segregation 1217

25.7 Service instance selection and identification 1217

25.8 Service priority and drop eligibility selection.... 1218

25.9 Service access protection 1218

25.9.1 Class II redundant LANs access protection 1220

25.9.2 Class III simple redundant LANs and nodes access protection 1221

25.10 Support of the MAC Service by a PBB-TE Region 1222

25.10.1 Provisioning TESIs 1223

25.10.2 ESP forwarding behavior 1224

25.11 Transparent service interface 1225

Principles of Provider Backbone Bridged Network (PBBN) operation 1227

26.1 PBBN overview 1227

26.2 PBBN example.... 1228

26.3 B-VLAN connectivity.... 1230

26.4 Backbone addressing 1231

26.4.1 Learning individual backbone addresses at a PIP 1232

26.4.2 Translating backbone destination addresses at a CBP 1232

26.4.3 Backbone addressing considerations for CFM MPs 1233

26.5 Detection of connectivity loops through attached networks.... 1233

26.6 Scaling of PBBs 1233

26.6.1 Hierarchical PBBNs 1234

26.6.2 Peer PBBNs 1234

26.7 Network management 1234

26.8 CFM in PBBs....1235

26.8.1 CFM over Port-based and S-tagged service interfaces 1240

26.8.2 CFM over I-tagged Service Interfaces 1241

26.8.3 CFM over hierarchical E-NNI 1241

26.8.4 CFM over peer E-NNI 1241

26.9 CFM in a PBB-TE Region.... 1242

26.9.1 Addressing PBB-TE MEPs 1242

26.9.2 TESI identification 1243

26.9.3 PBB-TE MEP placement in a Bridge Port 1243

26.9.4 PBB-TE MIP placement in a Bridge Port 1243

26.9.5 TESI Maintenance Domains 1243

26.9.6 PBB-TE enhancements of the CFM protocols 1244

26.9.7 Addressing Infrastructure Segment MEPs 1246

26.9.8 Infrastructure Segment identification 1246

26.9.9 Infrastructure Segment MEP placement in a Bridge Port 1247

26.9.10 Infrastructure Segment Maintenance Domains 1247

26.9.11 IPS extensions to Continuity Check operation 1247

26.10 Protection switching for point-to-point TESIs.... 1249

26.10.1 Introduction 1249

26.10.2 1:1 point-to-point TESI protection switching 1250

26.10.3 Protection Switching state machines 1253

26.11 IPS in PBB-TE Region 1258

26.11.1 Infrastructure Segment monitoring 1259

26.11.2 1:1 IPS 1260

26.11.3 IPS Control entity 1263

26.11.4 1:1 IPS state machines 1264

26.11.5 M:1 IPS 1264

26.12 Mismatch defect.... 1270

26.13 Signaling VLAN registrations among I-components 1271

Shortest Path Bridging (SPB) 1272

27.1 Protocol design requirements.... 1274

27.2 Protocol support.... 1275

27.3 Protocol design goals 1276

27.4 ISIS-SPB VLAN configuration 1276

27.4.1 SPT Region and ISIS-SPB adjacency determination 1278

27.5 ISIS-SPB information 1279

27.6 Calculating CIST connectivity.... 1280

27.7 Connectivity between regions in the same domain.... 1281

27.8 Calculating SPT connectivity 1281

27.8.1 ISIS-SPB overload 1282

27.9 Loop prevention....1282

27.10 SPVID and SPSourceID allocation.... 1283

27.11 Allocation of VIDs to FIDs.... 1284

27.12 SPBV SPVID translation 1285

27.13 VLAN topology management.... 1285

27.14 Individual addresses and SPBM 1286

27.14.1 Loop mitigation 1287

27.14.2 Loop prevention 1287

27.15 SPBM group addressing 1288

27.16 Backbone service instance topology management 1289

27.17 Equal cost shortest paths, ECTs, and load spreading.... 1290

27.18 Connectivity Fault Management for SPBM 1290

27.18.1 SPBM MA types 1291

27.18.2 SPBM MEP placement in a Bridge Port 1291

27.18.3 SPBM MIP placement in a Bridge Port 1291

27.18.4 SPBM modifications of the CFM protocols 1292

27.19 Using SPBV and SPBM modes 1293

27.19.1 Shortest Path Bridging—VID 1293

27.19.2 Shortest Path Bridging—MAC 1295

27.20 Security considerations 1297

ISIS-SPB Link State Protocol.... 1298

28.1 ISIS-SPB control plane MAC 1298

28.2 Formation and maintenance of ISIS-SPB adjacencies.... 1299

28.3 Loop prevention.... 1300

28.4 The Agreement Digest 1300

28.4.1 Agreement Digest Format Identifier 1301

28.4.2 Agreement Digest Format Capabilities 1301

28.4.3 Agreement Digest Convention Identifier 1301

28.4.4 Agreement Digest Convention Capabilities 1302

28.4.5 Agreement Digest Edge Count 1302

28.4.6 The Computed Topology Digest 1302

28.5 Symmetric shortest path tie breaking.... 1303

28.6 Symmetric ECT framework.... 1304

28.7 Symmetric ECT 1305

28.8 ECT Algorithm details.... 1306

28.9 ECT Migration....1307

28.9.1 Use of a new ECT Algorithm in SPBV 1308

28.9.2 Use of a new ECT Algorithm in SPBM 1308

28.10 MAC address registration 1309

28.11 Circuit IDs and Port Identifiers.... 1309

28.12 ISIS-SPB TLVs.... 1310

28.12.1 MT-Capability TLV 1310

28.12.2 SPB MCID sub-TLV 1311

28.12.3 SPB Digest sub-TLV 1311

28.12.4 SPB Base VLAN-Identifiers sub-TLV 1312

28.12.5 SPB Instance sub-TLV 1313

28.12.6 SPB Instance Opaque ECT Algorithm sub-TLV 1315

28.12.7 SPB Link Metric sub-TLV 1316

28.12.8 SPB Adjacency Opaque ECT Algorithm sub-TLV 1317

28.12.9 SPBV MAC address sub-TLV 1317

28.12.10 SPBM Service Identifier and Unicast Address (ISID-ADDR) sub-TLV ..... 1319

DDCFM operations and protocols 1322

29.1 Principles of DDCFM operation.... 1322

29.1.1 Data-driven and data-dependent faults (DDFs) 1322

29.1.2 Basic principle to diagnose and isolate DDFs 1322

29.2 DDCFM Entity operation 1325

29.2.1 DDCFM implementation 1325

29.2.2 FPT RR 1326

29.2.3 RR-related parameters 1327

29.2.4 Reflection Target and RFM Receiver 1328

29.2.5 RPT-related parameters 1328

29.2.6 Decapsulator Responder (DR) 1329

29.2.7 SFM Originator 1330

29.3 DDCFM protocols 1330

29.3.1 RR variables 1330

29.3.2 RR Filter procedures 1332

29.3.3 RR Encapsulation procedures 1333

29.3.4 RR Transmit procedure 1334

29.3.5 RR-related state machines 1335

29.3.6 RFM Receiver variables 1337

29.3.7 RFM Receiver procedure 1337

29.3.8 DR variables 1338

29.3.9 DR procedures 1339

29.3.10 Decapsulator Responder state machine 1340

29.4 Encoding of DDCFM PDUs 1340

29.4.1 RFM and SFM Header 1340

29.4.2 RFM format 1341

29.4.3 SFM format 1342

Principles of congestion notification 1344

30.1 Congestion notification design requirements 1344

30.2 Quantized Congestion Notification protocol (QCN) 1346

30.2.1 The CP algorithm 1347

30.2.2 Basic RP algorithm 1348

30.2.3 RP algorithm with timer 1349

30.3 Congestion Controlled Flow (CCF) 1350

30.4 Congestion Notification Priority Value (CNPV) 1351

30.5 Congestion Notification tag (CN-TAG) 1351

30.6 Congestion Notification Domain (CND) 1351

30.7 Multicast data 1352

30.8 Congestion notification and additional tags 1352

31 Congestion notification entity operation 1354

31.1 Congestion aware Bridge Forwarding Process 1354

31.1.1 Congestion Point (CP) 1355

31.1.2 CP ingress multiplexer 1355

31.2 Congestion aware end station functions 1355

31.2.1 Output flow segregation 1356

31.2.2 Per-CNPV station function 1357

31.2.3 Flow Select Database 1359

31.2.4 Flow multiplexer 1359

31.2.5 CNM demultiplexer 1359

31.2.6 Input flow segregation 1359

31.2.7 End station input queue 1360

31.2.8 Reception selection 1360

32 Congestion notification protocol 1361

32.1 CND operations 1361

32.1.1 CND defense 1361

32.1.2 Automatic CND recognition 1363

32.1.3 Variables controlling CND defense 1363

32.2 CN component variables 1364

32.2.1 cngMasterEnable 1365

32.2.2 cngCnmTransmitPriority 1365

32.2.3 cngDiscardedFrames 1365

32.2.4 cngErroredPortList 1365

32.3 Congestion notification per-CNPV variables 1365

32.3.1 cncpDefModeChoice 1365

32.3.2 cncpAlternatePriority 1366

32.3.3 cncpAutoAltPri 1366

32.3.4 cncpAdminDefenseMode 1366

32.3.5 cncpCreation 1366

32.3.6 cncpLldpInstanceChoice 1366

32.3.7 cncpLldpInstanceSelector 1366

32.4 CND defense per-Port per-CNPV variables 1367

32.4.1 cnpdDefModeChoice 1367

32.4.2 cnpdAdminDefenseMode 1367

32.4.3 cnpdAutoDefenseMode 1368

32.4.4 cnpdLldpInstanceChoice 1368

32.4.5 cnpdLldpInstanceSelector 1368

32.4.6 cnpdAlternatePriority 1368

32.4.7 cnpdXmitCnpvCapable 1368

32.4.8 cnpdXmitReady 1368

32.4.9 cncpDoesEdge 1369

32.4.10 cnpdAcceptsCnTag 1369

32.4.11 cnpdRcvdCnpv 1369

32.4.12 cnpdRcvdReady 1369

32.4.13 cnpdIsAdminDefMode 1369

32.4.14 cnpdDefenseMode 1370

32.5 CND defense procedures 1370

32.5.1 DisableCnpvRemapping() 1370

32.5.2 TurnOnCnDefenses() 1370

32.5.3 TurnOffCnDefenses() 1370

32.6 CND defense state machine 1370

32.7 Congestion notification protocol 1371

32.8 CP variables 1372

32.8.1 cpMacAddress 1373

32.8.2 cpId 1373

32.8.3 cpQSp 1373

32.8.4 cpQLen 1373

32.8.5 cpQLenOld 1373

32.8.6 cpW 1373

32.8.7 cpQOffset 1373

32.8.8 cpQDelta 1373

32.8.9 cpFb 1373

32.8.10 cpEnqued 1374

32.8.11 cpSampleBase 1374

32.8.12 cpDiscardedFrames 1374

32.8.13 cpTransmittedFrames 1374

32.8.14 cpTransmittedCnms 1374

32.8.15 cpMinHeaderOctets 1374

32.9 CP procedures 1374

32.9.1 Random 1374

32.9.2 NewCpSampleBase() 1374

32.9.3 EM_UNITDATA.request (parameters) 1375

32.9.4 GenerateCnmPdu() 1375

32.10 RP per-Port per-CNPV variables 1376

32.10.1 rpppMaxRps 1376

32.10.2 rpppCreatedRps 1376

32.10.3 rpppRpCentiseconds 1377

32.11 RP group variables 1377

32.11.1 rpgEnable 1377

32.11.2 rpgTimeReset 1377

32.11.3 rpgByteReset 1377

32.11.4 rpgThreshold 1378

32.11.5 rpgMaxRate 1378

32.11.6 rpgAiRate 1378

32.11.7 rpgHaiRate 1378

32.11.8 rpgGd 1378

32.11.9 rpgMinDecFac 1378

32.11.10 rpgMinRate 1378

32.12 RP timer 1378

32.12.1 RpWhile 1379

32.13 RP variables 1379

32.13.1 rpEnabled 1379

32.13.2 rpByteCount 1379

32.13.3 rpByteStage 1379

32.13.4 rpTimeStage 1379

32.13.5 rpTargetRate 1379

32.13.6 rpCurrentRate 1380

32.13.7 rpFreeze 1380

32.13.8 rpLimiterRate 1380

32.13.9 rpFb 1380

32.14 RP procedures 1380

32.14.1 ResetCnm 1380

32.14.2 TestRpTerminate 1381

32.14.3 TransmitDataFrame 1381

32.14.4 ReceiveCnm 1381

32.14.5 ProcessCnm 1382

32.14.6 AdjustRates 1382

32.15 RP rate control state machine 1382

32.16 Congestion notification and encapsulation interworking function 1384

Encoding of congestion notification PDUs 1386

33.1 Structure, representation, and encoding 1386

33.2 CN-TAG format 1386

33.2.1 Flow Identifier 1387

33.3 Congestion Notification Message (CNM) 1387

33.4 Congestion Notification Message PDU format 1388

33.4.1 Version 1388

33.4.2 ReservedV 1388

33.4.3 Quantized Feedback 1389

33.4.4 Congestion Point Identifier 1389

33.4.5 cnmQOffset 1389

33.4.6 cnmQDelta 1389

33.4.7 Encapsulated priority 1389

33.4.8 Encapsulated destination MAC address 1389

33.4.9 Encapsulated MSDU length 1389

33.4.10 Encapsulated MSDU 1389

33.4.11 CNM Validation 1390

Forwarding and Queuing Enhancements for time-sensitive streams (FQTSS) 1391

34.1 Overview.... 1391

34.2 Detection of SRP domains 1391

34.3 The bandwidth availability parameters.... 1392

34.3.1 Relationships among bandwidth availability parameters 1392

34.3.2 Bandwidth availability parameter management 1393

34.4 Deriving actual bandwidth requirements from the size of the MSDU 1393

34.5 Mapping priorities to traffic classes for time-sensitive streams 1394

34.6 End station behavior 1396

34.6.1 Talker behavior 1396

34.6.2 Listener behavior 1397

Stream Reservation Protocol (SRP).... 1398

35.1 Multiple Stream Registration Protocol (MSRP).... 1399

35.1.1 MSRP and Shared Media 1400

35.1.2 Behavior of end stations 1400

35.1.3 Behavior of Bridges 1402

35.1.4 SRP domains and status parameters 1402

35.2 Definition of the MSRP application 1402

35.2.1 Definition of internal state variables 1403

35.2.2 Definition of MRP elements 1405

35.2.3 Provision and support of Stream registration service 1415

35.2.4 MSRP Attribute Propagation 1419

35.2.5 Operational reporting and statistics 1424

35.2.6 Encoding 1424

35.2.7 Attribute value support requirements 1425

Priority-based Flow Control (PFC) 1426

36.1 PFC operation 1426

36.1.1 Overview 1426

36.1.2 PFC primitives 1427

36.1.3 Detailed specification of PFC operation 1428

36.2 PFC aware system queue functions 1429

36.2.1 PFC Initiator 1430

36.2.2 PFC Receiver 1430

Enhanced Transmission Selection (ETS).... 1432

37.1 Overview.... 1432

37.1.1 Relationship to other transmission selection algorithms 1432

37.2 ETS configuration parameters 1432

37.3 ETS algorithm.... 1432

37.4 Legacy configuration 1433

Data Center Bridging eXchange protocol (DCBX).... 1434

38.1 Overview.... 1434

38.2 Goals 1434

38.3 Types of DCBX attributes 1434

38.3.1 Informational attributes 1434

38.4 DCBX and LLDP 1434

38.4.1 Asymmetric attribute passing 1435

38.4.2 Symmetric attribute passing 1436

Multiple I-SID Registration Protocol (MIRP) 1438

39.1 MIRP overview 1438

39.1.1 Behavior of I-components 1440

39.1.2 Behavior of B-components 1440

39.2 Definition of the MIRP application 1440

39.2.1 Definition of MRP elements 1440

39.2.2 Alternate MIRP model for B-components 1443

39.2.3 Use of “new” declaration capability 1445

39.2.4 Attribute value support requirements 1445

39.2.5 MRP Message filtering 1445

Edge Virtual Bridging (EVB) 1446

40.1 EVB architecture without S-channels 1447

40.2 EVB architecture with S-channels 1448

40.3 Asymmetric EVB architecture without S-channels 1450

40.4 EVB status parameters 1450

40.4.1 EVBMode = Not supported 1452

40.4.2 EVBMode = EVB Bridge 1452

40.4.3 EVBMode = EVB station 1452

41 VSI Discovery and Configuration Protocol (VDP) 1453

41.1 VSI manager ID TLV definition 1453

41.1.1 TLV type 1453

41.1.2 TLV information string length 1453

41.1.3 VSI Manager ID 1454

41.2 VDP association TLV definitions 1454

41.2.1 TLV type 1454

41.2.2 TLV information string length 1455

41.2.3 Status 1455

41.2.4 VSI Type ID (VTID) 1456

41.2.5 VSI Type Version 1456

41.2.6 VSIID format 1456

41.2.7 VSIID 1456

41.2.8 Filter Info format 1457

41.2.9 Filter Info field 1457

41.2.10 VDP TLV type and Status semantics 1459

41.3 Organizationally defined TLV definitions 1460

41.3.1 TLV type 1461

41.3.2 TLV information string length 1461

41.3.3 Organizationally unique identifier (OUI) or Company ID (CID) 1461

41.3.4 Organizationally defined information 1461

41.4 Validation rules for VDP TLVs 1461

41.5 VDP state machines 1461

41.5.1 State machine conventions 1461

41.5.2 Bridge VDP state machine 1462

41.5.3 Station VDP state machine 1463

41.5.4 VDP state machine timers 1464

41.5.5 VDP state machine variables and parameters 1464

41.5.6 Command-Response TLV field references in state machines 1467

41.5.7 VDP state machine procedures 1467

42 S-Channel Discovery and Configuration Protocol (CDCP) 1469

42.1 CDCP discovery and configuration 1469

42.2 CDCP state machine overview 1469

42.3 CDCP configuration state machine 1470

42.4 CDCP configuration variables 1471

42.4.1 AdminChnCap 1471

42.4.2 AdminRole 1472

42.4.3 AdminSVIDWants 1472

42.4.4 LastLocalSVIDPool 1472

42.4.5 LastRemoteSVIDList 1472

42.4.6 LastSVIDWants 1472

42.4.7 LocalSVIDPool 1472

42.4.8 OperChnCap 1472

42.4.9 OperRole 1472

42.4.10 OperSVIDList 1473

42.4.11 RemoteChnCap 1473

42.4.12 RemoteRole 1473

42.4.13 RemoteSVIDList 1473

42.4.14 schState 1473

42.5 CDCP configuration procedures 1473

42.5.1 SetSVIDRequest (OperRole, AdminSVIDWants, OperSVIDList) 1473

42.5.2 RxSVIDConfig (OperSVIDList, LastRemoteSVIDList) 1474

42.5.3 TxSVIDConfig (OperChnCap, RemoteChnCap, LastLocalSVIDPool, RemoteSVIDList, OperSVIDList) 1474

Edge Control Protocol (ECP) 1475

43.1 ECP operation 1475

43.2 Edge Control Sublayer Service (ECSS) 1476

43.3 ECP state machines 1476

43.3.1 State machine conventions 1476

43.3.2 Overview 1476

43.3.3 Edge Control Protocol Data Unit (ECPDU) 1477

43.3.4 ECP transmit state machine 1478

43.3.5 ECP receive state machine 1479

43.3.6 ECP state machine timers 1479

43.3.7 ECP state machine variables and parameters 1480

43.3.8 ECP state machine procedures 1481

Equal Cost Multiple Paths (ECMP).... 1482

44.1 SPBM ECMP 1482

44.1.1 ECMP Operation 1482

44.1.2 ECMP ECT Algorithm 1483

44.1.3 Loop prevention for ECMP 1485

44.2 Support for Flow Filtering 1485

44.2.1 Flow filtering tag (F-TAG) 1486

44.2.2 F-TAG processing 1487

44.2.3 Forwarding process extension for flow filtering 1488

44.2.4 TTL Loop mitigation 1489

44.2.5 CFM for ECMP with flow filtering 1489

44.2.6 Operation with selective support for flow filtering 1491

Annex A (normative) PICS proforma—Bridge implementations 1492

Annex B (normative) PICS proforma—End station implementations 1553

Annex C (normative) Designated MSRP Node (DMN) Implementations 1567

Annex D (normative) IEEE 802.1 Organizationally Specific TLVs 1584

Annex E (normative) Notational conventions used in state diagrams.... 1692

Annex F (informative) Shared and Independent VLAN Learning (SVL and IVL) 1694

Annex G (informative) MAC method-dependent aspects of VLAN support.... 1703

Annex H (informative) Interoperability considerations.... 1705

Annex I (informative) Priority and drop precedence.... 1711

Annex J (informative) CFM protocol design and use.... 1719

Annex K (informative) TPMR use cases....1727

Annex L (informative) Operation of the credit-based shaper algorithm 1732

Annex M (normative) Support for PFC in link layers without MAC Control.... 1749

Annex N (informative) Buffer requirements for PFC 1750

Annex O (informative) Preserving the integrity of FCS fields in MAC Bridges 1755

Annex P (informative) Frame duplication and misordering.... 1762

Annex Q (informative) Bibliography.... 1765

Figures

Figure 6-1—Internal organization of the MAC sublayer 61

Figure 6-2—Provider Instance Ports (PIPs) 79

Figure 6-3—B-Component CBP 82

Figure 6-4—Example of operation of Port-and-Protocol-based classification 86

Figure 6-5—Service access priority selection 88

Figure 6-6—Two back-to-back EISS Multiplex Entities 94

Figure 6-7—Two back-to-back Backbone Service Instance Multiplex Entities 95

Figure 6-8—Backbone Service Instance Multiplex Entities with example CFM shims 95

Figure 6-9—Two back-to-back Up and Down TESI Multiplex Entities 98

Figure 6-10—Supporting the ISS with signaled priority 99

Figure 6-11—Two back-to-back Up and Down Infrastructure Segment Multiplex Entities .... 100

Figure 7-1—VLAN Bridging overview 103

Figure 8-1—A Bridged Network 108

Figure 8-2—VLAN Bridge architecture 110

Figure 8-3—MAC Bridge architecture 111

Figure 8-4—Relaying MAC frames 113

Figure 8-5—Observation of network traffic 113

Figure 8-6—Operation of Spanning Tree Protocol Entity 113

Figure 8-7—Operation of MRP 114

Figure 8-8—Management Port transmission and reception 114

Figure 8-8—Infrastructure Segment MEP placement in a PNP 115

Figure 8-9—Bridge Port Transmit and Receive 117

Figure 8-10—TPMR Port Transmit and Receive 118

Figure 8-11—Forwarding Process functions ...... 119

Figure 8-12—Logical points of attachment of the Higher Layer and Relay Entities ..... 152

Figure 8-13—Effect of control information on the forwarding path 153

Figure 8-14—Per-Port points of attachment 153

Figure 8-15—Single point of attachment—relay permitted 154

Figure 8-16—Single point of attachment—relay not permitted 154

Figure 8-17—Effect of Port State 155

Figure 8-18—Controlled and Uncontrolled Port connectivity 155

Figure 8-19—Ingress/egress control information in the forwarding path 156

Figure 9-1—VLAN TCI format .... 160

Figure 9-2—I-TAG TCI format .... 161

Figure 10-1—Example—Attribute value propagation from one station 164

Figure 10-2—Example—Attribute value propagation from two stations 165

Figure 10-3—Example—Registrations as pointers to the sources of declarations .... 165

Figure 10-4—MRP architecture 167

Figure 10-5—Format of the major components of an MRPDU 190

Figure 10-6—Operation of MMRP for a single VLAN Context 196

Figure 10-7—Example Directed Graph 197

Figure 10-8—Example of MMRP propagation in a VLAN Context 199

Figure 11-1—Operation of MVRP 208

Figure 12-1—Relationships among CFM managed objects 270

Figure 12-2—Relationship among BEB managed objects 287

Figure 12-3—SPB managed objects (MOs) 339

Figure 12-4—Relationships among EVB Bridge managed objects 355

Figure 12-5—Relationship among EVB station managed objects 356

Figure 13-1—Diagrammatic conventions for spanning tree topologies .... 373

Figure 13-2—Physical topology and active topology .... 374

Figure 13-3—Port Roles and Port States 374

Figure 13-4—A Backup Port 375

Figure 13-5—“Ring Backbone” example 375

Figure 13-6—An MST Bridge network 377

Figure 13-7—CIST Priority Vectors, Port Roles, and MST Regions 378

Figure 13-8—MSTI Active Topology in Region 2 379

Figure 13-9—CIST and MSTI active topologies in Region 1 of the example network .... 392

Figure 13-10—Agreements and Proposals ...... 396

Figure 13-11—CIST and MSTI Active Topologies in Region 2 of Figure 13-6 397

Figure 13-12—Enhanced Agreements 398

Figure 13-13—Spanning tree protocol state machines—overview and relationships 409

Figure 13-14—MSTP overview notation 410

Figure 13-15—Port Timers state machine 440

Figure 13-16—Port Receive state machine 440

Figure 13-17—Port Protocol Migration state machine 441

Figure 13-18—Bridge Detection state machine 441

Figure 13-19—Port Transmit state machine 442

Figure 13-20—Port Information state machine 443

Figure 13-21—Port Role Selection state machine 444

Figure 13-22—Disabled Port role transitions 445

Figure 13-23—Port Role Transitions state machine—MasterPort 446

Figure 13-24—Port Role Transitions state machine—RootPort 447

Figure 13-25—Port Role Transitions state machine—DesignatedPort 448

Figure 13-26—Port Role Transitions state machine—AlternatePort and BackupPort 449

Figure 13-27—Port State Transition state machine 449

Figure 13-28—Topology Change state machine 451

Figure 13-29—L2 Gateway Port Receive state machine 452

Figure 14-1—RST, MST, SPT, and STP Configuration BPDU format 456

Figure 14-2—STP TCN BPDU format 456

Figure 14-3—MSTI Configuration Message parameters and format 462

Figure 15-1—Internal organization of the MAC sublayer in a PBN 465

Figure 15-2—Port-based service interface to a PBN 466

Figure 15-3—Port-based service interface to a PBN 467

Figure 15-4—C-tagged service interface to a PBN 467

Figure 15-5—C-tagged service interface to a PBN 467

Figure 15-6—Customer Edge Ports (CEPs) 468

Figure 15-7—S-tagged service interface to a PBN 468

Figure 15-8—S-tagged interface to a PBN 469

Figure 15-9—RCSIs to a PBN 469

Figure 15-10—Remote Customer Access Ports (RCAPs) 470

Figure 15-11—C-tagged RCSI to a PBN 471

Figure 15-12—Port-based RCSI to a PBN 471

Figure 15-13—Provider Network Port (PNP) interface 472

Figure 16-1—PBN with interface examples 476

Figure 16-2—Examples of remote customer service access via a second PBN 478

Figure 16-3—Access service separation and “Hairpin Switching” 479

Figure 17-1—C-VLAN component internal LAN managed system 538

Figure 17-2—I/B-component internal LAN managed system 542

Figure 18-1—One Maintenance Domain: operator's view 1066

Figure 18-2—One service instance: operator's view .... 1067

Figure 18-3—One service instance: customer's view 1067

Figure 18-4—MEP and MIP Symbols 1068

Figure 18-5—MAs: one service instance in a provider network 1069

Figure 18-6—MAs: Expansion of Figure 18-5 1070

Figure 18-7—MEPs, MIPs, and MD Levels 1071

Figure 19-1—CFM Protocol shims 1072

Figure 19-2—MA Endpoint (MEP) 1075

Figure 19-3—MIP Half Function (MHF) 1081

Figure 19-4—LOM shim 1083

Figure 19-5—LOM architecture 1083

Figure 20-1—MEP state machines—overview and relationships 1096

Figure 20-2—MEP Continuity Check Initiator state machine 1103

Figure 20-3—MHF Continuity Check Receiver state machine 1104

Figure 20-4—MEP Continuity Check Receiver state machine 1108

Figure 20-5—Remote MEP state machine 1110

Figure 20-6—Remote MEP Error state machine 1111

Figure 20-7—MEP Cross Connect state machine 1112

Figure 20-8—MEP Traffic Field Mismatch state machine 1114

Figure 20-9—MEP Local Mismatch state machine 1114

Figure 20-10—MP Loopback Responder state machine 1116

Figure 20-11—MEP Loopback Initiator transmit state machine 1119

Figure 20-12—MEP Loopback Initiator receive state machine 1120

Figure 20-13—MEP Fault Notification Generator state machine 1122

Figure 20-14—MEP Mismatch Fault Notification Generator state machine 1124

Figure 20-15—MEP Linktrace Initiator receive state machine 1128

Figure 20-16—Linktrace Responder, MEPs, MHFs, and LOMs 1130

Figure 20-17—LTM Receiver state machine 1136

Figure 20-18—LTR Transmitter state machine 1137

Figure 22-1—MEPs and MIPs distinguished by VID (incomplete picture) 1167

Figure 22-2—Alternate view of Forwarding process 1168

Figure 22-3—Combining per-VLAN MPs into two shims 1169

Figure 22-4—More complete picture of MP placement in a Bridge Port 1170

Figure 22-5—Service instance spanning two Bridges protected by Up MPs 1172

Figure 22-6—Service instance spanning two Bridges protected by Down MPs 1172

Figure 22-7—MP placement in a non-VLAN aware Bridge Port 1174

Figure 22-8—MP placement relative to other standards 1175

Figure 22-9—Creating MEPs and MIPs 1178

Figure 22-10—CFM in a Provider Edge Bridge C-tagged service interface 1184

Figure 22-11—CFM in a Provider Edge Bridge C-tagged RCSI 1186

Figure 22-12—Up MEPs in a Management Port 1187

Figure 22-13—CFM in the enterprise environment 1188

Figure 22-14—CFM on a Bridge that implements IEEE Std 802.1Q-2005 1189

Figure 23-1—TPMR connecting two Bridge Ports 1190

Figure 23-2—TPMR chain connecting Bridge Ports 1190

Figure 23-3—MSSs and the MSPE 1192

Figure 23-4—Adding connectivity 1194

Figure 23-5—Losing connectivity 1195

Figure 23-6—TPMR recovery 1196

Figure 23-7—Notification from one end of the link to the other 1197

Figure 23-8—Immediate MAC status notification at the end of a link 1197

Figure 23-9—MSPE state machine overview 1198

Figure 23-10—Status Transition state machine (STM) 1202

Figure 23-11—Status Notification state machine (SNM) 1203

Figure 23-12—MSPDU structure 1205

Figure 25-1—Internal organization of the MAC sublayer in a PBBN 1209

Figure 25-2—PBB terminology 1210

Figure 25-3—Customer service interface types 1211

Figure 25-4—Port-based service interface 1212

Figure 25-5—Port-based interface equipment 1213

Figure 25-6—Encapsulated service frames at ISS 1214

Figure 25-7—S-tagged service interface 1214

Figure 25-8—S-tagged service interface equipment 1215

Figure 25-9—I-tagged service interface 1216

Figure 25-10—I-tagged service interface equipment 1216

Figure 25-11—S-tagged and Port-based service interface access classifications 1219

Figure 25-12—I-tagged service interface access protection classifications 1220

Figure 25-13—Internal organization of the MAC sublayer in a PBB-TE Region 1222

Figure 25-14—PBB-TE Region 1224

Figure 25-15—Transparent service interface 1226

Figure 25-16—Transparent service interface equipment 1226

Figure 26-1—PBBN example 1228

Figure 26-2—CFM shim model 1235

Figure 26-3—CFM example applied to a Port-based and S-tagged service interface .... 1236

Figure 26-4—CFM example applied to an I-tagged Service Interface 1237

Figure 26-5—CFM example applied to a hierarchical E-NNI, CBP-PIP Demarc 1238

Figure 26-6—CFM example applied to a peer E-NNI, CBP-PIP 1239

Figure 26-7—Independent ESPs using the same ESP-DAs and ESP-VIDs 1243

Figure 26-8—PBB-TE MEP placement in a CBP 1244

Figure 26-9—Independent Infrastructure Segments distinguished by SMP-SA 1247

Figure 26-10—Infrastructure Segment MEP placement in a PNP 1248

Figure 26-11—Protection switching architecture 1249

Figure 26-12—PBB-TE point-to-point protection switching 1251

Figure 26-13—Mapping data traffic to the protection entity 1252

Figure 26-14—Relationships of the Protection switching state machines—overview 1253

Figure 26-15—Hold-off state machine 1257

Figure 26-16—Clear Manual Switch state machine 1257

Figure 26-17—Service Mapping state machine 1258

Figure 26-18—Segment terminology and properties 1259

Figure 26-19—Infrastructure Segment monitoring 1260

Figure 26-20—Working Segment and Protection Segment 1260

Figure 26-21—Nested IPGs 1261

Figure 26-22—IPS Control entity 1263

Figure 26-23—M:1 IPS 1265

Figure 26-24—M:1 IPS state machines 1266

Figure 26-25—M:1 Hold-off state machine 1269

Figure 26-26—Protection Segment Selection state machine 1270

Figure 27-1—Configuring VLAN support in an SPT Region (example) 1277

Figure 27-2—SPBM group MAC address—general format 1288

Figure 27-3—SPBM group MAC addresses—source rooted SPT 1289

Figure 27-4—SPBM group MAC addresses—shared tree 1289

Figure 27-5—SPBM MEP placement in a CBP 1292

Figure 27-6—SPBV campus network example 1294

Figure 27-7—SPT Bridge Network using SPBM example 1296

Figure 28-1—Agreement Digest field format .... 1301

Figure 28-2—MT-Capability TLV 1310

Figure 28-3—SPB MCID sub-TLV 1311

Figure 28-4—SPB Digest sub-TLV 1311

Figure 28-5—SPB Base VLAN-Identifiers sub-TLV 1312

Figure 28-6—SPB Instance sub-TLV 1313

Figure 28-7—SPB Instance Opaque ECT-ALGORITHM sub-TLV 1315

Figure 28-8—ECMP ECT-ALGORITHM sub-TLV 1316

Figure 28-9—SPB Link Metric sub-TLV 1316

Figure 28-10—SPB Adjacency Opaque ECT-ALGORITHM sub-TLV 1317

Figure 28-11—SPBV MAC Address sub-TLV 1318

Figure 28-12—SPBM Service Identifier and Unicast Address sub-TLV 1319

Figure 29-1—Forward path test (FPT) 1323

Figure 29-2—Return path test (RPT) 1324

Figure 29-3—Combination of FPT and RPT 1325

Figure 29-4—Detailed functions of RR 1326

Figure 29-5—RFM Receiver on an non-MP 1329

Figure 29-6—Return Path DR 1330

Figure 29-7—RR Filter state machine 1335

Figure 29-8—RR Encapsulation state machine 1336

Figure 29-9—RR Transmit state machine 1336

Figure 29-10—RFM Receiver state machine 1338

Figure 29-11—Decapsulator Responder state machine 1340

Figure 30-1—Congestion detection in QCN CP 1347

Figure 30-2—Sampling (reflection) probability in QCN CP as a function of |Fb| .... 1347

Figure 30-3—QCN RP operation 1348

Figure 30-4—Byte Counter and Timer interaction with Rate Limiter 1350

Figure 30-5—CP–RP peering in VLAN Bridged Network 1352

Figure 30-6—CP-RP peering in PBBN 1353

Figure 31-1—CPs and congestion aware queues in a Bridge 1354

Figure 31-2—Congestion aware queue functions in an end station 1356

Figure 31-3—Per-CNPV station function 1358

Figure 32-1—CND defense state machine 1371

Figure 32-2—RP rate control state machine 1383

Figure 32-3—CP–RP peering in any hierarchical Bridged Network 1384

Figure 34-1—Queuing model for a Talker station 1396

Figure 35-1—Operation of MSRP 1399

Figure 35-2—Format of the components of the reservation FirstValue fields .... 1409

Figure 35-3—Format of the components of the Domain FirstValue .... 1414

Figure 36-1—PFC peering 1426

Figure 36-2—PFC Receiver state diagram for priority n 1428

Figure 36-3—PFC aware system queue functions 1430

Figure 36-4—PFC aware system queue functions with Link Aggregation 1431

Figure 38-1—DCBX Asymmetric State Machine 1436

Figure 38-2—Symmetric State Machine 1437

Figure 39-1—Operation of MIRP in an I-component 1439

Figure 39-2—Operation of MIRP in a B-component 1439

Figure 39-3—Alternate model for MIRP in a B-component 1444

Figure 40-1—EVB architecture overview 1446

Figure 40-2—EVB architecture without S-channels 1448

Figure 40-3—EVB architecture with S-channel 1448

Figure 40-4—EVB components and internal LANs with S-channels 1449

Figure 40-5—EVB architecture without S-channels, with EVB Bridge S-VLAN component ..... 1451

Figure 40-6—EVB architecture without S-channels, with EVB station S-VLAN component ..... 1451

Figure 41-1—VSI manager ID TLV 1453

Figure 41-2—VDP association TLV 1454

Figure 41-3—VID Filter Info format 1458

Figure 41-4—MAC/VID filter format 1458

Figure 41-5—GroupID/VID filter format 1459

Figure 41-6—GroupID/MAC/VID filter format 1459

Figure 41-7—Organizationally defined TLV 1461

Figure 41-8—Bridge VDP state machine 1462

Figure 41-9—Station VDP state machine 1463

Figure 42-1—CDCP state machine—Station role 1470

Figure 42-2—CDCP state machine—Bridge role 1471

Figure 43-1—Example ECP exchange 1475

Figure 43-2—ECPDU structure 1477

Figure 43-3—ECP transmit state machine 1478

Figure 43-4—ECP receive state machine 1479

Figure 44-1—Flow FilteringTCI format 1486

Figure 44-2—SPBM VID MEP and ECMP path MEP placement in a CBP 1490

Figure C-1—CSN backbone 1567

Figure C-2—Bridge's CSN model for bandwidth reservation 1568

Figure C-3—Talker MSRPDU flow 1569

Figure C-4—Listener MSRPDU flow 1569

Figure C-5—IEEE DMN Device Attribute IE 1571

Figure C-6—DMN Confirmation Transaction 1573

Figure C-7—Bandwidth reservation—bridge model for IEEE 802.11 BSS (STA downstream Port) ..... 1576

Figure C-8—Bandwidth reservation—bridge model for IEEE 802.11 BSS (STA upstream Port) ..... 1576

Figure C-9—Bandwidth reservation—bridge model for IEEE 802.11 BSS (direct link setup) ..... 1577

Figure C-10—MSRP/IEEE 802.11 query flows 1577

Figure C-11—MSRP/802.11 Talker STA to Listener STA reservation flows 1578

Figure C-12—MSRP/802.11 “Bridged” Listener to Talker STA reservation flows 1579

Figure C-13—MSRP/802.11 Listener STA to “Bridged” Talker reservation flows 1579

Figure D-1—Port VLAN ID TLV format 1585

Figure D-2—Port And Protocol VLAN ID TLV format 1585

Figure D-3—VLAN Name TLV format 1586

Figure D-4—Protocol Identity TLV format 1587

Figure D-5—VID Usage Digest TLV format 1588

Figure D-6—Management VID TLV format 1588

Figure D-7—Link Aggregation TLV format 1589

Figure D-8—Congestion Notification TLV format 1590

Figure D-9—ETS Configuration TLV format 1591

Figure D-10—ETS Recommendation TLV format 1593

Figure D-11—Priority-based Flow Control Configuration TLV format 1594

Figure D-12—Application Priority TLV format 1595

Figure D-13—EVB TLV format 1597

Figure D-14—CDCP TLV structure 1600

Figure F-1—Connecting independent VLANs—1 1695

Figure F-2—Connecting independent VLANs—2 1696

Figure F-3—Duplicate MAC addresses 1696

Figure F-4—Asymmetric VID use: “multi-netted server” 1697

Figure F-5—Asymmetric VLAN use: “Rooted-Multipoint” 1699

Figure F-6—Rooted-Multipoint with tagged interfaces 1700

Figure F-7—SPBV VLAN Shared Learning and VID Translation 1701

Figure G-1—Example of IEEE 802.3 MAC frame format 1703

Figure H-1—Static filtering inconsistency 1707

Figure H-2—Interoperability with MAC Bridges: example 1 .... 1708

Figure H-3—Interoperability with MAC Bridges: example 2 1709

Figure H-4—Interoperability between Port-based and Port-and-Protocol-based classification ..... 1710

Figure J-1—Up MPs in a CFM Port 1724

Figure K-1—TPMR as UNI demarcation device 1727

Figure K-2—TPMRs with aggregated links 1728

Figure K-3—Multiple TPMRs 1728

Figure K-4—Recovery at the end of a chain 1729

Figure K-5—Near simultaneous recoveries 1730

Figure K-6—Near simultaneous failure and recovery 1730

Figure K-7—Loss with quick recovery 1731

Figure L-1—Credit-based shaper operation—no conflicting traffic 1734

Figure L-2—Credit-based shaper operation—conflicting traffic 1735

Figure L-3—Credit-based shaper operation—burst traffic 1736

Figure L-4—Interference and latency 1740

Figure L-5—Burst behavior and credit 1740

Figure L-6—Fan-in scenario 1744

Figure L-7—Permanent delay scenario 1745

Figure L-8—Building up buffer occupancy—1 1746

Figure L-9—Building up buffer occupancy—2 1746

Figure L-10—Building up buffer occupancy—3 1747

Figure L-11—Building up buffer occupancy—4 1747

Figure M-1—PFC PDU format 1749

Figure N-1—PFC delays 1750

Figure N-2—Delay model 1751

Figure N-3—Worst-case delay 1752

Figure O-1—Converting a CRC to an FCS 1757

Figure O-2—Detection Lossless Circuit 1757

Figure O-3—Field change adjustment 1759

Figure O-4—Field insertion adjustment 1760

Figure P-1—Frame duplication scenario 1763

Figure P-2—Frame misordering scenario 1764

Tables

Table 6-1—Bridge transit delay 68

Table 6-2—Priority Code Point encoding ...... 76

Table 6-3—Priority Code Point decoding ..... 76

Table 6-4—Priority regeneration ....77

Table 6-5—Default SRP domain boundary port priority regeneration override values 78

Table 6-6—Service Access Priority 89

Table 6-7—Encapsulated Addresses EtherType 96

Table 8-1—C-VLAN and MAC Bridge component Reserved addresses 122

Table 8-2—S-VLAN component Reserved addresses 123

Table 8-3—TPMR component Reserved addresses 123

Table 8-4—Recommended priority to traffic class mappings .... 126

Table 8-5—Transmission selection algorithm identifiers .... 128

Table 8-6—Ageing time parameter value ...... 131

Table 8-7—Combining Static and Dynamic Filtering Entries for an individual MAC address ..... 140

Table 8-8—Combining Static Filtering Entry and MAC Address Registration Entry for “All Group Addresses” and “All Unregistered Group Addresses” .... 141

Table 8-9—Forwarding or Filtering for specific group MAC addresses 142

Table 8-10—Forwarding or Filtering with Dynamic Reservation Entries 143

Table 8-11—Determination of whether a Port is in a VID's member set .... 144

Table 8-12—Standard LLC address assignment 148

Table 8-13—ISIS-SPB reserved addresses 150

Table 8-14—ISIS-SPB Recommended Address Usage 151

Table 8-15—CCM group destination MAC addresses 157

Table 8-16—LTM group destination MAC addresses 157

Table 9-1—IEEE 802.1Q EtherType allocations 160

Table 9-2—Reserved VID values .... 160

Table 9-3—Reserved I-SID values ...... 162

Table 10-1—MRP application addresses .... 170

Table 10-2—MRP EtherType values ...... 171

Table 10-3—Applicant state table 184

Table 10-4—Registrar state table 185

Table 10-6—PeriodicTransmission state table 186

Table 10-5—LeaveAll state table 186

Table 10-7—MRP timer parameter values .... 187

Table 12-1—Component table entry managed object ...... 220

Table 12-2—Port table entry 221

Table 12-3—ISS Port Number table entry 222

Table 12-4—Bandwidth Availability Parameter Table row elements ...... 326

Table 12-5—Transmission Selection Algorithm Table row elements 327

Table 12-6—Priority Regeneration Override Table row elements 327

Table 12-7—CN component managed object row elements ...... 328

Table 12-8—CN component priority managed object row elements ...... 329

Table 12-10—Congestion Point managed object row elements 330

Table 12-9—CN Port priority managed object row elements 330

Table 12-11—Reaction Point port priority managed object row elements 331

Table 12-12—Reaction Point group managed object row elements ...... 331

Table 12-13—SRP Bridge Base Table row elements ...... 332

Table 12-14—SRP Bridge Port Table row elements 332

Table 12-15—SRP Latency Parameter Table row elements ...... 333

Table 12-16—SRP Stream Table row elements .... 333

Table 12-17—SRP Reservations Table row elements ...... 334

Table 12-15—Priority-based Flow Control objects ...... 334

Table 12-17—EVB system base table 358

Table 12-18—EVB system parameter defaults 360

Table 12-20—VSI table entry 361

Table 12-19—SBP table entry 361

Table 12-21—VSI MAC/VLAN table entry 363

Table 12-22—UAP table entry 364

Table 12-23—UAP table entry parameters 364

Table 12-24—S-channel interface table entry 365

Table 12-25—URP table entry 366

Table 12-26—ECP table entry 367

Table 13-1—Configuration Digest Signature Key 383

Table 13-2—Sample Configuration Digest Signature Keys 384

Table 13-3—Bridge and Port Priority values 402

Table 13-4—Port Path Cost values 403

Table 13-5—Timer and related parameter values .... 411

Table 17-1—Structure of the MIB modules ..... 482

Table 17-2—IEEE8021-TC-MIB Structure 484

Table 17-3—IEEE8021-BRIDGE-MIB structure and relationship to IETF RFC 4188 and this standard .... 485

Table 17-4—IEEE 802.1D objects not in the IEEE8021-BRIDGE-MIB 490

Table 17-5—IEEE8021-SPANNING-TREE MIB structure and relationship to IETF RFC 4318 and this standard .... 490

Table 17-6—Clause 12 objects not in the IEEE8021-SPANNING-TREE MIB 492

Table 17-7—IEEE8021-QBRIDGE MIB structure and relationship to IETF RFC 4363 and this standard .... 493

Table 17-8—Clause 12 management not in IEEE8021-Q-BRIDGE-MIB 498

Table 17-9—IEEE8021-PB-MIB structure and relationship to this standard 499

Table 17-10—IEEE8021-MSTP-MIB structure and relationship to this standard .... 501

Table 17-11—IEEE8021-CFM-MIB correspondence between variables, managed objects, and MIB objects .... 503

Table 17-12—IEEE8021-CFM-V2-MIB correspondence between variables, managed objects, and MIB objects .... 507

Table 17-13—IEEE8021-PBB-MIB structure and relationship to this standard 509

Table 17-14—IEEE8021-DDCFM-MIB structure and relationship to this standard .... 512

Table 17-15—IEEE8021-PBBTE-MIB Structure and relationship to this standard 514

Table 17-16—Example of ieee8021PbbTeTeSiEspTable 516

Table 17-17—IEEE8021-TPMR-MIB Structure and relationship to this standard 517

Table 17-18—FQTSS MIB structure and object cross reference 519

Table 17-19—Variables, managed object tables, and MIB objects 520

Table 17-20—SRP MIB structure and object cross reference 522

Table 17-21—IEEE8021-MVRPX-MIB structure and relationship to this standard 524

Table 17-22—IEEE8021-MIRP-MIB structure and relationship to this standard 524

Table 17-23—Variables, managed object tables, and MIB objects 525

Table 17-24—IEEE8021-TE IPS MIB Structure and relationship to this standard 525

Table 17-25—IEEE8021-SPB-MIB structure and relationship to this standard 527

Table 17-26—EVB MIB structure and object cross reference 531

Table 17-27—IEEE8021-ECMP-MIB structure and relationship to this standard 534

Table 17-28—PBB-TE required MIB compliances 543

Table 17-30—Sensitive managed objects: variables in dot1agCfmMdTable 551

Table 17-29—Sensitive managed objects: tables and notifications 551

Table 17-32—Sensitive managed objects (of DDCFM) for read 553

Table 17-31—Sensitive managed objects (of DDCFM): tables and notifications 553

Table 17-33—Sensitive managed objects (of EVB): tables and notifications .... 560

Table 17-34—Sensitive managed objects (of EVB) for read 560

Table 17-35—Provider Bridge service interface parameters 574

Table 17-36—PBB service interface parameters .... 577

Table 19-1—Actions taken by MP OpCode Demultiplexers 1077

Table 19-2—SAP use for LTMs and LTRs 1084

Table 20-1—Fault Alarm defects and priorities .... 1089

Table 20-2—Deriving enableRmepDefect and Port Status TLV in a Bridge 1099

Table 21-1—CFM PDU Encapsulation: Length/Type Media 1143

Table 21-2—CFM PDU Encapsulation: LLC Media 1143

Table 21-3—Common CFM Header format .... 1144

Table 21-4—OpCode Field range assignments .... 1144

Table 21-5—TLV format 1145

Table 21-6—Type Field values 1146

Table 21-8—Sender ID TLV format 1147

Table 21-7—Organization-Specific TLV format 1147

Table 21-9—Port Status TLV format 1149

Table 21-10—Port Status TLV values 1149

Table 21-11—Interface Status TLV format 1149

Table 21-13—Data TLV format 1150

Table 21-14—End TLV format 1150

Table 21-12— Interface Status TLV values ...... 1150

Table 21-15—CCM format .... 1151

Table 21-16—CCM Interval field encoding .... 1152

Table 21-17—CCM Maintenance Association Identifier field format: Maintenance Domain present .... 1153

Table 21-18—CCM Maintenance Association Identifier field format: Maintenance Domain not present 1153

Table 21-19—Maintenance Domain Name Format 1154

Table 21-20—Short MA Name Format 1154

Table 21-21—LBM and LBR formats .... 1156

Table 21-22—PBB-TE MIP TLV format 1157

Table 21-23—LTM format 1158

Table 21-24—LTM Flags field 1158

Table 21-26—LTR format 1160

Table 21-27—LTR Flags field 1160

Table 21-25—LTM Egress Identifier TLV format 1160

Table 21-28—Relay Action field values ...... 1161

Table 21-29—LTR Egress Identifier TLV format 1162

Table 21-30—Reply Ingress TLV format .... 1162

Table 21-31—Ingress Action field values .... 1163

Table 21-33—Egress Action field values .... 1164

Table 21-32—Reply Egress TLV format 1164

Table 22-1—MEP creation 1178

Table 22-2—MIP creation .... 1179

Table 22-3—Bandwidth required for CCMs for 1 MA 1182

Table 22-4—Bandwidth required for CCMs for 1000 MAs 1183

Table 23-1—Time sequence diagram symbols ...... 1193

Table 23-2—MSP performance parameters 1199

Table 23-3—MSP EtherType assignment 1205

Table 23-4—MSP Packet Types .... 1206

Table 24-1—Transmission and reception delays 1208

Table 26-1—Backbone Service Instance Group address OUI 1231

Table 26-8—Protection Requests Hierarchy 1254

Table 27-1—Allocation of VIDs to FIDs and FIDs to MSTIDs in an SPT Region (example) ..... 1277

Table 28-1—Bridge Priority Masking .... 1306

Table 29-1—RFM format 1341

Table 29-2—SFM format 1342

Table 32-1—LLDP instance selection managed object overrides 1364

Table 32-2—CND defense mode selection managed object overrides 1364

Table 32-3—Determining cnpdIsAdminDefMode and cnpdDefenseMode 1370

Table 32-4—Correspondence of QCN and CCF message fields 1372

Table 32-5—NewCpSampleBase() return value as a function of cpFb 1375

Table 33-3—CNM Encapsulation: Length/Type Media 1387

Table 33-1—CN-TAG Encapsulation: Length/Type Media 1387

Table 33-2—CN-TAG Encapsulation: LLC Media 1387

Table 33-5—Congestion Notification Message PDU 1388

Table 33-4—CNM Encapsulation: LLC Media 1388

Table 34-1—Recommended priority to traffic class mappings for SR classes A and B ..... 1395

Table 34-2—Recommended priority to traffic class mappings for SR class B only 1395

Table 35-1—AttributeType Values 1405

Table 35-2—AttributeLength Values 1406

Table 35-4—MSRP FirstValue NumberOfValues example 1407

Table 35-3—FourPackedEvent Values 1407

Table 35-5—TSpec components examples ...... 1411

Table 35-6—Reservation Failure Codes 1413

Table 35-7—SR class ID 1414

Table 35-8—Summary of Talker primitives .... 1416

Table 35-9—Summary of Listener primitives ...... 1416

Table 35-11—Incoming Listener attribute propagation per port 1421

Table 35-10—Talker attribute propagation per port 1421

Table 35-12—Updating Dynamic Reservation Entries 1422

Table 35-14—Listener Declaration Type Summation 1423

Table 35-13—Updating operIdleSlope(N) 1423

Table 41-1—VDP TLV types 1454

Table 41-2—Flag values in VDP requests 1455

Table 41-3—Error types in VDP responses 1455

Table 41-5—VSIID format values 1456

Table 41-4—Flag values in VDP responses 1456

Table 41-6—Filter Info format values 1457

Table 43-1—ECP subtypes 1477

Table 44-1—ECMP ECT-ALGORITHM values 1485

Table 44-2—F-TAG EtherType 1486

Table C-1—SRP to MoCA PQoS Transaction mapping 1574

Table C-2—SRP TSpec to MoCA TSPEC mapping 1575

Table C-3—SRP StreamID to MoCA PQoS Flow transaction mapping 1575

Table C-4—SRP to MLME QoS Services mapping 1581

Table C-5—EDCA-AC for AV Streams 1582

Table C-6—HCCA for AV Streams 1583

Table D-1—IEEE 802.1 Organizationally Specific TLVs specified in this standard 1584

Table D-2—Port and protocol capability/status 1586

Table D-3—Link Aggregation capability/status 1589

Table D-4—Priority assignment table 1591

Table D-5—Traffic class bandwidth assignment table 1592

Table D-6—TSA Assignment Table 1592

Table D-7—PFC Enable bit vector 1595

Table D-8—Application Priority Table 1596

Table D-9—Sel field values 1596

Table D-10—RRSAT flag values and meanings 1598

Table D-11—EVB Mode values 1599

Table D-12—IEEE 802.1 extension MIB object group conformance requirements ..... 1607

Table D-13—IEEE 802.1/LLDP extension MIB object cross reference 1608

Table E-1—State machine symbols 1693

Table I-1—Traffic type to traffic class mapping 1712

Table I-2—Traffic type acronyms 1714

Table I-3—Defining traffic types 1715

Table I-5—Defining traffic types—Credit-based shaper support of SR classes A and B 1716

Table I-4—Defining traffic types—Credit-based shaper support of SR class B only 1716

Table I-6—Priority Code Point encoding 1718

Table I-7—Priority Code Point decoding 1718

Table J-1—Provider MD Level allocation 1720

Table J-2—IEEE / ITU-T terminology differences 1720

Table N-1—IEEE 802.3 Interface Delays 1753

IEEE Standard for Local and metropolitan area networks—

Bridges and Bridged Networks

IMPORTANT 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 applicable laws and regulations.

This IEEE document is made available for use subject to important notices and legal disclaimers. These notices and disclaimers appear in all publications containing this document and may be found under the heading “Important Notice” or “Important Notices and Disclaimers Concerning IEEE Documents.” They can also be obtained on request from IEEE or viewed at http://standards.ieee.org/IPR/disclaimers.html.

1 Overview

IEEE 802 $^{®}$ Local Area Networks (LANs, 3.93) $^{1}$ of all types can be connected together with Media Access Control (MAC) Bridges (3.130) or Virtual Local Area Network (VLAN) Bridges (3.259), collectively known as Bridges (3.22). This standard defines the operation of Bridges and Bridged Networks. VLANs facilitate the administration of logical groups of stations. Stations in the same VLAN communicate as if they were on the same LAN, while traffic between VLANs is restricted. Management of VLAN Bridges and stations allows stations to be added to, removed from, or moved between VLANs.

This standard further extends the specification of VLAN Bridges to enable a service provider organization to use a common infrastructure of Bridges and LANs to offer the equivalent of separate LANs, Bridged, or Virtual Bridged Networks to independent customer organizations.

This standard specifies protocols and protocol entities within the architecture of Bridges that provide capabilities for detecting, verifying, and isolating connectivity failures in Bridged Networks. These capabilities can be used in networks operated by multiple independent organizations, each with restricted management access to each other's equipment.

1.1 Scope

This standard specifies Bridges that interconnect individual LANs, each supporting the IEEE 802 MAC Service using a different or identical media access control method, to provide Bridged Networks and VLANs.

1.2 Purpose

Bridges, as specified by this standard, allow the compatible interconnection of information technology equipment attached to separate individual LANs.

1.3 Introduction

For the purpose of compatible interconnection of information technology equipment using the IEEE 802 MAC Service supported by interconnected IEEE 802 standard LANs using different or identical media access control methods, this standard specifies the operation of MAC Bridges and VLAN Bridges. To this end, it

a) Positions the support of VLANs within an architectural description of the MAC Sublayer.

b) Defines the principles of operation of the MAC Bridge and VLAN Bridge in terms of the support and preservation of the MAC Service, and the maintenance of quality of service (QoS).

c) Specifies an Enhanced Internal Sublayer Service (EISS) provided to the Media Access-Independent functions that provide frame relay in a VLAN Bridge.

d) Establishes the principles and a model of Virtual Bridged Network operation.

e) Identifies the functions to be performed by Bridges, and provides an architectural model of the operation of a Bridge in terms of processes and entities that provide those functions.

f) Specifies a frame format that allows a VLAN Identifier (VID) and priority information to be carried by VLAN-tagged user data frames.

g) Specifies the rules that govern the addition or removal of VLAN tags to and from user data frames.

h) Establishes the requirements for automatic configuration of VLAN topology.

i) Establishes the requirements for VLAN Bridge Management in a Virtual Bridged Network, identifying managed objects and defining management operations.

j) Defines SMIv2 (IETF STD 58) Management Information Based (MIB) modules for the management of VLAN Bridge capabilities including spanning tree protocols and Provider Bridges.

k) Defines the operation of the Multiple Spanning Tree Algorithm and Protocol (MSTP).

1) Describes the protocols and procedures necessary to support interoperation between Multiple Spanning Tree (MST) and Single Spanning Tree (SST) Bridges in the same Virtual Bridged Networks.

m) Specifies the requirements to be satisfied by equipment claiming conformance to this standard.

To enable a service provider to use a Virtual Bridged Network to provide separate instances of the IEEE 802 MAC Service, MAC Internal Sublayer Service (ISS), and EISS to multiple independent customers, in a manner that does not require cooperation among the customers and that requires a minimum of cooperation between the customers and the provider of the MAC Service, this standard further specifies the operation of Provider Bridges. To this end, it

n) Differentiates Customer VLANs (C-VLANs) that are under the administrative control of a single customer of a service provider, from the Service VLANs (S-VLANs) that are used by a service provider to support different customers.

o) Specifies VLAN tag formats for both C-VLANs and S-VLANs, allowing each to be distinguished and separately applied and administered by customers and by a service provider.

p) Specifies the functionality of a generic VLAN Bridge component within a system and the specific requirements of derived C-VLAN and S-VLAN components.

q) Specifies a C-VLAN Bridge as comprising a single C-VLAN component, and a Provider Bridge as encompassing Bridges that comprise a single S-VLAN component and no C-VLAN components (S-VLAN Bridge) or a single S-VLAN component and one or more C-VLAN components (Provider Edge Bridge).

r) Specifies parameters and mappings that allow the EISS to support traffic classes that comprise distinct aggregate flows supporting different QoS characteristics and provide independent guarantees to different customers, through support of priority and drop precedence marking.

s) Specifies the incorporation of flow metering, transmission queue management, and transmission selection algorithms within the forwarding process of a Bridge.

t) Positions the support of S-VLANs within the architectural description of the MAC Sublayer and specifies their relationship to media access method-dependent functions and to the media-independent functions used by customers to administer their networks, including the support of C-VLANs.

u) Allocates the reserved multicast addresses to media access method-dependent, provider network, and customer network functions, specifying the filtering to be applied in each type of VLAN Bridge component.

v) Defines the principles of network operation in terms of the support and preservation of the MAC Service, and the maintenance of QoS for each service instance, including the segregation of data belonging to different organizations.

w) Specifies customer interfaces to a Provider Bridged Network (PBN) in terms of the operation and configuration of the VLAN Bridge components of Provider Bridges, including interfaces that

1) Provide access to a single service instance through a Bridge Port.

2) Allow a customer to select among and identify service instances by Customer VLAN Identifier (C-VID).

3) Allow a customer to select among and identify service instances by Service VLAN Identifier (S-VID).

4) Support customer signaling of priority information on a frame by frame basis.

5) Multiplex service instances over LANs that provide access to a provider network.

6) Support fault tolerance through redundant provision of access LANs and equipment.

x) Describes the functions to be performed within the PBN in order to support and maintain the connectivity provided to customer service instances.

y) Establishes the requirements for Bridge Management in the PBN, identifying the managed objects and defining the management operations.

z) Specifies performance requirements, and recommends default values and applicable ranges for the operational parameters of a Provider Bridge.

This standard specifies protocols, procedures, and managed objects to support Connectivity Fault Management (CFM). These allow discovery and verification of the path, through Bridges and LANs, taken for frames addressed to and from specified network users, and support detection and isolation of a connectivity fault to a specific Bridge or LAN. To this end, it

aa) Defines Maintenance Domains, Maintenance Associations (MAs), their constituent Maintenance Points (MPs), and the managed objects required to create and administer them.

ab) Describes the protocols and procedures used by MPs to detect and diagnose connectivity faults within a Maintenance Domain.

This standard specifies protocols, procedures, and managed objects to allow support of provisioning systems that explicitly select traffic engineered paths within Provider Backbone Bridged Networks (PBBNs) by allowing a network operator to disable unknown destination address forwarding, source address learning and spanning tree protocols for administratively selected VIDs, while allowing other network control protocols to dynamically determine active topologies for other services. These interoperable capabilities are supported by management of individual Bridges by Simple Network Management Protocol (SNMP) using an SMIv2

MIB, by extensions to the other control protocols specified in this standard, by the use of CFM with the addresses and VIDs that specify traffic engineered connections, and by 1:1 path protection switching capable of load sharing. To this end, it

ac) Enables construction of active topologies by an external agent that is responsible for setting up Ethernet Switched Paths (ESPs) by splitting the B-VID space between distributed spanning tree protocols and provisioned control.

ad) Supports discard of frames with unknown destination addresses for B-VIDs under provisioned control.

ae) Supports the operation of Continuity Check, Loopback, and Linktrace protocols on provisioned traffic engineered paths.

af) Supports 1:1 protection switching capable of load sharing for Traffic Engineering service instances (TESIs).

ag) Supports protection of a group of TESIs that traverses a sequence of LANs and intervening Bridges using a method that does not require the modification of data or control frames.

ah) Provides required extension to SNMP management by SMIv2 MIB modules.

This standard does not specify operation of ESPs through multiple Provider Backbone Bridge Traffic Engineering (PBB-TE) Regions. All the Backbone Edge Bridges (BEBs) specified for use in a PBB-TE Region are combined I type and B type Backbone Edge Bridges (IB-BEBs).

This standard specifies protocols, procedures, and managed objects to support the Multiple Registration Protocol (MRP). MRP allows participants in an MRP Application to register attributes with other participants in a Bridged Network. Four applications are defined—one to register VIDs [Multiple VLAN Registration Protocol (MVRP)], one to register MAC addresses [Multiple MAC Registration Protocol (MMRP)], one to register Streams and configure associated network resources [Multiple Stream Registration Protocol (MSRP)], and one that provides the ability to flush learned MAC Address Entries held in the Filtering Database (FDB) of an I-component on a per-I-SID basis [Multiple I-SID Registration Protocol (MIRP)]. MVRP will furthermore provide for the rapid healing of network failures without interrupting services to unaffected VLANs. To this end, it specifies the following:

ai) MRP and the operation of MRP entities. $^{2}$

aj) The generic frame formats used in MRP exchanges.

ak) The MMRP application of MRP, and the frame formats that it uses.

al) The MVRP application of MRP, and the frame formats that it uses.

To allow scaling of Provider Networks to at least $2^{24}$ S-VLANs, this standard further specifies the operation of Provider Backbone Bridges (PBBs) by means of an architecture and Bridge protocols compatible and interoperable with PBN protocols and equipment, allowing interconnection of multiple PBNs. To this end, it

am) Introduces BEBs that, by exchanging backbone frames that encapsulate the addresses, VLAN tags, and data of customer frames, support the virtual, media-independent equivalent of a number of independent instances of the service provided by media-dependent frame transmission procedures.

an) Extends the parameters of the ISS and EISS to include a connection identifier, capable of referencing the backbone addresses and other parameters, used to convey customer frames from one BEB to all, or one of, the other BEBs supporting a particular backbone service instance.

ao) Specifies the format of the Backbone Service Instance tag (I-TAG) that encapsulates the customer addresses, and introduces a Backbone Service Instance Identifier (I-SID) that allows each BEB to support a number of backbone service instances and permits the unambiguous identification of up to $2^{24}$ backbone service instances within a single PBBN.

ap) Provides a model of BEB operation in terms of VLAN Bridge components that allows the use of Provider Bridges as Backbone Core Bridges (BCBs), with PBBN traffic carried as frames containing I-TAGs on particular Backbone VLANs (B-VLANs) potentially coexisting with PBN traffic carried as frames without I-TAGs on other B-VLANs.

aq) Specifies the interfaces that a PBBN can provide to transport service frames. These comprise a Port-based service interface that assigns all received untagged and priority-tagged frames to a single S-VLAN transported over a single backbone service instance, an S-tagged service interface capable of mapping individual S-VLANs to different backbone service instances, and an I-tagged service interface capable of mapping frames from one set of backbone service instances to another.

ar) Describes the use of redundant Bridges and access LANs to protect backbone service access against failure of any of those systems or components.

as) Specifies the management of BEBs in terms of the model of operation [item ap) above], making use of defined management objects for the individual VLAN Bridge components, and adding managed objects to facilitate service creation.

at) Describes the use of CFM to detect and isolate faults in the connectivity provided to individual S-VLANs across the PBBN, in the connectivity provided to the group of S-VLANs supported by a single backbone service instance (identified by an I-SID), and in the connectivity provided to individual B-VLANs within the backbone itself.

au) Specifies extensions to MSTP to allow network administrators to protect against loops through peered PBBNs without requiring coupling of spanning trees that operate independently for each PBBN.

This standard specifies CFM protocols, procedures, and managed objects that provide confirmation of successful transmission of frames conveying specified data. This capability supports diagnosis of faults sensitive to, or caused by, particular data patterns, and their isolation to part of the transmission path. Connectivity verification can be carried out from any single point with bridged connectivity to MPs on the path, can isolate failures to communicate in a specific direction, and can be carried out while service is being provided to other users of the data path. To this end, it

av) Defines the extensions to CFM capabilities defined by Clause 18 through Clause 22 to facilitate diagnosis and isolation of faults sensitive to, or caused by, particular data patterns in frames transmitted by a service user.

aw) Describes the protocols and procedures for data-driven and data-dependent connectivity fault management (DDCFM).

This standard specifies the function of a Two-Port MAC Relay (TPMR), along with protocols and procedures that support its operation. A TPMR is a type of Bridge that has only two externally accessible Bridge Ports, and supports a subset of the functionality of a MAC Bridge. A TPMR is transparent to all frame-based media-independent protocols, except those explicitly addressed to it and those that are destined for reserved MAC addresses that the relay function of the TPMR is defined not to forward. It is remotely manageable through at least one of its external MACs, and signals a failure of either MAC's LAN through the other MAC. A TPMR should only be attached to point-to-point LANs. The conformance requirements for a TPMR are stated in 5.13 and 5.15.

This standard allows Bridges to provide performance guarantees for time-sensitive (i.e., bounded latency and latency variation) loss-sensitive real-time audio/video (AV) data stream transmission (AV traffic). It specifies priority regeneration and controlled bandwidth queue draining algorithms. VLAN tag encoded priority values are allocated, in aggregate, to segregate frames among queues that support AV traffic and queues that support non-AV traffic, allowing simultaneous support of both AV traffic and other bridged traffic over and between wired and wireless Local Area Networks (LANs). To this end, it

ax) Defines status parameters that allow the boundaries of a Stream Reservation Protocol (SRP—see Clause 35) domain (35.1.4) to be identified and maintained.

ay) Specifies how the priority information in frames received at SRP domain boundary ports is regenerated.

NOTE 1—The priorities in frames transmitted from outside an SRP domain to a Bridge inside an SRP domain are remapped in order to ensure that traffic that is not associated with a reservation does not disrupt traffic that is associated with a reservation. Hence, traffic entering an SRP domain that uses Priority Code Point values associated with reserved traffic classes will be remapped to Priority Code Point values that are not associated with reserved traffic classes. $^{3}$

az) Specifies how priority information is used to determine the traffic classes to be used for time-sensitive streams.

ba) Defines a credit-based shaper algorithm to shape traffic in accordance with stream reservations.

NOTE 2—The credit-based shaper algorithm operates on the outbound queues; the mechanisms specified for the support of time-sensitive AV traffic do not involve any form of ingress metering or policing.

This standard specifies protocols, procedures, and managed objects to support congestion notification. These allow a Virtual Bridged Network or a portion thereof, with a limited bandwidth-delay product, to transfer long-lived data flows with a significantly reduced chance of frame loss compared to a network without congestion notification. To this end, it

bb) Defines a means for VLAN Bridges that support congestion notification to form Congestion Managed Domains within a Virtual Bridged Network.

bc) Defines a means for detecting congested queues in end stations and VLAN Bridges, for signaling such congestion to the end stations sourcing the frames causing the congestion, and for those end stations to control the rate of transmission of those frames.

To enable the end-to-end management of resource reservation for QoS guaranteed streams, this standard further specifies protocols, procedures, and managed objects, usable by existing higher layer mechanisms, that allow network resources to be reserved for specific traffic streams traversing a Bridged Network. To this end, it

bd) Specifies the use of Dynamic Reservation Entries (8.8.7) in the FDB to control the forwarding of frames associated with a particular Stream.

be) Specifies a Stream Reservation Protocol (SRP). SRP facilitates the registration, deregistration and maintenance of stream reservation information in relevant Bridges to establish end-to-end stream paths.

This standard specifies protocols, procedures, and managed objects to support topology change signaling to alter the binding (held in an I-Component) of Customer addresses to backbone addresses on a per-I-SID basis. This is accomplished by extending the use of MRP. To this end, it specifies the MIRP application of MRP and the frame formats that it uses.

NOTE 3—MIRP can only trigger the flushing of learned MAC address information; it does not propagate the registration of I-SIDs. The name Multiple I-SID Registration Protocol is chosen because MIRP is a Multiple Registration Protocol (MRP) application and can be extended in the future to perform I-SID registrations.

This standard allows an S-tagged service interface connecting two independently administered PBNs to be used to handle traffic (identified by a single S-VID) for a given customer attached to one PBN as if the customer were directly attached to the other PBN using a Port-based or C-tagged service interface. To this end, it

bf) Specifies the use of a Port-mapping S-VLAN component to associate selected S-VIDs registered on an external port with distinct internal ports, each of which supports a separate service interface.

This standard specifies protocols, procedures, and managed objects to support Priority-based Flow Control (PFC). These allow a Virtual Bridged Network, or a portion thereof, to enable flow control per traffic class on IEEE 802 point-to-point full-duplex links. To this end, it

bg) Defines a means for a system to inhibit transmission of data frames on certain priorities from the remote system on the link.

This standard specifies protocols, procedures, and managed objects for enhancement of transmission selection to support allocation of bandwidth among traffic classes. When the offered load in a traffic class does not use its allocated bandwidth, Enhanced Transmission Selection (ETS) will allow other traffic classes to use the available bandwidth. Bandwidth is used by traffic classes subject to ETS when there are no frames to be transmitted for traffic classes subject to strict priority or credit-based shaper algorithms. It defines the Data Center Bridging eXchange protocol (DCBX), which controls the application of ETS and PFC.

This standard specifies Shortest Path Bridging (SPB) of unicast and multicast frames, specifying protocols to calculate multiple active topologies that can share learned station information, and support of a VLAN by multiple, per-topology, Shortest Path VLAN Identifiers (SPVIDs). To this end, it

bh) Describes the use of shortest paths to increase throughput and minimize transit delay, while introducing a negligible rate of frame misordering.

bi) Requires that active topologies calculated by spanning tree protocols and Shortest Path Tree (SPT) protocols be stable, predictable, and reproducible to maintain the characteristics of the MAC Service provided.

bj) Requires, except in the case of SPB using Equal Cost Multiple Paths (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 4—ECMP 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.

bk) Specifies the calculation of symmetric sets of SPTs, each rooted at a Bridge within an SPT Region comprising Bridges operating compatible protocols and configurations.

bl) Specifies the use of Bridge Protocol Data Units (BPDUs) to identify and bound SPT Regions and to ensure loop-free interoperability with regions using the Rapid Spanning Tree Algorithm and Protocol (RSTP) and MSTP.

bm) Specifies both Shortest Path Bridging VID (SPBV) and Shortest Path Bridging MAC (SPBM) modes:

1) for SPBV, identifying each SPT by SPVID and locating end stations by source MAC address learning.

2) for SPBM, identifying each SPT by VID and source MAC address and distributing end station location information explicitly.

bn) Supports management selection of the Common Spanning Tree (CST), a Multiple Spanning Tree Instance (MSTI), or SPB for support of any given VLAN within an SPT Region.

bo) Specifies a protocol that automatically assigns SPVIDs for each VLAN supported by SPBV.

bp) Supports load sharing by Equal Cost Trees (ECTs) through the calculation of multiple SPT Sets, with each shortest path VLAN being assigned to one SPT Set.

bq) Specifies Intermediate System to Intermediate System Protocol for Shortest Path Bridging (ISIS-SPB): the use of and extensions to the Intermediate System to Intermediate System (IS-IS) Protocol to calculate SPTs for both SPBV and SPBM.

br) Describes the addressing of ISIS-SPB entities and specifies the group MAC addresses they use.

bs) Specifies the use of loop prevention (for SPBV and for multicast frames for SPBM) and loop mitigation (for unicast frames for SPBM).

bt) Specifies an Agreement Protocol that prevents loops, specifying the necessary state information and computation as part of ISIS-SPB and communicating agreement information for the CIST and (as a compact Digest) for SPTs in each BPDU.

This standard specifies protocols, procedures, and managed objects that

bu) Provide for the discovery, configuration, and control of a pair of direct-attached Port-mapping S-VLAN components to extend the operation of a Customer Bridge to remote ports and enable coexistence of multiple services on station-resident ports (e.g., embedded bridging).

bv) Provide for discovery, configuration, and operation of reflective relay (8.6.1) for a Bridge Port.

bw) Provide for discovery of, and coordinated configuration of, edge relays (ERs) and other devices that utilize the reflective relay service.

bx) Provide for dynamic profile-driven port configuration.

by) 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.

bz) Specifies a flow filtering tag (F-TAG) containing a flow hash used in unicast ECMP traffic distribution and a TTL (time-to-live) field used to mitigate the effects of traffic loops resulting from transient conditions or control software errors or faults.

2 Normative references

The following referenced documents are indispensable for the application of this document (i.e., they must be understood and used, so each referenced document is cited in the text and its relationship to this document is explained). For dated references, only the edition cited applies. For undated references, the latest edition of the referenced document (including any amendments or corrigenda) applies.

ANSI X3.159, American National Standards for Information Systems—Programming Language—C. $^{4}$

IEEE Std 802 $^{®}$ , IEEE Standards for Local and Metropolitan Area Networks: Overview and Architecture. $^{5,6}$

IEEE Std 802.1AB $^{™}$ , IEEE Standard for Local and metropolitan area networks—Station and Media Access Control Connectivity Discovery.

IEEE Std 802.1AC $^{™}$ , IEEE Standard for Local and metropolitan area networks—Media Access Control (MAC) Service Definition.

IEEE Std 802.1AE™, IEEE Standard for Local and metropolitan area networks—Media Access Control (MAC) Security.

IEEE Std 802.1AX™, IEEE Standard for Local and metropolitan area networks—Link Aggregation.

IEEE Std 802.1BR™, IEEE Standard for Local and metropolitan area networks—Virtual Bridged Local Area Networks—Bridge Port Extension.

IEEE Std 802.1X $^{™}$ , IEEE Standards for Local and Metropolitan Area Networks—Port Based Network Access Control.

IEEE Std 802.3™, IEEE Standard for Ethernet.

IEEE Std 802.11 $^{™}$ , Information technology—Telecommunications and information exchange between systems—Local and metropolitan area networks—Specific requirements—Part 11: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Specifications.

IEEE Std 802.17 $^{™}$ , Information technology—Telecommunications and information exchange between systems—Local and metropolitan area networks—Specific requirements—Part 17: Resilient packet ring (RPR) access method and physical layer specifications.

IEEE Std 802.20 $^{™}$ , IEEE Standard for Local and metropolitan area networks—Part 20: Air Interface for Mobile Broadband Wireless Access Systems Supporting Vehicular Mobility—Physical and Media Access Control Layer Specification.

IETF RFC 1035 (STD 13), Domain Names: Implementation and Specification, November 1987. $^{7}$

IETF RFC 1042, A Standard for the Transmission of IP Datagrams over IEEE 802 Networks, February 1988.

IETF RFC 2104, HMAC: Keyed-Hashing for Message Authentication, February 1997.

IETF RFC 2119 (BCP 14), Key Words for Use in RFCs to Indicate Requirement Levels, March 1997.

IETF RFC 2205, Resource ReSerVation Protocol (RSVP) — Version 1 Functional Specification, September 1997.

IETF RFC 2578 (STD 58), Structure of Management Information Version 2 (SMIv2), April 1999.

IETF RFC 2579 (STD 58), Textual Conventions for SMIv2, April 1999.

IETF RFC 2580 (STD 58), Conformance Statements for SMIv2, April 1999.

IETF RFC 2685, Virtual Private Networks Identifier, September 1999.

IETF RFC 2750, RSVP Extensions for Policy Control, January 2000.

IETF RFC 2863, The Interfaces Group MIB, June 2000.

IETF RFC 3410, Introduction and Applicability Statements for Internet-Standard Management Framework, December 2002.

IETF RFC 3411, An Architecture for Describing Simple Network Management Protocol (SNMP) Management Frameworks, December 2002.

IETF RFC 3413 (STD 62), Simple Network Management Protocol (SNMP) Applications, December 2002.

IETF RFC 3414 (STD 62), User-based Security Model (USM) for Version 3 of the Simple Network Management Protocol (SNMPv3), December 2002.

IETF RFC 3415 (STD 62), View-based Access Control Model (VACM) for the Simple Network Management Protocol (SNMP), December 2002.

IETF RFC 3417 (STD 62), Transport Mappings for the Simple Network Management Protocol (SNMP), December 2002.

IETF RFC 3418 (STD 62), Management Information Base (MIB) for the Simple Network Management Protocol (SNMP), December 2002.

IETF RFC 3419, Textual Conventions for Transport Addresses, December 2002.

IETF RFC 4122, A Universally Unique IDentifier (UUID) URN Namespace, July 2005.

IETF RFC 4188, Definitions of Managed Objects for Bridges, September 2005.

IETF RFC 4291, IP Version 6 Addressing Architecture, February 2006.

IETF RFC 4318, Definitions of Managed Objects for Bridges with Rapid Spanning Tree Protocol, December 2005.

IETF RFC 4363, Definitions of Managed Objects for Bridges with Traffic Classes, Multicast Filtering, and Virtual LAN Extensions, January 2006.

IETF RFC 4789, Simple Network Management Protocol (SNMP) over IEEE 802 Networks, November 2006.

IETF RFC 5120, M-ISIS: Multi Topology (MT) Routing in Intermediate System to Intermediate Systems (IS-ISs), February 2008.

IETF RFC 5303, Three-Way Handshake for IS-IS Point-to-Point Adjacencies, October 2008.

IETF RFC 5305, IS-IS Extensions for Traffic Engineering, October 2008.

IETF RFC 6165, Extensions to IS-IS for Layer-2 Systems, April 2011.

ISO/IEC 7498-1, Information processing systems — Open Systems Interconnection — Basic Reference Model—Part 1: The Basic Model. $^{8}$

ISO/IEC 8802-2, Standard for Information technology — Telecommunications and information exchange between systems — Local and metropolitan area networks — Specific requirements — Part 2: Logical link control.

ISO/IEC 8802-11, Information technology — Telecommunications and information exchange between systems — Local and metropolitan area networks — Specific requirements — Part 11: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) specifications.

ISO/IEC 9577:1999, Information technology — Protocol identification in the network layer.

ISO/IEC 10589:2002, Information technology — Telecommunications and information exchange between systems — Intermediate System to Intermediate System intra-domain routeing information exchange protocol for use in conjunction with the protocol for providing the connectionless-mode network service.

ITU-T Recommendation X.690 (2002), Information Technology—ASN.1 Encoding Rules: Specification of Basic Encoding Rules (BER), Canonical Encoding Rules (CER), and Distinguished Encoding Rules (DER). $^{9}$

ITU-T Recommendation Y.1731 (02/2008), OAM Functions and Mechanisms for Ethernet-based Networks.

MEF Technical Specification 4 (MEF 4), Metro Ethernet Network Architecture Framework—Part 1: Generic Framework, May 2004. $^{10}$

MEF Technical Specification 10.2 (MEF 10.2), Ethernet Service Attributes Phase 2, May 2009.

3 Definitions

For the purposes of this document, the following terms and definitions apply. The IEEE Standards Dictionary Online should be consulted for terms not defined in this clause. $^{11}$

This standard makes use of the following terms defined in IEEE Std 802:

— end station

— station

The following terms are specific to this standard:

3.1 Active Segment: The Infrastructure Segment, either the Working Segment or the Protection Segment, that is currently carrying traffic of Traffic Engineering service instances (TESIs) associated with the Infrastructure Protection Group (IPG).

3.2 Active Service Access Point [SAP] (Active SAP): The SAP, bounding a Maintenance Point (MP), that is on the side of the MP toward the monitored Maintenance Association (MA).

3.3 Adjacency: A neighbor in Intermediate System to Intermediate System (IS-IS) Protocol. From section 3.6 of ISO/IEC 10589:2002.

3.4 Agreement Protocol: A protocol that uses control plane synchronization between adjacent Bridges to guarantee loop prevention, so enabling rapid transition to forwarding after network topology changes.

NOTE—See 13.16 and 13.17.

3.5 audio/video (AV) traffic: Traffic associated with audio and/or video applications that is sensitive to transmission latency and latency variation, and, for some applications, packet loss.

3.6 B-component (B-Comp): A Service Virtual Local Area Network (S-VLAN) component with one or more Customer Backbone Ports (CBPs).

3.7 B-DEI field: A field of a Backbone Virtual Local Area Network (B-VLAN) tag (B-TAG) that identifies the drop eligibility of the frame.

3.8 B-PCP field: A field of a Backbone Virtual Local Area Network (B-VLAN) tag (B-TAG) that indicates the B-VLAN priority of the frame.

3.9 Backbone Core Bridge (BCB): A Service Virtual Local Area Network (S-VLAN) Bridge used within the core of a Provider Backbone Bridged Network (PBBN).

3.10 Backbone Edge Bridge (BEB): A system that encapsulates customer frames for transmission across a Provider Backbone Bridged Network (PBBN).

3.11 Backbone Media Access Control (B-MAC) address: An individual Media Access Control (MAC) address associated with a Provider Instance Port (PIP) and used in creating the MAC header of I-tagged frames transmitted across a Provider Backbone Bridged Network (PBBN).

3.12 Backbone Media Access Control (B-MAC) Frame: A local area network (LAN) frame addressed with B-MAC addresses.

3.13 backbone service instance: An instance of the Media Access Control (MAC) Service in a Provider Backbone Bridged Network (PBBN), provided between two or more Virtual Instance Ports (VIPs) in Backbone Edge Bridges (BEBs).

3.14 Backbone Service Instance tag (I-TAG): A tag with an EtherType value allocated for “IEEE 802.1Q Backbone Service Instance Tag EtherType.”

3.15 Backbone Virtual Local Area Network (B-VLAN): A Virtual Local Area Network (VLAN) identified by a B-VLAN Identifier (B-VID).

3.16 Backbone Virtual Local Area Network [B-VLAN] Identifier (B-VID): A Virtual Local Area Network (VLAN) Identifier (VID) conveyed in a B-VLAN tag (B-TAG).

3.17 Backbone Virtual Local Area Network [B-VLAN] tag (B-TAG): An Service Virtual Local Area Network (S-VLAN) tag (S-TAG) used in conjunction with Backbone Media Access Control (B-MAC) addresses.

3.18 Backbone Virtual Local Area Network (B-VLAN) tagged frames: Frames that contain a B-VLAN tag (B-TAG) immediately following the Source MAC Address field.

3.19 Base Virtual Local Area Network [VLAN] Identifier [VID] (Base VID): The identifier of a VLAN in management operations in both Shortest Path Bridging VID (SPBV) mode and Shortest Path Bridging Media Access Control (MAC) (SPBM) mode.

3.20 bit time: The duration of one bit as transferred to and from the Media Access Control (MAC).

3.21 Boundary Port: A Bridge Port attaching an Multiple Spanning Tree (MST) Bridge to a Local Area Network (LAN) that is not in the same region.

3.22 Bridge: A system that includes Media Access Control (MAC) Bridge or Virtual Local Area Network (VLAN) Bridge component functionality and that supports a claim of conformance to Clause 5 of IEEE Std 802.1Q-2014 for system behavior.

3.23 Bridge Port: A Service Access Point (SAP) that provides the Enhanced Internal Sublayer Service (EISS) to the Media Access Control (MAC) Relay Entity of a Virtual Local Area Network (VLAN) Bridge component, or that provides the Internal Sublayer Service (ISS) to the MAC Relay Entity of a MAC Bridge, and the interface stack that supports that SAP.

NOTE—See 6.1, 8.5, and IEEE Std 802.1AC.

3.24 Bridged Network: A concatenation of individual IEEE 802 Local Area Networks (LANs) interconnected by Bridges.

3.25 C-tagged service interface: The interface provided by a Provider Edge Bridge (PEB) to allow the attached customer to select between and identify service instances using the C-VID associated with transmitted and received frames.

3.26 candidate Protection Segment: In the case of M:1 Infrastructure Protection Switching (IPS), an Infrastructure Segment that can assume the role of Protection Segment.

3.27 Common and Internal Spanning Tree (CIST): The single spanning tree calculated by the Spanning Tree Algorithm and Protocol (STP) and Rapid Spanning Tree Algorithm and Protocol (RSTP) and the logical continuation of that connectivity through Multiple Spanning Tree (MST) Bridges and Regions, calculated by the Multiple Spanning Tree Algorithm and Protocol (MSTP) to ensure that all Local Area Networks (LANs) in the Bridged Network are simply and fully connected.

3.28 Common Spanning Tree (CST): The single spanning tree calculated by the Spanning Tree Algorithm and Protocol (STP), Rapid Spanning Tree Algorithm and Protocol (RSTP), and Multiple Spanning Tree Algorithm and Protocol (MSTP) to connect Multiple Spanning Tree (MST) Regions.

3.29 congestion-aware system: A Bridge component or end station conforming to the congestion notification provisions of IEEE Std 802.1Q-2014.

3.30 Congestion Controlled Flow (CCF): A sequence of frames with the same priority, that the transmitting end station treats as belonging to a single flow, using a single Reaction Point (RP) to control the transmission rate of all those frames.

3.31 Congestion Notification Domain (CND): A connected subset of the end stations and Virtual Local Area Network (VLAN) Bridges in a Virtual Bridged Network that are compatibly configured to support a Congestion Notification Priority Value (CNPV).

3.32 Congestion Notification Message (CNM): A message transmitted by a Congestion Point (CP) to a Reaction Point (RP), in response to a frame received from that RP, conveying congestion information used by the RP to reduce its transmission rate.

3.33 Congestion Notification Priority Value (CNPV): A value of the priority parameter that a congestion-aware system uses to support congestion notification.

3.34 Congestion Notification Tag (CN-TAG): A tag that conveys a Flow Identifier (ID), that a Reaction Point (RP) can add to transmitted Congestion Controlled Flow (CCF) frames, and that a Congestion Point (CP) includes in a Congestion Notification Message (CNM).

3.35 Congestion Point (CP): A Virtual Local Area Network (VLAN) Bridge or end station Port function that monitors a single queue serving one or more Congestion Notification Priority Values (CNPVs), can generate Congestion Notification Messages (CNMs), and can remove Congestion Notification Tags (CN-TAGs).

NOTE—See 31.1.1.

3.36 congruent: (A) An adjective to describe two or more paths that coincide at all points when superimposed. (B) An adjective to describe a set of trees specifying paths that coincide at all points when superimposed, for all Virtual Local Area Networks (VLANs). See also: reverse path congruent, unicast multicast congruent, downstream congruent, and symmetric.

3.37 Connectivity Fault Management (CFM): Management capabilities for detecting, verifying, and isolating connectivity failures in Virtual Bridged Networks.

3.38 Continuity Check Message (CCM): A multicast Connectivity Fault Management (CFM) protocol data unit (PDU) transmitted periodically by a Maintenance Association (MA) Endpoint (MEP) in order to ensure continuity over the MA to which the transmitting MEP belongs.

3.39 current Protection Segment: In the case of M:1 Infrastructure Protection Switching (IPS), the candidate Protection Segment that is currently assuming the role of Protection Segment.

3.40 customer: The purchaser of a service instance from a service provider.

NOTE—Certain terms in this standard, including customer and service provider, reflect common business relationships that exist among the users of equipment implemented in conformance with this standard. The use of these terms does not imply or impose any requirement on such business relationships. A customer is often a business.

3.41 Customer Backbone Port (CBP): A Backbone Edge Bridge (BEB) Port that can receive and transmit I-tagged frames for multiple customers and can assign Backbone Virtual Local Area Network (B-VLAN) Identifiers (B-VIDs) and translate Backbone Service Instance Identifier (I-SID) on the basis of the received I-SID.

3.42 Customer Bridge: A Media Access Control (MAC) Bridge or a Customer Virtual Local Area Network (C-VLAN) Bridge.

3.43 Customer Bridged Network (CBN): A network of Customer Bridges.

3.44 Customer Edge Port (CEP): A Customer Virtual Local Area Network (C-VLAN) component Port on a Provider Edge Bridge (PEB) that is connected to customer-owned equipment and receives and transmits frames for a single customer.

3.45 customer equipment: The physical embodiment of one or more customer systems.

3.46 Customer Media Access Control (C-MAC) address: A Media Access Control (MAC) address within a Customer Bridged Network (CBN) or Provider Bridged Network (PBN). C-MAC addresses are carried within an Backbone Service Instance tag (I-TAG) in a Provider Backbone Bridged Network (PBBN).

3.47 Customer Network Port (CNP): A Service Virtual Local Area Network (S-VLAN) component Port on a Provider Bridge or within a Provider Edge Bridge (PEB) that receives and transmits frames for a single customer.

3.48 customer system: A system attached to a Provider Bridged Network (PBN) but not intended by the service provider to be under the control of the service provider.

3.49 Customer Virtual Local Area Network (C-VLAN): A Virtual Local Area Network (VLAN) identified by a C-VLAN Identifier (C-VID).

3.50 Customer Virtual Local Area Network (C-VLAN) Bridge: A system comprising a single C-VLAN component implemented in accordance with Clause 5 of IEEE Std 802.1Q-2014.

3.51 Customer Virtual Local Area Network (C-VLAN) component: A Virtual Local Area Network (VLAN) Bridge component with each Port supported by an instance of the Enhanced Internal Sublayer Service (EISS) that can recognize, insert, and remove C-VLAN tags (C-TAGs).

3.52 Customer Virtual Local Area Network [C-VLAN] Identifier (C-VID): A Virtual Local Area Network (VLAN) Identifier (VID) conveyed in a C-VLAN tag (C-TAG).

3.53 Customer Virtual Local Area Network [C-VLAN] tag (C-TAG): A Virtual Local Area Network (VLAN) tag with a Tag Protocol Identification value allocated for “802.1Q Tag Protocol EtherType.”

3.54 Data Center Bridging (DCB): A set of protocols and capabilities for use in a data center environment.

3.55 data-driven and data-dependent connectivity fault management (DDCFM): Connectivity Fault Management (CFM) capabilities that facilitate detecting and isolating data-driven and data-dependent faults (DDFs) in Virtual Bridged Networks.

3.56 data-driven and data-dependent fault (DDF): A fault that is sensitive to, or caused by, particular data patterns in frames transmitted by a service user.

3.57 Decapsulator Responder (DR): An entity for decapsulating Send Frame Messages (SFMs) and sending the decapsulated frames toward destinations specified by their own destination_address field.

3.58 Designated Multiple Stream Registration Protocol [MSRP] Node (DMN): A single station on a shared medium (e.g., IEEE 802.11 or a Coordinated Shared Network (CSN)) that controls MSRP access for all other stations on that shared medium.

3.59 Domain Service Access Point (DoSAP): A member of a set of Service Access Points (SAPs) at which a Maintenance Domain is capable of offering connectivity to systems outside the Maintenance Domain. Each DoSAP provides access to an instance either of the Enhanced Internal Sublayer Service (EISS) or of the Internal Sublayer Service (ISS).

3.60 Down Maintenance Association [MA] Endpoint [MEP] (Down MEP): A MEP residing in a Bridge that receives Connectivity Fault Management (CFM) protocol data units (PDUs) from, and transmits them toward, the direction of the Local Area Network (LAN).

3.61 Down Maintenance Point [MP] (Down MP): A Maintenance Association (MA) Endpoint (MEP) or a Maintenance Domain Intermediate Point (MIP) Half Function (MHF) residing in a Bridge that receives Connectivity Fault Management (CFM) protocol data units (PDUs) from, and transmits them toward, the direction of the Local Area Network (LAN).

3.62 downlink relay port (DRP): A port of an edge relay (ER) that is capable of supporting at least one Virtual Station Interface (VSI).

3.63 downstream congruent: A phrase to describe the path for a given frame relayed by a first Bridge when that path passes through a second Bridge and is thereafter the same as the path for any other frame (assigned to the same Virtual Local Area Network (VLAN) and destined to the same station) relayed by the second Bridge.

3.64 Edge Control Protocol (ECP): A protocol that provides reliable delivery of control service data units (SDUs).

3.65 edge relay (ER): A Bridge supporting the transfer of frames between one or more downlink relay ports (DRPs) and one uplink relay port (URP).

3.66 Edge Virtual Bridging (EVB): The set of functions supporting Virtual Station Interfaces (VSIs) in Bridges and attached end stations.

3.67 Edge Virtual Bridging (EVB) Bridge: A Customer Virtual Local Area Network (C-VLAN) Bridge that supports the Virtual Station Interface (VSI) Discovery and Configuration Protocol (VDP).

3.68 Edge Virtual Bridging (EVB) station: An end station containing one or more edge relays (ERs).

3.69 Enhanced Internal Sublayer Service [EISS] Service Access Point [SAP] (EISS-SAP): An instance of the EISS.

NOTE—See 6.8.

3.70 Equal Cost Multiple Paths (ECMP): The use of multiple possible next hop choices for frames within a single service in Shortest Path Bridging Media Access Control (MAC) (SPBM) mode networks.

3.71 Equal Cost Multiple Paths [ECMP] path Maintenance Association [MA] (ECMP path MA): An MA that monitors a set, which can be complete, of equal connectivity paths between two specific endpoints as constructed by ECMP.

3.72 Equal Cost Tree (ECT): One of the shortest path trees from the root Bridge selected from alternatives with the same path costs.

3.73 Equal Cost Tree (ECT) Algorithm: A Shortest Path Tree (SPT) algorithm yielding a consistent result for a given root Bridge when run by all Bridges within an SPT Region.

3.74 Ethernet: A term that is used to refer either to the IEEE 802.3 media access method or to the IEEE 802.3 frame format.

NOTE—In many places, “Ethernet” is also used as part of a reserved term with its own specific meaning.

3.75 Ethernet Switched Path (ESP): A provisioned traffic engineered unidirectional connectivity path among two or more Customer Backbone Ports (CBPs) that extends over a Provider Backbone Bridged Network (PBBN). The path is identified by a 3-tuple <ESP-DA, ESP-SA, ESP-VID>, where ESP-DA and ESP-SA are Media Access Control (MAC) addresses and ESP-VID is a Virtual Local Area Network (VLAN) Identifier (VID) allocated to Traffic Engineering Multiple Spanning Tree Instance Identifier (TE-MSTID).

NOTE—The use of “Ethernet” in this definition does not imply that an ESP is limited to use in conjunction with IEEE Std 802.3.

3.76 Ethernet Switched Path [ESP] Virtual Local Area Network [VLAN] Identifier [VID] (ESP-VID): A VLAN Identifier (VID) associated with a special (Traffic Engineering) value of the Multiple Spanning Tree Instance Identifier (MSTID) in the Multiple Spanning Tree (MST) Configuration Table, the TE-MSTID, indicating that the VID is under the control of an external agent responsible for setting up ESPs and that learning is disabled and forwarding is enabled.

3.77 Expedited traffic: Traffic that requires preferential treatment as a consequence of jitter, latency, or throughput constraints or as a consequence of management policy.

3.78 Fault Alarm: An out-of-band signal, which can be a Simple Network Management Protocol (SNMP) Notification, that notifies a system administrator of a connectivity failure.

3.79 flow filtering tag (F-TAG): A tag with a Tag Protocol Identification value allocated for “IEEE 802.1Q Flow Filtering Tag EtherType.”

3.80 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 Equal Cost Multiple Paths (ECMP).

3.81 Flow Identifier [ID] (Flow ID): An ID assigned by a congestion-aware end station, unique within the scope of one or more of the source Media Access Control (MAC) addresses used by that system to transmit Congestion Controlled Flow (CCF) frames.

3.82 forced switch (FS): An administrative command to force the backbone service instances assigned to a Traffic Engineering (TE) protection group to be carried by this group's protection entity.

3.83 forward path test (FPT): A test to determine whether a data frame that matches the specified filter condition can reach a specific location within a network.

3.84 Frame: A unit of data transmission on an IEEE 802 Local Area Network (LAN) that conveys a Media Access Control (MAC) Protocol Data Unit (MPDU).

3.85 Frame relay: Forwarding of frames between the Ports of a Bridge.

3.86 Group: An association of

a) A group Media Access Control (MAC) address

b) A set of properties that define membership characteristics

c) A set of properties that define the forwarding/filtering behavior of a Bridge with respect to frames destined for members of that group MAC address

with a set of end stations that all wish to receive information destined for that group MAC address.

NOTE—An example of the information that Group members might wish to receive is a multicast video data stream.

3.87 GroupID: A service instance identifier used in Virtual Station Interface (VSI) Discovery and Configuration Protocol (VDP).

3.88 I-component (I-Comp): A Service Virtual Local Area Network (S-VLAN) component with one or more Provider Instance Ports (PIPs).

3.89 I-DEI field: A field of the Backbone Service Instance tag (I-TAG) that indicates the drop eligibility of a frame in a backbone service instance.

3.90 I-PCP field: A field of the Backbone Service Instance tag (I-TAG) that indicates the priority of a frame in a backbone service instance.

3.91 I-SID field: A field of the Backbone Service Instance tag (I-TAG) that identifies the backbone service instance of a frame.

3.92 I-tagged frame: A frame that contains a Backbone Service Instance tag (I-TAG) immediately following the Source MAC Address field.

3.93 IEEE 802 Local Area Network [LAN] (IEEE 802 LAN): LAN technologies that provide a Media Access Control (MAC) Service equivalent to the MAC Service defined in IEEE Std 802.1AC. IEEE 802 LANs include IEEE 802.3 (Ethernet) and IEEE 802.11 (Wireless) LANs.

NOTE—The term “Local Area Network” and the abbreviation LAN are used exclusively to refer to an individual LAN specified by a MAC technology, without the inclusion of Bridges. This precise use of terminology within this specification allows a Bridged Network to be distinguished from an individual LAN that has been bridged to other LANs in the network (a bridged LAN). In more general usage, such precise terminology is not required, as it is an explicit goal of this standard that Bridges are transparent to the users of the MAC Service.

3.94 Independent Virtual Local Area Network [VLAN] Learning (IVL): Configuration and operation of the Learning Process and the Filtering Database (FDB) such that, for a given set of VLAN Identifiers (VIDs), if a given individual Media Access Control (MAC) Address is learned in association with one VID, that learned information is not used in forwarding decisions taken for that address relative to any other VID in the given set.

NOTE—In a Bridge that supports only IVL operation, the “given set of VIDs” is the set of all VIDs.

3.95 Independent Virtual Local Area Network [VLAN] Learning [IVL] Bridge (IVL Bridge): A Bridge that supports only IVL.

3.96 Infrastructure Protection Group (IPG): In the case of 1:1 Infrastructure Protection Switching (IPS), a set comprising a Working Segment and a Protection Segment or, in the case of M:1 IPS, a set comprising a Working Segment and one or more Protection Segments.

3.97 Infrastructure Protection Switching (IPS): The switching of a selected group of Traffic Engineering service instances (TESIs) from a Working Segment to a Protection Segment or from a Protection Segment to a Working Segment due to failure of connectivity, restoration of connectivity, or administrative command.

3.98 Infrastructure Segment: A sequence of Provider Network Ports (PNPs) and the intervening Local Area Networks (LANs) and Bridge relay entities.

3.99 Intermediate Service Access Point (ISAP): A Service Access Point (SAP), interior to a Maintenance Domain, through which frames can pass in transit from Domain Service Access Point (DoSAP) to DoSAP.

3.100 Internal Spanning Tree (IST): The connectivity provided by the Common and Internal Spanning Tree (CIST) within a Multiple Spanning Tree (MST) Region.

3.101 Internal Sublayer Service (ISS) Service Access Point (ISS-SAP): An instance of the ISS.

NOTE—See IEEE Std 802.1AC.

3.102 latency: The delay experienced by a frame in the course of its propagation between two points in a network, measured from the time that a known reference point in the frame passes the first point to the time that the reference point in the frame passes the second point.

NOTE—Latency is sometimes referred to as frame delay.

3.103 Layer Management Interface (LMI): An interface used for carrying management controls, counters, status parameters, or event indications that are not communicated to an entity's peers.

NOTE—This is not one of the Service Access Points (SAPs) defined in this standard.

3.104 Legacy region: A set of Local Area Networks (LANs) connected such that there is physical connectivity between any pair of LANs using only Media Access Control (MAC) Bridges.

NOTE—If, in a Bridged Network containing both MAC Bridges and Virtual Local Area Network (VLAN) Bridges, all VLAN Bridges were to be removed, the result would be one or more Bridged Networks, each with its own distinct spanning tree. Each of those networks is a legacy region.

3.105 Link status notification: Notification of the status of a Local Area Network (LAN) by transmitting a frame conveying information about the MAC_Operational parameter associated with the LAN.

3.106 Linktrace Message (LTM): A Connectivity Fault Management (CFM) protocol data unit (PDU) initiated by a Maintenance Association (MA) Endpoint (MEP) to trace a path to a target Media Access Control (MAC) address, forwarded from Maintenance Domain (MD) Intermediate Point (MIP) to MIP, up to the point at which the LTM reaches its target, a MEP, or can no longer be forwarded.

3.107 Linktrace Output Multiplexer (LOM): A Connectivity Fault Management (CFM) shim that enables the Linktrace Responder to forward Linktrace Messages (LTMs) out of a specific Bridge Port without passing the LTMs through the Frame filtering entity.

3.108 Linktrace Reply (LTR): A unicast Connectivity Fault Management (CFM) protocol data unit (PDU) sent by an Maintenance Point (MP) to a Maintenance Association (MA) Endpoint (MEP), in response to receiving a Linktrace Message (LTM) from that MEP.

3.109 Listener: The end station that is the destination, receiver, or consumer of a stream.

3.110 Loopback Message (LBM): A unicast Connectivity Fault Management (CFM) protocol data unit (PDU) transmitted by a Maintenance Association (MA) Endpoint (MEP), addressed to a specific Maintenance Point (MP), in the expectation of receiving a Loopback Reply (LBR).

3.111 Loopback Reply (LBR): A unicast Connectivity Fault Management (CFM) protocol data unit (PDU) transmitted by an Maintenance Point (MP) to a Maintenance Association (MA) Endpoint (MEP), in response to a Loopback Message (LBM) received from that MEP.

3.112 Maintenance Association Identifier (MAID): An identifier for a Maintenance Association (MA), unique over the domain that Connectivity Fault Management (CFM) is to protect against the accidental concatenation of service instances. The MAID has two parts: the Maintenance Domain Name and the Short MA Name.

3.113 Maintenance Association (MA): A set of MA Endpoints (MEPs), each configured with the same Maintenance Association Identifier (MAID) and Maintenance Domain (MD) Level, established to verify the integrity of a single service instance. Equivalently, an MA is the closure of the Maintenance Entities among a set of MEPs so configured.

3.114 Maintenance Association [MA] Endpoint [MEP] Identifier [ID] (MEPID): A small integer, unique over a given MA, identifying a specific MEP.

3.115 Maintenance Association [MA] Endpoint (MEP): An actively managed Connectivity Fault Management (CFM) entity, associated with a specific Domain Service Access Point (DoSAP) of a service instance, which can generate and receive CFM protocol data units (PDUs) and track any responses. It is an endpoint of a single MA and is an endpoint of a separate Maintenance Entity for each of the other MEPs in the same MA.

3.116 Maintenance Association [MA] Endpoint [MEP] Continuity Check Message [CCM] Database (MEP CCM Database): A database, maintained by every MEP, that maintains received information about other MEPs in the MA.

3.117 Maintenance Domain: The network or the part of the network for which faults in connectivity can be managed. The boundary of a Maintenance Domain is defined by a set of Domain Service Access Points (DoSAPs), each of which can become a point of connectivity to a service instance.

3.118 Maintenance Domain Intermediate Point (MIP): A Connectivity Fault Management (CFM) entity consisting of two MIP Half Functions (MHFs).

3.119 Maintenance Domain Intermediate Point [MIP] Continuity Check Message [CCM] Database (MIP CCM Database): A database, maintained optionally by a MIP or Maintenance Association (MA) Endpoint (MEP), that maintains received information about the MEPs in the Maintenance Domain.

3.120 Maintenance Domain Intermediate Point [MIP] Half Function (MHF): A Connectivity Fault Management (CFM) entity, associated with a single Maintenance Domain, and thus with a single Maintenance Domain Level (MD Level) and a set of Virtual Local Area Network (VLAN) Identifiers (VIDs), that can generate CFM protocol data units (PDUs), but only in response to received CFM PDUs.

3.121 Maintenance Domain Level (MD Level): A small integer in a field in a Connectivity Fault Management (CFM) protocol data unit (PDU) that is used, along with the Virtual Local Area Network (VLAN) Identifier (VID) in the VLAN tag, to identify to which Maintenance Domain among those associated with the CFM frame's VID, and thus to which Maintenance Association (MA), a CFM PDU belongs.

3.122 Maintenance Domain Name: The identifier, unique over the domain that Connectivity Fault Management (CFM) is to protect against accidental concatenation of service instances, of a particular Maintenance Domain.

3.123 Maintenance Entity: A point-to-point relationship between two Maintenance Association (MA) Endpoints (MEPs) within a single MA.

3.124 Maintenance Point (MP): One of either a Maintenance Association (MA) Endpoint (MEP) or a Maintenance Domain Intermediate Point (MIP).

3.125 Maintenance Point (MP) Level Demultiplexer: The component of an MP that separates Connectivity Fault Management (CFM) protocol data units (PDUs) at different Maintenance Domain Levels (MD Levels).

3.126 Maintenance Point (MP) Multiplexer: A component of an MP that merges frames from more than one input Service Access Point (SAP), sending them to a single output SAP.

3.127 Maintenance Point (MP) OpCode Demultiplexer: A component of an MP that identifies and separates Connectivity Fault Management (CFM) protocol data units (PDUs) with different values of the OpCode field.

3.128 Maintenance Point (MP) Type Demultiplexer: A component of an MP that identifies and separates Connectivity Fault Management (CFM) protocol data units (PDUs) based on the Length/Type field.

3.129 manual switch: An administrative command to move the backbone service instances assigned to a Traffic Engineering (TE) protection group to a specific TE service instance (TESI) associated with this TE protection group in absence of signal failures on both of the entities in the group.

3.130 Media Access Control (MAC) Bridge: A Bridge, implemented in accordance with Clause 5 of IEEE Std 802.1Q-2014, that does not recognize Virtual Local Area Network (VLAN) tagged frames.

3.131 Media Access Control (MAC) Bridge component: The media access method-independent functionality supporting an instance of the Internal Sublayer Service (ISS) at each Bridge Port and the functionality that relays frames between Bridge Ports.

3.132 Media Access Control (MAC) Bridged Network: A concatenation of individual IEEE 802 Local Area Networks (LANs) interconnected by MAC Bridges.

3.133 Media Access Control (MAC) status notification: A layer management interaction with an underlying MAC Service to change the status of the MAC_Operational parameter in a Bridge that is a peer user of that service.

3.134 Media Access Control (MAC) status propagation: The process of communicating a MAC_Operational parameter value through one or more Two-Part MAC Relays (TPMRs), using link status notification, MAC status notification, or both.

3.135 Multi-Topology (MT): One of a set of independent topologies that the Intermediate System to Intermediate System (IS-IS) Protocol supports within an IS-IS domain.

3.136 Multi-Topology Identifier (MTID): The identifier of an Intermediate System to Intermediate System (IS-IS) Protocol Multi-Topology (MT).

3.137 Multicast:

a) A group Media Access Control (MAC) address (noun).

b) To transmit a frame using a group MAC address as the destination address (verb).

c) Containing a group MAC address as the destination address (adjective).

3.138 Multiple Spanning Tree Instance (MSTI): One of a number of spanning trees calculated by the Multiple Spanning Tree Algorithm and Protocol (MSTP) within a Multiple Spanning Tree (MST) Region.

3.139 Multiple Spanning Tree (MST) Bridge: A Bridge capable of supporting the Common Spanning Tree (CST), and one or more Multiple Spanning Tree Instances (MSTIs), and of selectively mapping frames classified in any given Virtual Local Area Network (VLAN) to the CST or a given MSTI.

3.140 Multiple Spanning Tree [MST] Configuration Identifier (MCID): A name for, revision level, and a summary of a given allocation of Virtual Local Area Networks (VLANs) to spanning trees.

NOTE—Each MST Bridge uses a single MST Configuration Table and Configuration Identifier.

3.141 Multiple Spanning Tree (MST) Configuration Table: A configurable table that allocates each and every possible Virtual Local Area Network (VLAN) Identifier (VID) to the Common Spanning Tree (CST) or a specific Multiple Spanning Tree Instance (MSTI).

3.142 Multiple Spanning Tree (MST) Region: One or more MST Bridges with the same MST Configuration Identifiers (MCIDs), interconnected by and including Local Area Networks (LANs) for which one of those Bridges is the Designated Bridge for the Common and Internal Spanning Tree (CIST) and that have no Bridges attached that cannot receive and transmit Rapid Spanning Tree (RST) Bridge Protocol Data Units (BPDUs).

3.143 Multiple Stream Registration Protocol (MSRP): A protocol designed to provide quality of service (QoS) for streams in bridged networks by reserving resources within each Bridge along the streams' paths.

3.144 Operations, Administration, and Maintenance (OAM): A group of network management functions that provide network fault indication, performance information, and data and diagnosis functions.

NOTE—Examples are ATM OAM ITU-T I.610 (02/1999) [B43] $^{12}$ and IEEE 802.3-2012 Clause 57 OAM.

3.145 operator: (A) A provider of a single network of Provider Bridges or a single Layer 2 or Layer 3 backbone network to the service provider. (B) An enumeration of a state machine event. (C) A symbol denoting a mathematical operation.

NOTE 1—(A) An operator can, in fact, be identical to, or a part of the same organization as, the service provider, but for the purposes of this standard, the operator and service provider are presumed to be separate organizations.

NOTE 2—(A) Certain terms in this standard, including “customer,” “service provider,” and “operator,” reflect common business relationships that often exist among organizations and individuals that use equipment implemented in accordance with this standard. Terms such as “customer VID” or “operator MD Level” are no more than convenient labels for entities defined here; their use does not imply any requirement upon the business relationships among vendors or users of devices compliant with this standard.

3.146 Owner: A user of a system (and in particular, a Bridge) who has full access to the System Group of the SNMPv2-MIB (IETF RFC 3418).

3.147 Passive Service Access Point [SAP] (Passive SAP): The SAP, bounding an Maintenance Point (MP), that is on the side of the MP away from the monitored Maintenance Association (MA).

3.148 Paused state: A state of a queue in which the transmission selection entity does not select frames from the queue.

3.163 Provider Access Port (PAP): A Port-mapping Service Virtual Local Area Network (S-VLAN) component port within a Provider Edge Bridge (PEB) that receives and transmits frames for a single customer [single S-VLAN Identifier (S-VID)].

3.149 point-to-multipoint Ethernet Switched Path [ESP] (point-to-multipoint ESP): An ESP among one root Customer Backbone Port (CBP) and n leaf CBPs.

3.164 Provider Backbone Bridge (PBB): A Backbone Core Bridge (BCB) or a Backbone Edge Bridge (BEB).

3.150 point-to-multipoint Traffic Engineering service instance [TESI] (point-to-multipoint TESI): A TESI supported by a set of Ethernet Switched Paths (ESPs) that comprises one point-to-multipoint ESP from a root to n leaves plus a point-to-point ESP from each of the leaves to the root.

3.165 Provider Backbone Bridge Traffic Engineering (PBB-TE) Region: A contiguous set of combined I type and B type Backbone Edge Bridges (IB-BEBs) and Backbone Core Bridges (BCBs) that implement the capabilities defined in 25.10 of IEEE Std 802.1Q-2014.

3.151 point-to-point Ethernet Switched Path [ESP] (point-to-point ESP): An ESP between two Customer Backbone Ports (CBPs). The ESP-DA and the ESP-SA in the ESP's 3-tuple identifier are the individual Media Access Control (MAC) addresses of the two CBPs.

3.166 Provider Backbone Bridged Network (PBBN): A network using Backbone Edge Bridges (BEBs) and Backbone Core Bridges (BCBs) to interconnect Provider Bridged Networks (PBNs) and other networks.

3.152 point-to-point Traffic Engineering service instance [TESI] (point-to-point TESI): A TESI supported by two point-to-point Ethernet Switched Paths (ESPs) where the ESPs' endpoints have the same Customer Backbone Port (CBP) Media Access Control (MAC) addresses.

3.167 Provider Bridge: A Provider Edge Bridge (PEB) or a Service Virtual Local Area Network (S-VLAN) Bridge.

3.153 Port: A Service Access Point (SAP) and the interface stack supporting that SAP.

3.168 Provider Bridged Network (PBN): A network using Provider Bridges to offer customer protocol transparent connectivity.

3.154 Port State: One of a number of possible combinations of forwarding and learning variables, used by a spanning tree protocol or Shortest Path Tree (SPT) protocol for each tree for each Bridge Port, to enforce the active topology of that tree.

3.169 Provider Edge Bridge (PEB): A system comprising one or more Service Virtual Local Area Network (S-VLAN) components and one or more Customer Virtual Local Area Network (C-VLAN) components implemented in accordance with Clause 5 of IEEE Std 802.1Q-2014.

3.155 Port-based service interface: The interface provided by a Provider Bridge that associates all customer frames with a single service instance.

3.170 Provider Edge Port (PEP): A Customer Virtual Local Area Network (C-VLAN) component Port within a Provider Edge Bridge (PEB) that connects to a Customer Network Port (CNP) and receives and transmits frames for a single customer.

3.156 Port-mapping Service Virtual Local Area Network [S-VLAN] component (Primary S-VLAN component): An S-VLAN component with one externally accessible port and one or more additional ports, each connected to another Bridge component via an internal Local Area Network (LAN), and for which each registered S-VLAN Identifier's (S-VID's) member set includes the externally accessible port and exactly one other port.

3.171 Provider Instance Port (PIP): The set of Virtual Instance Ports (VIPs) that are supported by a single instance of the Internal Sublayer Service (ISS).

NOTE—See 6.14.

3.172 Provider Network Port (PNP): A Service Virtual Local Area Network (S-VLAN) component Port on a Provider Bridge that can transmit and receive frames for multiple customers.

3.157 Primary Virtual Local Area Network [VLAN] Identifier [VID] (Primary VID): The VID, among a list of VIDs associated with a service instance, on which all Connectivity Fault Management (CFM) protocol data units (PDUs) generated by Maintenance Points (MPs) except for forwarded Linktrace Messages (LTMs) are to be transmitted.

3.173 Rapid Spanning Tree (RST) Bridge: A Bridge capable of supporting only a single spanning tree, the Common Spanning Tree (CST), by the Rapid Spanning Tree Algorithm and Protocol (RSTP), defined in Clause 13 of IEEE Std 802.1Q-2014.

3.158 Priority-tagged frame: A tagged frame whose tag header carries priority information but carries no Virtual Local Area Network (VLAN) identification information.

3.174 Reaction Point (RP): An end station port function that controls the transmission rate of frames for one or more Congestion Controlled Flows (CCFs).

3.159 Protection Segment: An Infrastructure Segment associated with an Infrastructure Protection Group (IPG) that can carry Traffic Engineering service instance (TESI) traffic when the Working Segment associated with that IPG has failed or when directed by administrative command.

3.160 protocol group database: Specifies a group of protocols by assigning a unique protocol group identifier to all protocols of the same group.

3.161 protocol group identifier: Designates a group of protocols that are associated together when assigning a Virtual Local Area Network (VLAN) Identifier (VID) to a frame.

3.162 protocol template: A tuple of values that specify a data-link encapsulation format and an identification of the protocol layer above the data-link layer.

NOTE—See 31.2.2.2.

3.175 Reflected Frame Message (RFM): A Connectivity Fault Management (CFM) protocol data unit (PDU) transmitted by a Reflection Responder (RR) in order to perform forward path test (FPT).

3.176 Reflection Responder (RR): An entity that encapsulates and reflects selected data frames to a target location and allows a copy of each reflected frame to continue to its destination without encapsulation.

3.177 Reflective relay: A mode of operation of the active topology enforcement function in which a received frame on a port that supports reflective operation can be forwarded on the same port on which it was received.

3.178 Remote Customer Access Port (RCAP): A Port-mapping Service Virtual Local Area Network (S-VLAN) component port on a Provider Edge Bridge (PEB) that is intended to be directly connected to another Provider Bridged Network (PBN) under a different administration, and receives and transmits frames for one or more customers.

3.179 return path test (RPT): A test to determine if a data frame can be sent without error from a specific location within a network to a station specified by the destination_address field of the data frame.

3.180 reverse path congruent: A phrase to describe two paths where a unicast frame traverses exactly the same Bridges and Local Area Networks (LANs) along the path from the source to the destination, but in the reverse order as a frame transmitted from that destination to the source.

3.181 rooted-multipoint: A service instance in which each Service Access Point (SAP) is either a Root or a Leaf, and a Data.Request at a Leaf does not result in a Data.Indication at any other Leaf.

NOTE—See 6.2.1 and F.1.3.2.

3.182 S-channel: A point-to-point Service Virtual Local Area Network (S-VLAN) established between a Port-mapping S-VLAN component in an Edge Virtual Bridging (EVB) Bridge and a Port-mapping S-VLAN component in an EVB station.

3.183 S-channel Access Port (CAP): The Port that terminates an S-channel.

3.184 S-channel Discovery and Configuration Protocol (CDCP): A protocol that is used to configure Service Virtual Local Area Network (S-VLAN) components to create S-channels.

3.185 S-tagged service interface: The interface provided by a Provider Bridge to allow the attached customer to select between and identify service instances using the Service Virtual Local Area Network (S-VLAN) Identifier (S-VID) associated with transmitted and received frames.

3.186 Segment Endpoint Bridge (SEB): A Provider Backbone Bridge (PBB) at the endpoint of an Infrastructure Segment.

3.187 Segment Endpoint Port (SEP): A Provider Network Port (PNP) at the endpoint of an Infrastructure Segment.

3.188 Segment Identifier (SEG-ID): A pair of Segment Monitoring Path Identifiers (SMP-IDs) specifying the identity of an Infrastructure Segment.

3.189 Segment Intermediate Bridge (SIB): A Provider Backbone Bridge (PBB) having an intermediate position within an Infrastructure Segment.

3.190 Segment Intermediate Port (SIP): A Provider Network Port (PNP) having an intermediate position within an Infrastructure Segment.

3.191 Segment Monitoring Path (SMP): A unidirectional path carrying Connectivity Fault Management (CFM) traffic associated with the monitoring of an Infrastructure Segment.

3.192 Segment Monitoring Path Identifier (SMP-ID): A 3-tuple <SMP-DA, SMP-SA, SMP-VID> where the SMP-DA is the Media Access Control (MAC) address of the destination Provider Network Port (PNP) of the Segment Monitoring Path (SMP), the SMP-SA is the MAC address of the origin PNP of the SMP, and SMP-VID is a Virtual Local Area Network (VLAN) Identifier (VID) allocated to the Traffic Engineering Multiple Spanning Tree Instance Identifier (TE-MSTID) and associated with the SMP.

NOTE—See 8.9.

3.193 Send Frame Message (SFM): A Connectivity Fault Management (CFM) protocol data unit (PDU) destined to a Decapsulator Responder (DR) in order to perform return path test (RPT).

3.194 Send Frame Message (SFM) Originator: A function on a Bridge interface, an end station, or a test equipment to send SFM encapsulated data frames.

3.195 Service Access Point (SAP): The point at which a service is offered.

NOTE—In this standard, an instance of either the Internal Sublayer Service (ISS) (IEEE Std 802.1AC) or the Enhanced Internal Sublayer Service (EISS) (6.8). This term is used in place of the awkward “ISS Service Access Point” or “EISS Service Access Point,” where no loss of clarity is introduced.

3.196 service frame: A Local Area Network (LAN) frame exchanged between a provider and a customer.

3.197 service instance: A set of Service Access Points (SAPs) such that a Data.Request primitive presented to one SAP can result in a Data.Indication primitive occurring at one or more of the other SAPs in that set.

NOTE—In general, a service provider can use a number of technologies to support a service instance; within this standard, a service instance is supported by a single Service Virtual Local Area Network (S-VLAN).

3.198 service provider: An organization that contracts to provide one or more service instances to a customer.

3.199 Service Virtual Local Area Network (S-VLAN): A Virtual Local Area Network (VLAN) identified by an S-VLAN Identifier (S-VID).

3.200 Service Virtual Local Area Network (S-VLAN) Bridge: A system comprising a single S-VLAN component implemented in accordance with Clause 5 of IEEE Std 802.1Q-2014.

3.201 Service Virtual Local Area Network (S-VLAN) component: A Virtual Local Area Network (VLAN) Bridge component with each Port supported by an instance of the Enhanced Internal Sublayer Service (EISS) that can recognize, insert, and remove S-VLAN tags (S-TAGs).

3.202 Service Virtual Local Area Network [S-VLAN] Identifier (S-VID): A Virtual Local Area Network (VLAN) Identifier (VID) conveyed in an S-VLAN tag (S-TAG).

3.203 Service Virtual Local Area Network [S-VLAN] tag (S-TAG): A Virtual Local Area Network (VLAN) tag with a Tag Protocol Identification value allocated for “802.1Q Service Tag EtherType.”

3.204 Shared Virtual Local Area Network [VLAN] Learning (SVL): Configuration and operation of the Learning Process and the Filtering Database (FDB) such that, for a given set of VLANs, if an individual Media Access Control (MAC) Address is learned in one VLAN, that learned information is used in forwarding decisions taken for that address relative to all other VLANs in the given set.

NOTE—In a Bridge that supports only SVL operation, the “given set of VLANs” is the set of all VLANs.

3.205 Shared Virtual Local Area Network [VLAN] Learning [SVL] Bridge (SVL Bridge): A type of Bridge that supports only SVL.

3.206 Shared Virtual Local Area Network [VLAN] Learning [SVL]/Independent VLAN Learning [IVL] Bridge (SVL/IVL Bridge): A type of Bridge that simultaneously supports both SVL and IVL.

3.207 shim: A protocol entity that uses the same service as it provides.

NOTE—Within this standard, shims make use of the Internal Sublayer Service (ISS) or the Enhanced Internal Sublayer Service (EISS).

3.208 Short Maintenance Association [MA] Name (Short MA Name): The part of the Maintenance Association Identifier (MAID) that is unique within the Maintenance Domain and is appended to the Maintenance Domain Name to form the MAID.

3.209 Shortest Path Bridging (SPB): The method of bridging using Shortest Path Trees (SPTs) for forwarding from each Bridge. SPB is used for references that are applicable to all modes of SPB: Shortest Path Bridging Media Access Control (MAC) (SPBM) mode and Shortest Path Bridging Virtual Local Area Network (VLAN) Identifier (VID) (SPBV) mode.

3.210 Shortest Path Bridging Media Access Control [MAC] [SPBM] mode (SPBM mode): The Shortest Path Bridging (SPB) method where all Shortest Path Trees (SPTs) are rooted at a Backbone Edge Bridge (BEB). In frames with a group destination address, the SPT is identified by a destination MAC address derived from the SPSourceID; in frames with an individual address, the SPT is identified by a MAC address of the source BEB. This method does not use learning.

3.211 Shortest Path Bridging Media Access Control [MAC] [SPBM] mode Maintenance Association [MA] (SPBM MA): An MA for monitoring and diagnosing connectivity associated with a Virtual Local Area Network (VLAN) Identifier (VID) assigned to the SPBM Multiple Spanning Tree Instance Identifier (MSTID). There are three types of SPBM MA—SPBM VID MAs, SPBM path MAs, and SPBM group MAs.

NOTE—See 27.18.1.

3.212 Shortest Path Bridging Media Access Control [MAC] [SPBM] mode Virtual Local Area Network [VLAN] Identifier [VID] (SPBM VID): A VID associated with the SPBM-MSTID value of the Multiple Spanning Tree Instance Identifier (MSTID) in the Multiple Spanning Tree (MST) Configuration Table.

3.213 Shortest Path Bridging Virtual Local Area Network [VLAN] Identifier [VID] [SPBV] mode (SPBV mode): The Shortest Path Bridging (SPB) method where Shortest Path VLAN Identifiers (SPVIDs) are used to identify the Shortest Path Trees (SPTs) for individual and group addresses. This method is learning capable.

3.214 Shortest Path First (SPF): Abbreviation for the Dijkstra Shortest Path First Algorithm that is used in link state protocols such as Intermediate System to Intermediate System (IS-IS) Protocol.

3.215 Shortest Path Source Identifier (SPSourceID): A 20-bit identifier of a Bridge that is unique within a Shortest Path Tree (SPT) Domain. SPSourceID is used to auto-create SPT Domain significant group Media Access Control (MAC) addresses utilizing the local address bit in Shortest Path Bridging MAC (SPBM) mode.

NOTE—See 27.10.

3.216 Shortest Path Tree (SPT) Bridge: A Virtual Local Area Network (VLAN) Bridge capable of operating Shortest Path Bridging (SPB) protocols.

3.217 Shortest Path Tree (SPT) Domain: A set of SPT Bridges that are interconnected by Local Area Networks (LANs) and have the same configured Intermediate System to Intermediate System (IS-IS) Protocol area address. An SPT Domain contains one or more SPT Regions, each comprising some or all of the Bridges in the Domain.

3.218 Shortest Path Tree (SPT) Region: A set of Local Area Networks (LANs) and SPT Bridges interconnected via Ports on those SPT Bridges, where each LAN's Common and Internal Spanning Tree (CIST) Designated Bridge is an SPT Bridge, and each Port is either the Designated Port on one of the LANs or else a non-Designated Port of an SPT Bridge that is connected to one of the LANs, whose Multiple Spanning Tree (MST) Configuration Identifier (MCID) matches exactly the MCID or the Auxiliary MCID of the Designated Bridge of that LAN.

NOTE—See 27.4.1.

3.219 Shortest Path Tree (SPT) Set: A set of SPTs determined by one Equal Cost Tree (ECT) Algorithm and capable of supporting one or more Virtual Local Area Networks (VLANs) within an SPT Region. The set is the union of all the SPTs from all sources to all other Bridges using that single ECT Algorithm. A single SPT Set is created for each ECT Algorithm. Active SPT Sets are identified by their {ECT Algorithm, FID} tuples.

NOTE—See 8.9.4 and 13.6.

3.220 Shortest Path Virtual Local Area Network [VLAN] Identifier (SPVID): The identifier of both the VLAN and the Shortest Path Tree (SPT) that is used for the transmission of a tagged frame in Shortest Path Bridging VLAN Identifier (VID) (SPBV) mode.

3.221 Single Spanning Tree (SST) Bridge: A Bridge capable of supporting only a single spanning tree, the Common Spanning Tree (CST). The single spanning tree may be supported by the Spanning Tree Algorithm and Protocol (STP), defined in Clause 8 of IEEE Std 802.1D, 1998 Edition [B9], or by Rapid Spanning Tree Algorithm and Protocol (RSTP), defined in Clause 13 of IEEE Std 802.1Q-2014.

3.222 spanning tree: A simply and fully connected active topology formed from the arbitrary physical topology of connected Bridged Network components by relaying frames through selected Bridge Ports and not through others. The protocol parameters and states used and exchanged to facilitate the calculation of that active topology and to control the Media Access Control (MAC) relay function.

3.223 Spanning Tree Algorithm and Protocol (STP): The algorithm and protocol described in Clause 8 of IEEE Std 802.1D, 1998 Edition [B9].

3.224 Spanning Tree Algorithm and Protocol (STP) Bridge: A Bridge capable of supporting only a single spanning tree, the Common Spanning Tree (CST), by the STP defined in Clause 8 of IEEE Std 802.1D, 1998 Edition [B9].

3.225 Spanning Tree Bridge Protocol Data Unit (ST BPDU): A Bridge Protocol Data Unit (BPDU) specified for use by a Configuration or Topology Change Notification BPDU as described in Clause 14 of IEEE Std 802.1Q-2014.

3.226 Shortest Path Bridging (SPB) System Identifier: A unique 6-byte value for each Intermediate System to Intermediate System Protocol for Shortest Path Bridging (ISIS-SPB) capable Bridge and is equivalent to the Intermediate System to Intermediate System (IS-IS) Protocol System Identifier (ID). The System ID is used to identify unique Bridges in the topology. For IEEE Std 802.1Q-2014, this ID is the 6-byte Bridge Address.

NOTE—See 8.13.8.

3.227 Station-facing Bridge Port (SBP): A Bridge Port that supports the Edge Virtual Bridging (EVB) status parameters with an EVBMode parameter value of “EVB Bridge”.

NOTE—See 40.4.

3.228 Stream: A unidirectional flow of data (e.g., audio and/or video) from a Talker to one or more Listeners.

3.229 Stream Reservation Protocol (SRP) domain boundary port: A Port of a station that is a member of an SRP domain for a given stream reservation (SR) class and that is connected via an individual Local Area Network (LAN) to a Port of a station that either is within a different SRP domain for that SR class or is not part of any SRP domain.

NOTE—The term SRP domain is defined in 35.1.4.

3.230 Stream Reservation Protocol (SRP) domain core port: A Port of a station that is a member of an SRP domain for a given stream reservation (SR) class and that is connected, via an individual Local Area Network (LAN) that is part of the active topology, to a Port of a station that is a member of the same SRP domain for that SR class.

NOTE—The term SRP domain is defined in 35.1.4.

3.231 stream reservation (SR) class: A traffic class whose bandwidth can be reserved for audio/video (AV) traffic. A priority value is associated with each SR class. SR classes are denoted by consecutive letters of the alphabet, starting with A and continuing for up to seven classes.

3.232 StreamID: A 64-bit field that uniquely identifies a stream.

3.233 symmetric: An adjective to describe paths, trees, or sets of trees. Symmetric algorithms are used to create a set of trees that are reverse path congruent with respect to sources and destinations. Symmetric algorithms are used to create a set of trees that are unicast multicast congruent with respect to a given source. See also: reverse path congruent and unicast multicast congruent.

3.234 T-component: A Two-Port Media Access Control (MAC) Relay (TPMR) component with one Provider Instance Port (PIP).

3.235 Tag header: A header that allows priority information, and optionally, Virtual Local Area Network (VLAN) identification information, to be associated with a frame.

3.236 Tagged frame: A frame that contains a tag header immediately following the Source MAC Address field of the frame.

3.237 Talker: The end station that is the source or producer of a stream.

3.238 time-sensitive stream: A stream of data frames that are required to be delivered with a bounded latency.

3.239 traffic class: A classification used to expedite transmission of frames generated by critical or time-sensitive services. Traffic classes are numbered from zero through N-1, where N is the number of outbound queues associated with a given Bridge Port, and $1 \leq N \leq 8$ , and each traffic class has a one-to-one correspondence with a specific outbound queue for that Port. Traffic class 0 corresponds to nonexpedited traffic; nonzero traffic classes correspond to expedited classes of traffic. A fixed mapping determines, for a given priority associated with a frame and a given number of traffic classes, what traffic class will be assigned to the frame.

3.240 Traffic Engineering service instance (TESI): An instance of the Media Access Control (MAC) Service supported by a set of Ethernet Switched Paths (ESPs) and identified by Traffic Engineering service instance Identifier (TE-SID), forming a bidirectional service. A TESI is point-to-point or point-to-multipoint.

3.241 Traffic Engineering service instance Identifier (TE-SID): An identifier of the Traffic Engineering service instance (TESI) that corresponds to a series of 3-tuples <ESP-DA, ESP-SA, ESP-VID>, each one identifying one of the TESI's Ethernet Switched Paths (ESPs).

NOTE—The TE-SID is not used as a tag parameter.

3.242 Traffic Engineering (TE): The process that controls the placement of traffic demands in a network in order to optimize the resource utilization and to ensure that the quality of service (QoS) objectives for each defined class of service are met.

3.243 Traffic Engineering (TE) protection group: A group of two point-to-point Traffic Engineering service instances (TESIs) between a pair of Customer Backbone Ports (CBPs), which carries an assigned set of backbone service instances and continues to carry these backbone service instances if any one of the TESIs in the group is failed or disabled.

3.244 traffic specification (TSpec): A specification that characterizes the bandwidth that a stream can consume.

3.245 Two-Port Media Access Control [MAC] Relay (TPMR): A Bridge that has exactly two externally accessible Ports and supports a subset of the functionality of a MAC Bridge as specified in 5.15 of IEEE Std 802.1Q-2014.

3.246 Two-Port Media Access Control [MAC] Relay (TPMR) component: A MAC Bridge component with two Bridge Ports supported by an instance of the Internal Sublayer Service (ISS) as specified in 5.13 of IEEE Std 802.1Q-2014.

3.247 unicast:

a) An individual Media Access Control (MAC) address (noun).

b) To transmit a frame using an individual MAC address as the destination address (verb).

c) Containing an individual MAC address as the destination address (adjective).

3.248 unicast multicast congruent: A phrase to describe the path taken by a unicast frame to a given destination when that path is the same as the path taken by any multicast frame [assigned to the same Virtual Local Area Network (VLAN)] from that source to the same destination.

3.249 Untagged frame: A frame that does not contain a tag header immediately following the Source MAC Address field of the frame.

3.250 Up Maintenance Association [MA] Endpoint [MEP] (Up MEP): A MEP residing in a Bridge that transmits Connectivity Fault Management (CFM) protocol data units (PDUs) toward, and receives them from, the direction of the Media Access Control (MAC) Relay Entity.

3.251 Up Maintenance Point [MP] (Up MP): A Maintenance Association (MA) Endpoint (MEP) or a Maintenance Domain Intermediate Point (MIP) Half Function (MHF) residing in a Bridge that transmits Connectivity Fault Management (CFM) protocol data units (PDUs) toward, and receives them from, the direction of the Media Access Control (MAC) Relay Entity.

3.252 Uplink Access Port (UAP): A Port on a Port-mapping Service Virtual Local Area Network (S-VLAN) component that connects an Edge Virtual Bridging (EVB) Bridge with an EVB station.

3.253 uplink relay port (URP): A port of an edge relay (ER) that supports the Edge Virtual Bridging (EVB) status parameters with an EVBMode parameter value of “EVB station.”

NOTE—See 40.4.

3.254 Virtual Bridged Network: A concatenation of individual IEEE 802 Local Area Networks (LANs) interconnected by Bridges, including Virtual Local Area Network (VLAN) Bridges.

3.255 virtual edge bridge (VEB): An edge relay (ER) that requires reflective relay service to be disabled on the Station-facing Bridge Port (SBP) of the attached Bridge.

3.256 virtual edge port aggregator (VEPA): An edge relay (ER) that always forwards frames through its uplink relay port (URP) and that can make use of reflective relay service provided by the Station-facing Bridge Port (SBP) of the attached Bridge.

3.257 Virtual Instance Port (VIP): A Bridge Port on an I-component or a T-component in a Backbone Edge Bridge (BEB) that provides access to a single backbone service instance.

3.258 Virtual Local Area Network (VLAN): The closure of a set of Media Access Control (MAC) Service Access Points (MSAPs) such that a data request in one MSAP in the set is expected to result in a data indication in another MSAP in the set.

NOTE—See also 6.2.

3.259 Virtual Local Area Network (VLAN) Bridge: A system comprising a single VLAN Bridge component implemented in accordance with Clause 5 of IEEE Std 802.1Q-2014.

3.260 Virtual Local Area Network (VLAN) Bridge component: The media access method-independent functionality supporting an instance of the Enhanced Internal Sublayer Service (EISS) at each Bridge Port that can recognize, insert, and remove VLAN tags, and the functionality that relays frames between Bridge Ports.

3.261 Virtual Local Area Network (VLAN) Bridged Network: A Virtual Bridged Network.

3.262 Virtual Local Area Network (VLAN) tagged frame: A tagged frame whose tag header carries both VLAN identification and priority information.

3.263 virtual station: An end station instantiated within an Edge Virtual Bridging (EVB) station.

3.264 Virtual Station Interface (VSI): An interface to a virtual station that is attached to a downlink relay port (DRP) of an edge relay (ER).

3.265 Virtual Station Interface [VSI] Discovery and Configuration Protocol (VDP): A protocol that supports the association of a VSI with a Bridge Port.

3.266 Working Segment: The Infrastructure Segment, among the Infrastructure Segments associated with an Infrastructure Protection Group (IPG), on which Traffic Engineering service instance (TESI) traffic is carried when no connectivity failure of that segment has been detected and no administrative command is active.

4 Abbreviations

The following abbreviations are used in this standard:

<table><tr><td>ACK</td><td>acknowledgment</td></tr><tr><td>AV</td><td>audio/video</td></tr><tr><td>AVB</td><td>audio/video bridging</td></tr><tr><td>B-BEB</td><td>B type Backbone Edge Bridge</td></tr><tr><td>B-Comp</td><td>B-component</td></tr><tr><td>B-DA</td><td>Backbone Destination MAC address</td></tr><tr><td>B-DEI</td><td>B-VLAN Drop Eligible Indicator</td></tr><tr><td>B-MAC</td><td>Backbone Media Access Control</td></tr><tr><td>B-PCP</td><td>B-VLAN Priority Code Point</td></tr><tr><td>B-SA</td><td>Backbone Source MAC address</td></tr><tr><td>B-TAG</td><td>B-VLAN tag</td></tr><tr><td>B-VID</td><td>Backbone VLAN Identifier</td></tr><tr><td>B-VLAN</td><td>Backbone Virtual Local Area Network</td></tr><tr><td>BCB</td><td>Backbone Core Bridge</td></tr><tr><td>BEB</td><td>Backbone Edge Bridge</td></tr><tr><td>BNF</td><td>Backus-Naur Form</td></tr><tr><td>BPDU</td><td>Bridge Protocol Data Unit</td></tr><tr><td>BSI</td><td>backbone service instance</td></tr><tr><td>C-DA</td><td>Customer Destination MAC address</td></tr><tr><td>C-MAC</td><td>Customer Media Access Control</td></tr><tr><td>C-SA</td><td>Customer Source MAC address</td></tr><tr><td>C-TAG</td><td>C-VLAN tag</td></tr><tr><td>C-VID</td><td>Customer VLAN Identifier</td></tr><tr><td>C-VLAN</td><td>Customer Virtual Local Area Network</td></tr><tr><td>CAP</td><td>S-channel Access Port</td></tr><tr><td>CBN</td><td>Customer Bridged Network</td></tr><tr><td>CBP</td><td>Customer Backbone Port</td></tr><tr><td>CCF</td><td>Congestion Controlled Flow</td></tr><tr><td>CCM</td><td>Continuity Check Message</td></tr><tr><td>CCP</td><td>Current Congestion Point</td></tr><tr><td>CDCP</td><td>S-channel Discovery and Configuration Protocol</td></tr><tr><td>CE</td><td>customer equipment</td></tr><tr><td>CEP</td><td>Customer Edge Port</td></tr><tr><td>CFM</td><td>Connectivity Fault Management</td></tr><tr><td>CID</td><td>Company Identifier<eq>^{13}</eq>. (See also OUI.)</td></tr><tr><td>CIST</td><td>Common and Internal Spanning Tree</td></tr><tr><td>CIST-MSTID</td><td>Common and Internal Spanning Tree Multiple Spanning Tree Instance Identifier</td></tr><tr><td>CN</td><td>congestion notification</td></tr><tr><td>CN-TAG</td><td>Congestion Notification tag</td></tr><tr><td>CND</td><td>Congestion Notification Domain</td></tr><tr><td>CNM</td><td>Congestion Notification Message</td></tr><tr><td>CNP</td><td>Customer Network Port</td></tr><tr><td>CNPV</td><td>Congestion Notification Priority Value</td></tr><tr><td>CP</td><td>Congestion Point</td></tr><tr><td>CPID</td><td>Congestion Point Identifier</td></tr><tr><td>CRC</td><td>Cyclic Redundancy Check</td></tr><tr><td>CSN</td><td>Coordinated Shared Network</td></tr><tr><td>CST</td><td>Common Spanning Tree</td></tr><tr><td>DCB</td><td>Data Center Bridging</td></tr><tr><td>DCBX</td><td>Data Center Bridging eXchange protocol</td></tr><tr><td>DCCP</td><td>Datagram Congestion Control Protocol</td></tr><tr><td>DCN</td><td>data center network</td></tr><tr><td>DDCFM</td><td>data-driven and data-dependent connectivity fault management</td></tr><tr><td>DDF</td><td>data-driven and data-dependent fault</td></tr><tr><td>DEI</td><td>Drop Eligible Indicator</td></tr><tr><td>DLSDU</td><td>Data Link Service Data Unit</td></tr><tr><td>DMN</td><td>Designated MSRP Node</td></tr><tr><td>DoSAP</td><td>Domain Service Access Point</td></tr><tr><td>DR</td><td>Decapsulator Responder</td></tr><tr><td>DRP</td><td>downlink relay port</td></tr><tr><td>ECMP</td><td>Equal Cost Multiple Paths</td></tr><tr><td>ECP</td><td>Edge Control Protocol</td></tr><tr><td>ECPDU</td><td>Edge Control Protocol Data Unit</td></tr><tr><td>ECT</td><td>Equal Cost Tree</td></tr><tr><td>EISS</td><td>Enhanced Internal Sublayer Service (6.8)</td></tr><tr><td>ER</td><td>edge relay</td></tr><tr><td>ESP</td><td>Ethernet Switched Path</td></tr><tr><td>ETS</td><td>Enhanced Transmission Selection</td></tr><tr><td>EUI-48</td><td>48-bit Extended Unique Identifier14</td></tr><tr><td>EVB</td><td>Edge Virtual Bridging</td></tr><tr><td>F-TAG</td><td>flow filtering tag</td></tr><tr><td><eq>F_b</eq></td><td>Quantized Feedback</td></tr><tr><td>FCS</td><td>Frame Check Sequence</td></tr><tr><td>FDB</td><td>Filtering Database</td></tr><tr><td>FID</td><td>Filtering Identifier (8.8.8, 8.9.3)</td></tr><tr><td>FPT</td><td>forward path test</td></tr><tr><td>FQTSS</td><td>Forwarding and Queuing Enhancements for time-sensitive streams</td></tr><tr><td>FS</td><td>Forced Switch</td></tr><tr><td>I-BEB</td><td>I type Backbone Edge Bridge</td></tr><tr><td>I-Comp</td><td>I-component</td></tr><tr><td>I-DEI</td><td>Backbone Service Instance Drop Eligible Indicator</td></tr><tr><td>I-PCP</td><td>Backbone Service Instance Priority Code Point</td></tr><tr><td>I-TAG</td><td>Backbone Service Instance tag</td></tr><tr><td>I-SID</td><td>Backbone Service Instance Identifier</td></tr><tr><td>IB-BEB</td><td>combined I type and B type Backbone Edge Bridge</td></tr><tr><td>ID</td><td>identifier</td></tr><tr><td>IP</td><td>Internet Protocol</td></tr><tr><td>IPG</td><td>Infrastructure Protection Group</td></tr><tr><td>IPS</td><td>Infrastructure Protection Switching</td></tr><tr><td>IPv6</td><td>Internet Protocol version 6</td></tr><tr><td>ISAP</td><td>Intermediate Service Access Point</td></tr><tr><td>ISIS-SPB</td><td>Intermediate System to Intermediate System Protocol for Shortest Path Bridging</td></tr><tr><td>ISS</td><td>Internal Sublayer Service (IEEE Std 802.1AC)</td></tr><tr><td>IST</td><td>Internal Spanning Tree</td></tr><tr><td>ITB-BEB</td><td>any valid combination of multi-component Backbone Edge Bridge, e.g., IB-BEB</td></tr><tr><td>IVL</td><td>Independent VLAN Learning (3.94)</td></tr><tr><td>LACP</td><td>Link Aggregation Control Protocol</td></tr><tr><td>LAG</td><td>Link Aggregation Group</td></tr><tr><td>LAN</td><td>Local Area Network (IEEE Std 802)</td></tr><tr><td>LBM</td><td>Loopback Message</td></tr><tr><td>LBR</td><td>Loopback Reply</td></tr><tr><td>LLC</td><td>Logical Link Control (ISO/IEC 8802-2)</td></tr><tr><td>LLDP</td><td>Link Layer Discovery Protocol</td></tr><tr><td>LMI</td><td>Layer Management Interface</td></tr><tr><td>Local-SID</td><td>Local Service Instance Identifier</td></tr><tr><td>LOM</td><td>Linktrace Output Multiplexer</td></tr><tr><td>LoP</td><td>Lockout of Protection</td></tr><tr><td>LSB</td><td>least significant bit</td></tr><tr><td>LSP</td><td>Link State PDU</td></tr><tr><td>LTM</td><td>Linktrace Message</td></tr><tr><td>LTR</td><td>Linktrace Reply</td></tr><tr><td>MA</td><td>Maintenance Association</td></tr><tr><td>MAC</td><td>Medium Access Control (IEEE Std 802)</td></tr><tr><td>MAD</td><td>MRP Attribute Declaration</td></tr><tr><td>MAID</td><td>Maintenance Association Identifier</td></tr><tr><td>MAP</td><td>MRP Attribute Propagation</td></tr><tr><td>MCID</td><td>MST Configuration Identifier</td></tr><tr><td>MD Level</td><td>Maintenance Domain Level</td></tr><tr><td>MEP</td><td>MA Endpoint</td></tr><tr><td>MEPID</td><td>MA Endpoint Identifier</td></tr><tr><td>MHF</td><td>MIP Half Function</td></tr><tr><td>MIB</td><td>Management Information Base (Clause 17)</td></tr><tr><td>MIP</td><td>Maintenance domain Intermediate Point</td></tr><tr><td>MIRP</td><td>Multiple I-SID Registration Protocol</td></tr><tr><td>MIRPDU</td><td>Multiple I-SID Registration Protocol Data Unit</td></tr><tr><td>MMRP</td><td>Multiple MAC Registration Protocol</td></tr><tr><td>MMRPDU</td><td>Multiple MAC Registration Protocol Data Unit</td></tr><tr><td>MoCA</td><td>Multimedia over Coax Alliance</td></tr><tr><td>MP</td><td>Maintenance Point</td></tr><tr><td>MPDU</td><td>MAC Protocol Data Unit</td></tr><tr><td>MRP</td><td>Multiple Registration Protocol</td></tr><tr><td>MRPDU</td><td>Multiple Registration Protocol Data Unit</td></tr><tr><td>MS</td><td>MAC Service</td></tr><tr><td>MSAP</td><td>MAC Service Access Point</td></tr><tr><td>MSB</td><td>most significant bit</td></tr><tr><td>MSDU</td><td>MAC Service Data Unit (IEEE Std 802.1AC)</td></tr><tr><td>MSP</td><td>MAC Status Protocol or MAC status propagation</td></tr><tr><td>MSPDU</td><td>MAC Status Protocol Data Unit</td></tr><tr><td>MSPE</td><td>MAC Status Propagation Entity</td></tr><tr><td>MSRP</td><td>Multiple Stream Registration Protocol</td></tr><tr><td>MSRPDU</td><td>Multiple Stream Registration Protocol Data Unit</td></tr><tr><td>MSS</td><td>MAC Status Shim</td></tr><tr><td>MST</td><td>Multiple Spanning Tree</td></tr><tr><td>MST BPDU</td><td>Multiple Spanning Tree Bridge Protocol Data Unit</td></tr><tr><td>MSTI</td><td>Multiple Spanning Tree Instance</td></tr><tr><td>MSTID</td><td>Multiple Spanning Tree Instance Identifier</td></tr><tr><td>MSTP</td><td>Multiple Spanning Tree Algorithm and Protocol</td></tr><tr><td>MT</td><td>Multi-Topology (Note that “MT state” is used in Clause 10 for the “Empty state.”)</td></tr><tr><td>MTID</td><td>Multi-Topology Identifier</td></tr><tr><td>MVRP</td><td>Multiple VLAN Registration Protocol</td></tr><tr><td>MVRPDU</td><td>Multiple VLAN Registration Protocol Data Unit</td></tr><tr><td>NLPID</td><td>Network Layer Protocol Identifier</td></tr><tr><td>OAM</td><td>Operations, Administration, and Maintenance</td></tr></table>

<table><tr><td>OUI</td><td>organizationally unique Identifier</td></tr><tr><td>PAE</td><td>Port Access Entity</td></tr><tr><td>PAP</td><td>Provider Access Port</td></tr><tr><td>PATHID</td><td>Path Identifier</td></tr><tr><td>PB</td><td>Provider Bridge</td></tr><tr><td>PBB</td><td>Provider Backbone Bridge</td></tr><tr><td>PBB-TE</td><td>Provider Backbone Bridge Traffic Engineering</td></tr><tr><td>PBBN</td><td>Provider Backbone Bridged Network</td></tr><tr><td>PBN</td><td>Provider Bridged Network</td></tr><tr><td>PCP</td><td>Priority Code Point</td></tr><tr><td>PDU</td><td>protocol data unit</td></tr><tr><td>PFC</td><td>Priority-based Flow Control</td></tr><tr><td>PICS</td><td>Protocol Implementation Conformance Statement (Annex A, Annex B)</td></tr><tr><td>PID</td><td>Protocol Identifier</td></tr><tr><td>PIP</td><td>Provider Instance Port</td></tr><tr><td>PNP</td><td>Provider Network Port</td></tr><tr><td>PPVID</td><td>port and protocol VLAN Identifier</td></tr><tr><td>PQoS</td><td>Parameterized Quality of Service</td></tr><tr><td>PVID</td><td>port VLAN Identifier</td></tr><tr><td>QCN</td><td>Quantized Congestion Notification protocol</td></tr><tr><td>QoS</td><td>quality of service</td></tr><tr><td>RCAP</td><td>Remote Customer Access Port</td></tr><tr><td>RCSI</td><td>Remote Customer Service Interface</td></tr><tr><td>RFM</td><td>Reflected Frame Message</td></tr><tr><td>RP</td><td>Reaction Point</td></tr><tr><td>RPR</td><td>resilient packet ring</td></tr><tr><td>RPT</td><td>return path test</td></tr><tr><td>RR</td><td>Reflection Responder</td></tr><tr><td>RST</td><td>Rapid Spanning Tree</td></tr><tr><td>RST BPDU</td><td>Rapid Spanning Tree Bridge Protocol Data Unit</td></tr><tr><td>RSTP</td><td>Rapid Spanning Tree Algorithm and Protocol</td></tr><tr><td>RSVP</td><td>Resource Reservation Protocol</td></tr><tr><td>S-TAG</td><td>S-VLAN tag</td></tr><tr><td>S-VID</td><td>Service VLAN Identifier</td></tr><tr><td>S-VLAN</td><td>Service Virtual Local Area Network</td></tr><tr><td>SAP</td><td>Service Access Point</td></tr><tr><td>SBP</td><td>Station-facing Bridge Port</td></tr><tr><td>SCID</td><td>S-channel Identifier</td></tr><tr><td>SCTP</td><td>Stream Control Transmission Protocol</td></tr><tr><td>SDU</td><td>service data unit</td></tr><tr><td>SEB</td><td>Segment Endpoint Bridge</td></tr><tr><td>SEG-ID</td><td>Segment Identifier</td></tr><tr><td>SEP</td><td>Segment Endpoint Port</td></tr><tr><td>SF</td><td>Signal Fail</td></tr><tr><td>SFM</td><td>Send Frame Message</td></tr><tr><td>SIB</td><td>Segment Intermediate Bridge</td></tr><tr><td>SIP</td><td>Segment Intermediate Port</td></tr><tr><td>SMP</td><td>Segment Monitoring Path</td></tr><tr><td>SMP-ID</td><td>Segment Monitoring Path Identifier</td></tr><tr><td>SNAP</td><td>Subnetwork Access Protocol</td></tr><tr><td>SNM</td><td>Status Notification state machine</td></tr><tr><td>SNMP</td><td>Simple Network Management Protocol</td></tr><tr><td>SPB</td><td>Shortest Path Bridging</td></tr><tr><td>SPBM</td><td>Shortest Path Bridging MAC</td></tr></table>

<table><tr><td>SPBV</td><td>Shortest Path Bridging VID</td></tr><tr><td>SPF</td><td>Shortest Path First</td></tr><tr><td>SPT</td><td>Shortest Path Tree</td></tr><tr><td>SPVID</td><td>Shortest Path VLAN Identifier</td></tr><tr><td>SR</td><td>stream reservation</td></tr><tr><td>SR_PVID</td><td>Stream Reservation Port VLAN Identifier</td></tr><tr><td>SRP</td><td>Stream Reservation Protocol</td></tr><tr><td>SST</td><td>Single Spanning Tree</td></tr><tr><td>ST BPDU</td><td>Spanning Tree Bridge Protocol Data Unit</td></tr><tr><td>STM</td><td>Status Transition state machine</td></tr><tr><td>STP</td><td>Spanning Tree Algorithm and Protocol</td></tr><tr><td>SVL</td><td>Shared VLAN Learning (3.204)</td></tr><tr><td>TC</td><td>textual convention</td></tr><tr><td>TCI</td><td>Tag Control Information (9.3)</td></tr><tr><td>TCP</td><td>Transmission Control Protocol</td></tr><tr><td>TE</td><td>Traffic Engineering</td></tr><tr><td>TE-MSTID</td><td>Traffic Engineering Multiple Spanning Tree Instance Identifier</td></tr><tr><td>TE-SID</td><td>Traffic Engineering service instance Identifier</td></tr><tr><td>TESI</td><td>Traffic Engineering service instance</td></tr><tr><td>TLV</td><td>Type, Length, Value</td></tr><tr><td>TPID</td><td>Tag Protocol Identifier (9.3)</td></tr><tr><td>TPMR</td><td>Two-Port MAC Relay</td></tr><tr><td>TSpec</td><td>traffic specification</td></tr><tr><td>TTL</td><td>time-to-live</td></tr><tr><td>UAP</td><td>Uplink Access Port</td></tr><tr><td>UDP</td><td>User Datagram Protocol</td></tr><tr><td>ULP</td><td>upper layer protocol</td></tr><tr><td>ULPDU</td><td>upper layer protocol data unit</td></tr><tr><td>UNI</td><td>User Network Interface</td></tr><tr><td>URP</td><td>uplink relay port</td></tr><tr><td>UUID</td><td>Universally Unique Identifier</td></tr><tr><td>VDP</td><td>VSI Discovery and Configuration Protocol</td></tr><tr><td>VEB</td><td>virtual edge bridge</td></tr><tr><td>VEPA</td><td>virtual edge port aggregator</td></tr><tr><td>VID</td><td>VLAN Identifier (7.2, 9.3)</td></tr><tr><td>VIP</td><td>Virtual Instance Port</td></tr><tr><td>VLAN</td><td>Virtual Local Area Network</td></tr><tr><td>VSI</td><td>Virtual Station Interface</td></tr><tr><td>VSIID</td><td>VSI Instance Identifier</td></tr><tr><td>VTID</td><td>VSI Type Identifier</td></tr></table>

5 Conformance

This clause specifies the mandatory and optional capabilities provided by conformant implementations of this standard. An implementation can

a) Compose all or part of the functionality of a system;

b) Provide, as specified by this standard, one or more instances of the MAC Service to other functional entities whose specification is outside the scope of this standard;

c) Provide, as specified by this standard, one or more instances of the MAC Internal Sublayer Service (ISS) to other implementations or instances of the same implementation that conform to this standard.

Accordingly, and as detailed in 5.4, this clause specifies conformance requirements for common systems and for functional components within systems, possibly connected to other system components with interfaces that are not otherwise accessible.

5.1 Requirements terminology

For consistency with existing IEEE and IEEE 802.1 standards, requirements placed upon conformant implementations of this standard are expressed using the following terminology:

a) Shall is used for mandatory requirements;

b) May is used to describe implementation or administrative choices (“may” means “is permitted to,” and hence, “may” and “may not” mean precisely the same thing);

c) Should is used for recommended choices (the behaviors described by “should” and “should not” are both permissible but not equally desirable choices).

NOTE—The usage in 17.7 follows the IETF model.

The Protocol Implementation Conformance Statement (PICS) proformas (see Annex A for Bridges and Annex B for end station implementations) reflect the occurrences of the words “shall,” “may,” and “should” within the standard.

The standard avoids needless repetition and apparent duplication of its formal requirements by using is, is not, are, and are not for definitions and the logical consequences of conformant behavior. Behavior that is permitted but is neither always required nor directly controlled by an implementer or administrator, or whose conformance requirement is detailed elsewhere, is described by can. Behavior that never occurs in a conformant implementation or system of conformant implementations is described by cannot. The word allow is used as a replacement for the phrase “Support the ability for,” and the word capability means “can be configured to.”

5.2 Conformant components and equipment

This subclause specifies requirements and options for the following core components:

a) VLAN Bridge component (5.4);

b) MAC Bridge component (5.13);

for the following components that use that core functionality:

c) Customer VLAN (C-VLAN) component (5.5);

d) Service VLAN (S-VLAN) component (5.6);

e) I-component (5.7);

f) B-component (5.8);

g) TPMR component (5.15);

h) T-component (5.17);

i) Edge relay (ER) (5.24.1);

and for the following systems that include instances of the above components:

j) C-VLAN Bridge (5.9);

k) S-VLAN Bridge (5.10.1);

1) Provider Edge Bridge (5.10.2);

m) Backbone Edge Bridge (BEB) (5.12);

n) MAC Bridge (5.14);

o) TPMR (5.16);

p) Edge Virtual Bridging (EVB) Bridge (5.23);

q) EVB station (5.24).

NOTE—Both S-VLAN Bridges and Provider Edge Bridges are examples of Provider Bridges.

5.3 Protocol Implementation Conformance Statement (PICS)

A claim of conformance specifies implementation of a C-VLAN component, an S-VLAN component, an I-component, a B-component, or a specific system. A component or system can support multiple claims for a range of possible behaviors.

The supplier of an implementation that is claimed to conform to this standard shall provide the information necessary to identify both the supplier and the implementation, and shall complete a copy of the PICS proforma provided in Annex A for that specific Bridge component or system, or Annex B for an end station implementation, together with any further information and completed PICS(s) required to identify subcomponents.

NOTE 1—C-VLAN component and S-VLAN component PICS both require completion of a PICS for a VLAN Bridge component; the VLAN Bridge PICS requires a claim of conformance for a single C-VLAN component; the Provider Edge Bridge requires a claim of conformance for a single S-VLAN component and one or more claims for C-VLAN components.

NOTE 2—The claim of conformance that could be made to this standard for an implementation of a VLAN-aware Bridge is replaced by a claim of conformance to a VLAN Bridge. Although the current and subsequent amendment(s) or revision(s) of this standard have changed the presentation of the information, the technical requirements of conformance remain unchanged.

NOTE 3—I-component and B-component PICS both require completion of a PICS for an S-VLAN component.

5.4 VLAN Bridge component requirements

An implementation of a VLAN Bridge component shall

a) Conform to the relevant standard for the MAC technology implemented at each Port in support of the MAC ISS, as specified in IEEE Std 802.1AC;

b) Support the MAC Enhanced Internal Sublayer Service (EISS) at each Port, as specified in 6.8 and 6.9;

c) Implement an ISO/IEC 8802-2 conformant Logical Link Control (LLC) class with Type 1 operation as required by 8.2;

d) Relay and filter frames as described in 8.1 and specified in 8.5, 8.6, 8.7, and 8.8;

e) Maintain the information required to support Basic Filtering Services, as described in 6.16 and in 8.1 and specified in 8.5, 8.7, and 8.8;

f) Conform to the provisions for addressing specified in 8.13;

g) Implement Rapid Spanning Tree Algorithm and Protocol (RSTP), as specified in Clause 13;

h) Encode transmitted BPDUs and validate received BPDUs as specified in Clause 14;

i) Specify the following parameters of the implementation:

1) Filtering Database Size, the maximum number of entries;

2) Permanent Database Size, the maximum number of entries;

j) Specify the following performance characteristics of the implementation:

1) A Guaranteed Port Filtering Rate for each Bridge Port;

2) A Guaranteed Bridge Relaying Rate for the Bridge;

3) The related time intervals $T_F$ and $T_R$ for these parameters as specified in Clause 24;

k) Operation of the Bridge within the specified parameters shall not violate any of the other conformance provisions of this standard;

1) On each Port, support at least one of the permissible values for the Acceptable Frame Types parameter, as defined in 6.9;

m) Support the following on each Port that supports untagged and priority-tagged frames:

1) A Port VLAN Identifier (PVID) value (6.9);

2) Configuration of at least one VID whose untagged set includes that Port (8.8.2);

3) Configuration of the PVID value via management operations (12.10);

4) Configuration of Static Filtering Entries via management operations (12.7);

n) Allow tag headers to be inserted, modified, and removed from relayed frames, as specified in 8.1 and Clause 9, as required by the value(s) of the Acceptable Frame Types parameter supported on each Port, and by the ability of each Port to transmit VLAN-tagged and/or untagged frames;

o) Allow automatic configuration and management of VLAN topology using the Multiple VLAN Registration Protocol (MVRP) (5.4.2, Clause 11) on all Ports;

p) Allow static and dynamic configuration information for at least one VID, by means of Static and Dynamic VLAN Registration Entries in the FDB (8.11);

q) Support at least one Filtering Identifier (FID) (8.8.3, 8.8.8, 8.8.9, and IEEE Std 802.1AC);

r) Allow allocation of at least one VID to each FID that is supported (8.8.3, 8.8.8, 8.8.9, and IEEE Std 802.1AC).

NOTE—Under some circumstances, the ability for VLAN Bridges to successfully interoperate depends on the number of FIDs supported and on the number of VIDs that can be allocated to each FID. These circumstances are discussed in Annex B, along with interoperability implications.

5.4.1 VLAN Bridge component options

An implementation of a VLAN Bridge component may

a) Support MST operation (5.4.1.1);

b) Support Port-and-Protocol-based VLAN classification (5.4.1.2), including multiple VID values per port, administrative control of the values of the multiple VIDs, and a Protocol Group Database;

c) Support CFM operation (5.4.1.4);

d) Support Shortest Path Bridging (SPB) operation (5.4.5);

e) Support congestion notification (5.4.3);

f) Support Priority-based Flow Control (PFC) (5.11);

g) Support Extended Filtering Services (6.16.5) and the operation of Multiple MAC Registration Protocol (MMRP, 10.9) to support automatic configuration and management of MAC address information on all Ports (5.4.1.3);

h) Allow the FDB to contain Static and Dynamic VLAN Registration Entries (8.8) for more than one VID, up to a maximum of 4094 VIDs;

i) Allow translation of VIDs through support of the VID Translation Table or through support of both the VID Translation Table and Egress VID translation table on one or more Bridge Ports (6.9);

NOTE 1—The maximum number of VIDs that can be supported is 4094 rather than 4096, as the VID values 0 and FFF are reserved, as indicated in Table 9-2. As conformance to this standard is only with regard to externally visible protocol behavior, this limit on the number of VIDs that can be supported does not imply any such limitation with regard to the internal architecture of a Bridge.

j) On each Port, support all of the permissible values for the Acceptable Frame Types parameter, as defined in 6.9, and support configuration of the parameter value via management;

k) Support enabling and disabling of Ingress Filtering (8.6.2);

1) Allow configuration of more than one VID whose untagged set includes that Port (8.8.2);

m) Support the management functionality defined in Clause 12;

n) Support the use of a remote management protocol. Bridges claiming to support remote management shall

1) State which remote management protocol standard(s) or specification(s) are supported;

2) State which standard(s) or specification(s) for managed object definitions and encodings are supported for use by the remote management protocol;

o) Support multiple Traffic Classes for relaying and filtering frames through one or more outbound Ports, controlling the mapping of the priority of forwarded frames as specified in 6.9.4 and IEEE Std 802.1AC;

p) Support more than one FID (8.8);

q) Allow allocation of more than one VID to each supported FID (8.8, 8.8.8);

r) Allow configuration of fixed VID to FID allocations (8.8.8, 12.10.3);

s) Allow configuration of the Restricted_MAC_Address_Registration parameter (10.12.2.3) for each Port of the Bridge;

t) Support the ability to configure the value of the Restricted_VLAN_Registration parameter (11.2.3.2.3) for each Port of the Bridge;

u) Support Forwarding and Queuing Enhancements for time-sensitive streams (FQTSS) (5.4.1.5);

v) Support SMIv2 MIB modules for the management of VLAN Bridge capabilities (Clause 17);

NOTE 2—In previous versions of this standard, the MIB modules were maintained by IETF (e.g., IETF RFC 4363 for the Q-BRIDGE MIB). For this version of the standard, the relevant set of MIB modules required to manage a Bridge is contained in Clause 17.

w) Support Multiple Stream Registration Protocol (MSRP; Clause 35);

x) Support the operation of MVRP (5.4.2, 11.2) as a New-Only Participant;

y) Support the operation of MVRP (5.4.2, 11.2) as a New-Only Participant;

z) Support the MVRP extension MIB module defined in 17.7.15;

aa) Support Enhanced Transmission Selection (ETS) (5.4.1.6);

ab) Support Data Center Bridging eXchange protocol (DCBX) (5.4.1.7).

5.4.1.1 Multiple Spanning Tree (MST) operation (optional)

A VLAN Bridge implementation in conformance to the provisions of this standard for an MST Bridge (5.4.1, 8.3, 8.4, 8.6.1, 8.9, 8.10, 11.2, 11.2.3.1, Clause 13, and Clause 14) shall

a) Support MSTP as specified in Clause 13;

b) Support the Common and Internal Spanning Tree (CIST) plus a stated maximum number of Multiple Spanning Tree Instances (MSTIs), where that number is at least 2 (8.9) and at most 64 (13.14);

NOTE—In other words, a conformant MST Bridge supports a minimum of three spanning tree instances—the CIST and at least two additional MSTIs.

c) Support a stated maximum number of FIDs not less than the number of MSTIs (8.9);

d) Support the ability to associate each FID to a spanning tree (8.9.3);

e) Support the transmission and reception of MST Configuration Identifier (MCID) information (8.9.2);

f) Support a Port State for each Port for each spanning tree instance supported (8.4, 13.38);

g) Support operation of a spanning tree protocol for each spanning tree instance and Port (8.10, Clause 13);

h) Use the Bridge Group Address as specified in 8.13.3;

i) Support the default values for Bridge Forward Delay and Bridge Priority parameters specified in 13.26;

j) Support the operation of MVRP in each supported spanning tree context (11.2.3.1.1, 11.2.3.1.2);

k) Support the Bridge management functions for the Bridge protocol entity for each supported spanning tree, independently (12.8);

1) Support, in particular, management of the Bridge priority parameters, and of the port priority and path cost parameters for every port, independently for each supported spanning tree (12.8.1.1, 12.8.1.3, 13.27);

m) Support VLAN management functions for each supported spanning tree (12.10.1 and 12.11.1);

n) Support management of the MSTI configuration (12.12).

A VLAN Bridge implementation in conformance to the provisions of this standard for an MST Bridge (5.4.1, Clause 13) may

o) Support a greater number of FIDs than spanning trees (8.8.8);

p) Support SMIv2 MIB modules for the management of VLAN Bridge capabilities (Clause 17).

5.4.1.2 Port-and-Protocol-based VLAN classification (optional)

A VLAN Bridge component implementation in conformance to the provisions of this standard for Port-and-Protocol-based VLAN classification (5.4.1) shall

a) Support one or more of the following Protocol Classifications and Protocol Template formats: Ethernet, RFC_1042, SNAP_8021H, SNAP_Other, or LLC_Other (6.12);

and may

b) Support configuration of the contents of the Protocol Group Database.

5.4.1.3 Multiple MAC Registration Protocol (MMRP) operation (optional)

A Bridge implementation in conformance to the provisions of this standard for the support of MMRP shall

a) Conform to the operation of the MRP Applicant, Registrar, LeaveAll, and Periodic Transmission state machines, as defined in 10.7.7, 10.7.8, 10.7.9, and 10.7.10, as required for one or the other of the following variants of the MRP Participant, as defined in 10.6 and 10.7:

1) The Full Participant.

2) The Full Participant, point-to-point subset.

b) Exchange Multiple Registration Protocol Data Units (MRPDUs) as required by those state machines, formatted in accordance with the generic protocol data unit (PDU) format described in 10.8, and able to carry application-specific information as defined in 10.12, using the group MAC addresses reserved for use by MRP applications, as defined in Table 10-1.

c) Implement the MMRP Application component as defined in 10.12.

d) Propagate registration information in accordance with the operation of MAP for the Base Spanning Tree Context, as specified in 10.3.1.

e) Forward, filter or discard MAC frames carrying any MRP Application address as the destination MAC address in accordance with the requirements of 8.13.6.

5.4.1.4 Connectivity Fault Management (CFM) (optional)

A VLAN Bridge component implementation that conforms to the provisions of this standard for CFM (Clause 18 through Clause 22) shall

a) Support the creation of Maintenance Domains at eight Maintenance Domain Levels (MD Levels), with multiple nonoverlapping Maintenance Domains at each MD Level, using the managed objects specified in 12.14;

b) Support the creation of a Maintenance Association (MA) for each VID supported by the Bridge for each MD Level;

c) Support the creation of a single Maintenance Domain Intermediate Point (MIP) for each Maintenance Domain on each Port, all MIPs being at the same MD Level;

d) Support the creation of eight Up MA Endpoints (MEPs) for each VID on each Port, each MEP at a different MD Level;

e) Support the creation of eight Down MEPs for each VID on each Port, each MEP at a different MD Level;

f) Support the creation of eight Down MEPs attached to no VID on each Port, each MEP at a different MD Level;

g) Support the maintenance of a MEP CCM Database;

h) Provide control via all of the required managed objects specified in 12.14;

i) Conform to the state machines and procedures in Clause 20; and

j) Transmit and receive required CFM PDUs in the formats specified in Clause 21.

A VLAN Bridge component implementation that conforms to the provisions of this standard for CFM may

k) Support the creation of MIPs at different MD Levels on a single Port;

1) Support the creation of MIPs at MD Levels lower than or equal to MEPs on the same Port;

m) Support the maintenance of a MIP CCM Database in a MIP or MEP;

n) Support the CFM MIB module defined in 17.5; and/or

o) Support the creation of MAs that are associated with more than one VID (22.1.5);

p) Support the creation and operation of Reflection Responder (RR) and Reflected Frame Message (RFM) Receiver for the forward path test (FPT);

q) Support the creation and operation of Decapsulator Responder (DR) and Send Frame Message (SFM) Originator for the return path test (RPT).

5.4.1.5 Forwarding and Queuing Enhancements for time-sensitive streams (FQTSS)—requirements

A VLAN Bridge component implementation that conforms to the provisions of this standard for FQTSS shall

a) Support a minimum of two traffic classes on all Ports, of which

1) A minimum of one traffic class supports the strict priority algorithm for transmission selection (8.6.8.1), and

2) One traffic class is a stream reservation (SR) class.

b) Support the operation of the credit-based shaper algorithm (8.6.8.2) on all Ports as the transmission selection algorithm used for the SR class.

c) Support SRP domain boundary port priority regeneration override as defined in 6.9.4, and the default priority regeneration override value defined in Table 6-5, for SR class “B.”

d) Support the tables and procedures for mapping priorities to traffic classes as defined in 34.5.

A VLAN Bridge component implementation that conforms to the provisions of this standard for FQTSS may

e) Support the management entities defined in 12.20 by means of the SNMPv2 MIB module defined in 17.7.12.

f) Support two or more SR classes (a maximum of seven), and support the operation of the credit-based shaper algorithm (8.6.8.2) on all Ports as the transmission selection algorithm used for those SR classes. The number of SR classes supported shall be stated in the PICS.

g) Support SRP domain boundary port priority regeneration override as defined in 6.9.4, and the default priority regeneration override value defined in Table 6-5, for SR class “A.” If more than two SR classes are supported, the default priority regeneration override values used for the additional SR classes shall be stated in the PICS.

5.4.1.6 ETS Bridge requirements

A device supporting ETS shall

a) Support at least 3 traffic classes (37.3);

NOTE—A minimum of 3 traffic classes allows a minimum configuration such that one traffic class contains priorities with PFC enabled, one traffic class contains priorities with PFC disabled, and one traffic class using strict priority.

b) Support bandwidth configuration with a granularity of 1% or finer (37.3);

c) Support bandwidth allocation with a precision of 10% (37.3);

d) Support a transmission selection policy such that if one of the traffic classes does not consume its allocated bandwidth, then any unused bandwidth is available to other traffic classes (37.3); and

e) Support DCBX (Clause 38).

5.4.1.7 DCBX Bridge requirements

A device supporting DCBX shall

a) Support Link Layer Discovery Protocol (LLDP) transmit and receive mode (IEEE Std 802.1AB).

b) Support the DCBX ETS Configuration Type, Length, Value (TLV) (D.2.9).

c) Support the ETS Recommendation TLV (D.2.10).

d) Support the Priority-based Flow Control Configuration TLV (D.2.11).

e) Support the Application Priority TLV (D.2.12).

f) Support the asymmetric and symmetric DCBX state machines (38.4).

5.4.2 Multiple VLAN Registration Protocol (MVRP) requirements

A VLAN Bridge implementation in conformance to the provisions of this standard for the support of MVRP shall

1) The Full Participant.

2) The Full Participant, point-to-point subset.

c) Implement the MVRP Application component as defined in 11.2.

d) Propagate registration information

1) In a Single Spanning Tree (SST) Bridge, in accordance with the operation of MAP for the Base Spanning Tree Context, as specified in 10.3 and 10.3.1; or

2) In an MST Bridge, in accordance with the operation of MAP for MST contexts as specified in 11.2.3.1.2 of this standard.

e) Forward, filter or discard MAC frames carrying any MRP Application address as the destination MAC address in accordance with the requirements of 8.13.6.

f) If a VID Translation Table (6.9) is in use for a Bridge Port, translate VIDs in Multiple VLAN Registration Protocol Data Units (MVRPDUs) as specified in 11.2.4.

5.4.3 VLAN Bridge requirements for congestion notification

A VLAN Bridge implementation that conforms to the provisions of this standard for congestion notification (Clause 30 through Clause 33) shall

a) Support, on one or more Ports, the creation of at least one Congestion Point (CP) (32.1.1);

b) Support, at each CP, the generation of Congestion Notification Messages (CNMs) (32.7) and the removal of Congestion Notification tags (CN-TAGs) (32.1.1);

c) Support the ability to configure the variables controlling the operation of each CP (12.21.1, 12.21.2, 12.21.3, 12.21.4);

d) Support the operation of each Port in each of the Congestion Notification Domain (CND) defense modes separately for each Congestion Notification Priority Value (CNPV) (32.1.1);

e) Conform to the required capabilities of the LLDP of 5.2 of IEEE Std 802.1AB-2009;

f) Support the use of the Congestion Notification TLV in LLDP (32.1.1).

A Provider Instance Port (PIP, 6.10) that conforms to the provisions of this standard for congestion notification shall

g) Support CNM translation (32.16);

A Provider Edge Port (PEP) (15.4) that conforms to the provisions of this standard for congestion notification shall

h) Support CNM translation (32.16).

A VLAN Bridge implementation that conforms to the provisions of this standard for congestion notification may

i) Support the creation of up to seven CPs on a Bridge Port (31.1.1); and/or

j) Support the IEEE8021-CN-MIB (17.7.13).

5.4.4 Multiple Stream Registration Protocol (MSRP) requirements

A VLAN Bridge implementation in conformance to the provisions of this standard for the support of MSRP shall

a) Conform to the operation of the MRP Applicant, Registrar, and LeaveAll state machines, as defined in 10.7.7, 10.7.8, and 10.7.9, as required for one or more of the following variants of the MRP Participant, as defined in 10.6 and 10.7:

1) The Full Participant.

2) The Full Participant, point-to-point subset.

b) Exchange MRPDUs as required by those state machines, formatted in accordance with the generic PDU format described in 10.8, and able to carry application-specific information as defined in Clause 35, using the "Individual LAN Scope group address, Nearest Bridge group address" as defined in Table 8-1, Table 8-2, and Table 8-3 (C-VLAN, S-VLAN, and TPMR component Reserved addresses, respectively).

c) Implement the MSRP Application component as defined in Clause 35.

d) Propagate registration information in accordance with the operation of MAP for the Base Spanning Tree Context, as specified in 10.3.1.

e) Forward, filter or discard MAC frames carrying any MRP Application address as the destination MAC address in accordance with the requirements of 8.13.6.

f) Not redeclare its attributes unless responding to a LeaveAll event.

NOTE—In order to meet the requirement specified in 5.4.4(f), the Periodic Transmission state machine (10.7.10) is specifically excluded from MSRP. A Bridge is allowed to generate an MSRP LeaveAll event to force an immediate redeclaration of all MSRP attributes from its neighbor(s).

5.4.5 Shortest Path Bridging (SPB) operation (optional)

A VLAN 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 Shortest Path Tree (SPT) computation for SPB;

c) Encode, decode, and validate SPT BPDUs for the Agreement Protocol (13.17) and support Agreement Protocol logic in Intermediate System to Intermediate System (IS-IS) Protocol as specified in Clause 28;

d) Support at least three FIDs;

e) Support the management functionality specified in Clause 12.

A VLAN 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 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 (ECMP) operation of SPBM (5.4.5.1);

k) Support ECMP operation of SPBM with flow filtering (5.4.5.2).

5.4.5.1 SPBM ECMP 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.

An SPBM capable VLAN-aware bridge implementation that conforms to the provisions of this standard for ECMP may

c) Support the IEEE8021-ECMP-MIB module objects ieee8021EcmpEctStaticTable and ieee8021EcmpTopSrvTable defined in 17.7.21.

5.4.5.2 SPBM ECMP operation with flow filtering (optional)

An SPBM capable VLAN-aware bridge implementation that conforms to the provisions of this standard for 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 flow filtering tags (F-TAGs) from relayed frames as required by the applicable values in the Flow Filtering Control Table for each port;

c) Support the management functionality specified in Clause 12.

An SPBM capable VLAN-aware bridge implementation that conforms to the provisions of this standard for 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.5 C-VLAN component conformance

A C-VLAN component comprises a VLAN Bridge component with the EISS on all Ports supported by the use of a C-VLAN tag (C-TAG) (6.8, 9.5).

A conformant implementation of a C-VLAN component shall

a) Comprise a single conformant VLAN Bridge component;

b) Recognize and use C-TAGs;

c) Filter the reserved MAC addresses specified in Table 8-1;

d) Use the Customer Bridge MVRP Address specified in Table 10-1; and

shall not

e) Use S-VLAN tags (S-TAGs) except in support of the functionality specified in 6.13.

5.5.1 C-VLAN component options

A conformant C-VLAN component may implement the options specified for a VLAN Bridge component whose use is not specifically prohibited by 5.4.1 and may

a) Support encoding the drop_eligible parameter in the PCP field of the tag header (6.9.3); and

b) Allow support of the ISS as specified in 6.13 to facilitate priority selection on a Provider Bridged Network (PBN); and

c) Implement RSTP, with the enhancements to support Customer Edge Ports (CEPs), as specified in 13.41.

5.6 S-VLAN component conformance

An S-VLAN component comprises a VLAN Bridge component with the EISS on all Ports supported by the use of an S-TAG (6.8, 9.5).

A conformant implementation of an S-VLAN component shall

a) Comprise a single conformant VLAN Bridge component; and

b) Recognize and use S-TAGs;

c) Support encoding the drop_eligible parameter in the PCP field of the tag header (6.9.3);

d) Filter the reserved MAC addresses specified in Table 8-2;

e) Use the Provider Bridge MVRP Address specified in Table 8-1;

f) Allow the Acceptable Frame Types parameter (6.9) to be set to Admit All Frames for each Port;

g) Allow the Enable Ingress Filtering parameter (8.6.2) to be set for each Port; and

shall not

h) Recognize or use C-TAGs;

i) Allow support of the ISS as specified in 6.13 for any of its Ports;

j) Configure the Customer Bridge MVRP Addresses specified in Table 10-1 in the FDB (8.8) or Permanent Database (8.8.11);

k) Use the Customer Bridge MVRP Address specified in Table 10-1.

5.6.1 S-VLAN component options

A conformant S-VLAN component may implement any of the options specified for a VLAN Bridge component (5.4.1).

5.6.2 S-VLAN component requirements for Provider Backbone Bridge Traffic Engineering (PBB-TE)

An S-VLAN component implementation that conforms to the provisions of this standard for PBB-TE (25.10) shall

a) Disable learning for a set of Backbone VLAN Identifiers (B-VIDs) allocated to Traffic Engineering Multiple Spanning Tree Instance Identifier (TE-MSTID) as specified in 8.4 and in 8.9; and

b) Discard frames with unregistered destination addresses for B-VIDs allocated to TE-MSTID (8.8.1).

An S-VLAN component implementation that conforms to the provisions of this standard for PBB-TE (25.10) may

c) Allow control of all B-VIDs by an external agent, conforming to the Reserved VID values of Table 9-2;

d) Support MIP creation and the corresponding CFM extensions for Traffic Engineering service instances (TESIs) as specified in 26.9;

e) Support Infrastructure Protection Switching (IPS) as specified in 26.11.

5.6.3 S-VLAN component requirements for PBB-TE IPS

An S-VLAN component implementation that conforms to the provisions of this standard for PBB-TE IPS (26.11) shall

a) Support 1:1 IPS as specified in 26.11.2.

An S-VLAN component implementation that conforms to the provisions of this standard for PBB-TE IPS (26.11) may

b) Support M:1 IPS as specified in 26.11.5.

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 Provider Network Port (PNP).

5.7 I-component conformance

An I-component comprises an S-VLAN component (5.6) with the EISS on each Customer Network Port (CNP) supported by the use of an S-TAG (6.9, 9.5), and the EISS for each Virtual Instance Port (VIP) configured on a PIP supported by the use of both an S-TAG (6.9, 9.5) and a Backbone Service Instance tag (I-TAG) (6.10, 9.5).

A conformant implementation of an I-component shall

a) Comprise a single conformant S-VLAN component;

b) Recognize and use I-TAGs on one or more PIPs (6.10);

c) Support 1:1 mapping between Service VLAN Identifier (S-VID) values and Backbone Service Instance Identifier (I-SID) values;

d) Support the connection_identifier parameter on the EISS of each VIP (6.10) and in the FDB (8.8.12);

e) Support the termination of PBN spanning trees by inhibiting transmission of PBN BPDUs at a PIP.

5.7.1 I-component options

A conformant I-component may implement any of the options specified for an S-VLAN component (5.6.1), and may

a) Support many-to-one mapping from S-VID values to I-SID values;

b) Support a Common Spanning Tree (CST) among PBNs interconnected with one or more backbone service instances by permitting transmission of PBN BPDUs through VIPs at a PIP;

c) Filter frames received at PIPs that have the Backbone Source MAC address (B-SA) used by the PIP, to prevent such frames from circulating if backbone service instances in two or more attached PBBNs are configured in a loop;

d) Use back-to-back Backbone Service Instance Multiplex Entities (6.18) on a PIP to enable monitoring of backbone service instances with CFM;

e) Support the Multiple I-SID Registration Protocol (MIRP) defined in 39.1.1;

f) Support the MVRP Extension MIB module defined in 17.7.15;

g) Support the MIRP MIB module defined in 17.7.16.

5.8 B-component conformance

A B-component comprises an S-VLAN component with the EISS on each PNP supported by the use of an S-TAG (6.9, 9.5), and the EISS on each Customer Backbone Port (CBP) supported by the use of both an S-TAG (6.9, 9.5) and an I-TAG (6.11, 9.5). A conformant implementation of a B-component shall

a) Comprise a single conformant S-VLAN component;

b) Recognize and use I-TAGs on one or more CBPs (6.11);

c) Terminate PBBN spanning tree by inhibiting transmission of PBBN BPDUs at a CBP.

5.8.1 B-component options

A conformant B-component may implement any of the options specified for an S-VLAN component (5.6.1), and may

a) Translate I-SID values by supporting the Local-SID field in the Backbone Service Instance table in CBPs (6.11);

b) Assign B-VID values based on I-SID values by supporting the B-VID field in the Backbone Service Instance table in CBPs (6.11);

c) Use the Default Backbone Destination field in the Backbone Service Instance table in CBPs (6.11) as the destination MAC address for any frames received with the Backbone Service Instance Group address (26.4);

d) Use back-to-back Backbone Service Instance Multiplex Entities (6.18) on a CBP to enable monitoring of backbone service instances with CFM;

e) Support the MIRP defined in 39.1.2;

f) Support the MVRP Extension MIB module defined in 17.7.15;

g) Support the MIRP MIB module defined in 17.7.16.

5.8.2 B-component requirements for PBB-TE

A B-component implementation that conforms to the provisions of this standard for PBB-TE (25.10) shall

a) Disable learning for a set of B-VIDs allocated to TE-MSTID as specified in 8.4 and in 8.9;

b) Discard frames with unregistered destination addresses for B-VIDs allocated to TE-MSTID (8.8.1);

c) Support the Default Backbone Destination field in the Backbone Service Instance tables on the CBPs providing TESIs as specified in 6.11;

d) Support the B-VID field in the Backbone Service Instance tables on the CBPs providing TESIs as specified in 6.11;

e) Support the creation of MEPs for the TESIs on CBPs as specified in 26.9;

f) Support 1:1 protection switching as specified in 26.10.3;

g) Provide control via all of the PBB-TE required managed objects specified in Clause 12.

A B-component implementation that conforms to the provisions of this standard for PBB-TE (25.10) may

h) Allow control of all B-VIDs by an external agent, conforming to the Reserved VID values of Table 9-2;

i) Support MIP creation and the corresponding CFM extensions for TESIs as specified in 26.9;

j) Support the Hold-Off timer used by the protection switching protocol as specified in 26.10.3;

k) Support sharing of TESIs among TE protection groups in order to provide 1:1 protection switching that is capable load sharing as specified in 12.14.1.2 and 25.10.2;

1) Support the Mismatch defect identification as specified in 26.11;

m) Support the PBB-TE MIB module defined in Clause 17;

n) Support IPS as specified in 26.11.

5.8.3 B-component requirements for PBB-TE IPS

A B-component implementation that conforms to the provisions of this standard for PBB-TE IPS (26.11) shall

a) Support 1:1 IPS as specified in 26.11.2.

A B-component implementation that conforms to the provisions of this standard for PBB-TE IPS (26.11) may

b) Support M:1 IPS as specified in 26.11.5.

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.

5.9 C-VLAN Bridge conformance

A C-VLAN Bridge shall comprise a single conformant C-VLAN component (5.5).

Each C-VLAN Bridge Port shall be capable of attaching directly to an IEEE 802 LAN.

5.9.1 C-VLAN Bridge options

A C-VLAN Bridge may implement any C-VLAN component option (5.5).

5.10 Provider Bridge conformance

A Provider Bridge shall comprise one S-VLAN (5.6) component, zero or more C-VLAN components (5.5), and zero or more Port-mapping S-VLAN components (5.6).

NOTE—The one mandatory S-VLAN component in a Provider Bridge is generally referred to simply as the S-VLAN component; however, when this component needs to be distinguished from other components in a Provider Bridge (particularly Port-mapping S-VLAN components), it is sometimes referred to as the “primary S-VLAN component.”

Each Port shall be capable of being configured as one of, and may be capable of being configured as any of

a) A Provider Network Port (PNP)

b) A Customer Network Port (CNP)

c) A Customer Edge Port (CEP)

d) A Remote Customer Access Port (RCAP)

as specified in Clause 15. Each Port configured as a PNP or CNP shall be capable of attaching the S-VLAN component of the Provider Bridge directly to an IEEE 802 LAN. Each Port configured as a CEP shall be capable of attaching a C-VLAN component within the Provider Bridge directly to an IEEE 802 LAN. Each Port configured as an RCAP shall be capable of attaching a Port-mapping S-VLAN component (15.6) within the Provider Bridge directly to an IEEE 802 LAN.

5.10.1 S-VLAN Bridge conformance

An S-VLAN Bridge shall comprise a single conformant S-VLAN component (5.6). An S-VLAN Bridge does not have any physical interfaces configured as a CEP or RCAP, nor does it include any C-VLAN components.

5.10.2 Provider Edge Bridge conformance

A Provider Edge Bridge is a conformant Provider Bridge with a primary S-VLAN component, the capability to include one or more C-VLAN components as specified in 15.4 and the capability to include zero or more Port-mapping S-VLAN components as specified in 15.6.

Each C-VLAN component shall comprise a single CEP and a single distinct PEP for each service instance that can be provided through that CEP. Each PEP shall be connected within the Provider Edge Bridge, as specified in 6.14, to a distinct CNP on the S-VLAN component. Each C-VLAN component shall implement RSTP, with the enhancements to support CEPs, as specified in 13.41.

Each Port-mapping S-VLAN component shall comprise a single RCAP and one or more Provider Access Ports (PAPs) each associated with one Remote Customer Service Interface (RCSI) provided through that RCAP. Each PAP shall be connected within the Provider Edge Bridge, as specified in 6.14, to a distinct CNP on the primary S-VLAN component or CEP on a C-VLAN component. A PNP shall also be provided, connected internally to a PNP on the primary S-VLAN component as specified in 15.6.

NOTE—The single CEP supported by a C-VLAN component and the single RCAP supported by a Port-mapping S-VLAN component can be supported by two or more independent instances of a MAC, aggregated as specified by Link Aggregation (IEEE Std 802.1AX).

5.11 System requirements for Priority-based Flow Control (PFC)

A system that conforms to the provisions of this standard for PFC (see Clause 36) shall

a) Support, on one or more ports, enabling PFC on at least one priority (36.1.2);

b) Support, for each PFC Priority, processing PFC M_CONTROL.requests (36.1.3.1);

c) Support, for each PFC Priority, processing PFC M_CONTROL.indications (36.1.3.3);

d) Abide by the PFC delay constraints (36.1.3.3);

e) Provide PFC aware system queue functions (36.2); and

f) Enable use of PFC only in a domain controlled by DCBX (Clause 38).

A system that conforms to the provisions of this standard for PFC may

g) Support enabling PFC on up to eight priorities per port;

h) Support the IEEE8021-PFC-MIB (17.7.17).

5.12 Backbone Edge Bridge (BEB) conformance

A BEB system shall comprise zero or more I-components and zero or one B-component and zero or more T-components, but at least one I-component or one B-component or one T-component, supporting externally accessible ports as specified in Clause 25. Each externally accessible port shall be designated as one of, and may be capable of being configured as any of the following:

a) A PNP;

b) A PIP;

c) A CBP;

d) A CNP;

e) A CEP;

f) A RCAP.

5.12.1 BEB requirements for PBB-TE

A BEB that conforms to the provisions of this standard for PBB-TE (25.10) shall comprise one B-component capable of providing TESIs (5.8.2) and one or more I-components (5.7) or T-components (5.17).

5.13 MAC Bridge component requirements

An implementation of a MAC Bridge component shall

a) Conform to the relevant standard for the MAC technology implemented at each Port in support of the MAC ISS, as specified in IEEE Std 802.1AC;

b) Support the VLAN-unaware MAC Relay Entity by means of an ISS interface (not an EISS interface);

c) Implement an ISO/IEC 8802-2 conformant LLC class with Type 1 operation as required by 8.2;

d) Maintain the information required to support Basic Filtering Services, as described in IEEE Std 802.1AC and in 8.1 and specified in 8.5, 8.7, and 8.8;

e) Conform to the provisions for addressing specified in 8.13;

f) Implement RSTP, as specified in Clause 13;

g) Encode transmitted BPDUs and validate received BPDUs as specified in Clause 14;

h) Specify the following parameters of the implementation:

1) Filtering Database Size, the maximum number of entries;

2) Permanent Database Size, the maximum number of entries;

i) Specify the following performance characteristics of the implementation:

1) A Guaranteed Port Filtering Rate for each Bridge Port;

2) A Guaranteed Bridge Relaying Rate for the Bridge;

3) The related time intervals $T_F$ and $T_R$ for these parameters as specified in Clause 24;

j) Operation of the Bridge within the specified parameters shall not violate any of the other conformance provisions of this standard.

5.13.1 MAC Bridge component options

An implementation of a MAC Bridge component may

a) Support Extended Filtering Services (6.16.5) and the operation of MMRP (10.9) to support automatic configuration and management of MAC address information on all Ports (5.4.1.3);

b) Support the management functionality defined in Clause 12;

c) Support the use of a remote management protocol. Bridges claiming to support remote management shall

1) State which remote management protocol standard(s) or specification(s) are supported;

2) State which standard(s) or specification(s) for managed object definitions and encodings are supported for use by the remote management protocol;

d) Support multiple Traffic Classes for relaying and filtering frames through one or more outbound Ports, controlling the mapping of the priority of forwarded frames as specified in IEEE Std 802.1AC and 6.9.4;

e) Allow configuration of the Restricted_MAC_Address_Registration parameter (10.12.2.3) for each Port of the Bridge;

f) Support the ISS with signaled priority on each Bridge Port (6.20);

g) Support SMIv2 MIB modules for the management of MAC Bridge capabilities (Clause 17);

h) Support CFM operation (5.4.1.4);

i) Support ETS (5.4.1.6);

j) Support PFC (5.11)

k) Support DCBX (5.4.1.7).

5.14 MAC Bridge conformance

A MAC Bridge shall comprise a single conformant MAC Bridge component (5.13).

Each Bridge Port shall be capable of attaching directly to an IEEE 802 LAN.

5.14.1 MAC Bridge options

A MAC Bridge may implement any VLAN-unaware component option (5.5).

5.15 TPMR component conformance

A TPMR component comprises a MAC Bridge component. A conformant implementation of a TPMR component shall

a) Support exactly two Bridge Ports other than a Management Port.

b) Support the operation of the following functions of the Forwarding Process:

1) Frame filtering (8.6.3).

2) Queuing frames (8.6.6).

3) Transmission selection (8.6.8).

c) Support the operation of the MAC Status Propagation Entity (MSPE), by means of the functions and protocol specified in Clause 23.

d) Support at least one traffic class on each Bridge Port.

e) Support the management functionality specified in 12.19.

f) Support only the following entries in the FDB:

1) Static Filtering Entries, permanently configured in the FDB and that cannot be modified by management, that specify filtering on both of the TPMR's Bridge Ports for the group MAC addresses defined in Table 8-3; and

2) A Static Filtering Entry, permanently configured in the FDB and that cannot be modified by management, that specifies forwarding or filtering on each of the TPMR's Bridge Ports for the MAC address associated with the management entity of the TPMR. The values that are configured into this filtering entry are determined by the implementer, and shall be stated in the PICS.

g) Support a MIP on an MA that is not associated with any VLAN on each of the TPMR's Bridge Ports. The default MD level shall be zero.

NOTE—As a TPMR is a non-VLAN aware Bridge, these MPs are not associated with a particular VID (22.1.7). This default level 0 MIP allows detection and identification of the TPMR without configuration. Such a MIP can of course be disabled by management.

A conformant implementation of a TPMR component shall not

h) Implement RSTP defined in Clause 13.

i) Encode transmitted BPDUs and validate received BPDUs (Clause 14).

j) Support Extended Filtering Services for relaying and filtering frames (6.16.5).

5.15.1 TPMR component options

An implementation of a TPMR component may

a) Support multiple traffic classes on each Bridge Port.

b) Support the ISS with signaled priority on each Bridge Port (6.20).

5.16 TPMR conformance

An implementation of a TPMR shall

a) Comprise a single conformant TPMR component (5.15).

b) Support exactly two externally accessible Ports, each capable of attaching directly to an IEEE 802 LAN.

c) Be capable of supporting a management entity using the TPMR Port Connectivity (8.5.2) on one of its externally accessible ports.

d) Support remote management of the TPMR managed objects specified in 12.19.

5.16.1 TPMR options

A TPMR may implement any TPMR component option (5.15.1).

An implementation of a TPMR may

a) Support a management entity using the Bridge Port Connectivity (8.5.1) on a Management Port (8.3) or the externally accessible ports.

b) Support remote management using Simple Network Management Protocol (SNMP) over IEEE 802 Networks (IETF RFC 4789, 8.13.7).

c) Support remote management using the TPMR MIB module defined in 17.7.11.

NOTE—While IETF RFC 4789 is specifically referenced, the standard does not preclude the support of other transports for SNMP.

5.17 T-component conformance

A T-component comprises a TPMR component (5.15) with one PIP (6.11).

A conformant implementation of an T-component shall

a) Comprise a single conformant TPMR component.

b) Recognize and use I-TAGs on one PIP (6.10).

c) Support a single VIP at the PIP.

5.17.1 T-component options

A conformant T-component may implement any of the options specified for a TPMR component (5.15.1).

5.18 End station requirements for MMRP, MVRP, and MSRP

This subclause defines the conformance requirements for end station implementations claiming conformance to MVRP, MMRP, and MSRP. Although this standard is principally concerned with defining the requirements for VLAN Bridges, the conformance requirements for end station implementations of MVRP, MMRP, and MSRP are included in order to give guidance to such implementations. The PICS proforma defined in Annex B is concerned with conformance claims with respect to end station implementations.

For the reasons stated in 10.6, it is recommended that end stations that do not require the ability to perform Source Pruning implement the Applicant-Only Participant, in preference to the Simple-Applicant Participant.

5.18.1 MMRP requirements and options

An end station for which conformance to MMRP is claimed shall

a) Conform to the operation of the MRP Applicant, Registrar, LeaveAll, and Periodic Transmission state machines, as defined in 10.7.7, 10.7.8, 10.7.9, and 10.7.10, as required for one or more of the following variants of the MRP Participant, as defined in 10.6 and 10.7:

1) The Full Participant.

2) The Full Participant, point-to-point subset.

3) The Applicant-Only Participant.

4) The Simple-Applicant Participant.

b) Exchange MPDUs as required by the MRP state machine(s) implemented, formatted in accordance with the generic PDU format described in 10.8, and able to carry application-specific information as defined in 10.12.1, using the "Individual LAN Scope group address, Nearest Bridge group address" as defined in Table 8-1, Table 8-2 and Table 8-3 (C-VLAN and MAC Bridge, S-VLAN and TPMR component Reserved addresses, respectively).

An end station for which conformance to the operation of the Applicant state machine (10.7.7) is claimed may

c) Perform source pruning, as defined in 10.10.3 and 10.12.

It is recommended that only those end stations that require the ability to perform Source Pruning (10.10.3) conform to the operation of the Full Participant or the Full Participant, point-to-point subset.

NOTE—If an end station does not require the ability to perform Source Pruning, then there is no need for it to implement Registrar functionality.

5.18.2 MVRP requirements and options

An end station for which conformance to MVRP is claimed shall

a) Conform to the operation of the MRP Applicant, Registrar, LeaveAll, and Periodic Transmission state machines, as defined in 10.7.7, 10.7.8, 10.7.9, and 10.7.10, as required for one or more of the following variants of the MRP Participant, as defined in 10.6 and 10.7:

1) The Full Participant.

2) The Full Participant, point-to-point subset.

3) The Applicant-Only Participant.

4) The Simple-Applicant Participant.

An end station for which conformance to MVRP is claimed may

c) Perform source pruning, as defined in 10.10.3 and 11.2.1.1.

It is recommended that only those end stations that require the ability to perform Source Pruning (11.2.1.1) conform to the operation of the Full Participant or the Full Participant, point-to-point subset.

NOTE—If an end station does not require the ability to perform Source Pruning, then there is no need for it to implement Registrar functionality.

d) Support the operation of MVRP (5.4.2, 11.2) as a New-Only Participant.

e) Support the MVRP Extension MIB module defined in 17.7.15.

5.18.3 MSRP requirements and options

An end station for which conformance to MSRP is claimed shall

1) The Full Participant.

2) The Full Participant, point-to-point subset.

3) The Applicant-Only Participant.

4) The Simple-Applicant Participant.

b) Exchange MPDUs as required by the MRP state machine(s) implemented, formatted in accordance with the generic PDU format described in 10.8, and able to carry application-specific information as defined in 35.2.2, using the “Individual LAN Scope group address, Nearest Bridge group address” as defined in Table 8-1, Table 8-2, and Table 8-3 (C-VLAN, S-VLAN, and TPMR component Reserved addresses, respectively).

c) Not redeclare its attributes unless responding to a LeaveAll event.

An end station for which conformance to the operation of the Applicant state machine (10.7.7) is claimed may

d) Perform Talker pruning, as defined in 35.2.1.4(b), 35.2.3.1 and 35.2.4.3.1.

e) Perform Listener pruning as described in 35.2.3.1.

NOTE—In order to meet the requirement specified in 5.18.3(c), the Periodic Transmission state machine (10.7.10) is specifically excluded from MSRP. An end station is allowed to generate an MSRP LeaveAll event to force an immediate redeclaration of all MSRP attributes from its neighbor(s).

5.19 VLAN-aware end station requirements for CFM

A VLAN-aware Station implementation that conforms to the provisions of this standard for CFM (Clause 18 through Clause 22) shall

a) Support the creation of Maintenance Domains at eight MD Levels, with multiple nonoverlapping Maintenance Domains at each MD Level, using the managed objects specified in 12.14;

b) Support the creation of an MA on each VID supported by the Station for each MD Level;

c) Support the creation of eight Down MEPs on each VID on each Port, each MEP at a different MD Level;

d) Support the creation of eight Down MEPs attached to no VID on each Port, each MEP at a different MD Level;

e) Support the maintenance of a MEP CCM Database;

f) Provide control via all of the required managed objects specified in 12.14;

g) Conform to the state machines and procedures in Clause 20; and

h) Transmit and receive required CFM PDUs in the formats specified in Clause 21.

A VLAN-aware Station implementation that conforms to the provisions of this standard for CFM may

i) Support the CFM MIB module defined in 17.5;

j) Support the creation of MAs that are associated with more than one VID (22.1.5).

5.20 End station requirements—FQTSS

An end station implementation that conforms to the provisions of this standard for FQTSS shall

a) Support a minimum of two traffic classes on all Ports, of which

1) A minimum of one traffic class supports the strict priority algorithm for transmission selection (8.6.8.1), and

2) One traffic class is an SR class.

b) Support the operation of the credit-based shaper algorithm (8.6.8.2) as the transmission selection algorithm used for frames transmitted for each stream associated with the SR class.

c) Support the operation of the credit-based shaper algorithm (8.6.8.2) on all Ports as the transmission selection algorithm used for the SR class.

d) Use the default priority associated with SR class “B” as shown in Table 6-5 as the priority value carried in transmitted SR class “B” data frames.

An end station implementation that conforms to the provisions of this standard for FQTSS may

e) Support two or more SR classes (a maximum of seven), and support the operation of the credit-based shaper algorithm (8.6.8.2) on all Ports as the transmission selection algorithm used for those SR classes. The number of SR classes supported shall be stated in the PICS.

f) Use the default priority associated with SR class “A” as shown in Table 6-5 as the priority value carried in transmitted SR class “A” data frames. If more than two SR classes are supported, the priority value carried in transmitted data frames for the additional SR classes shall be stated in the PICS.

5.21 End station requirements for congestion notification

A VLAN-aware end station implementation that conforms to the provisions of this standard for congestion notification (Clause 30 through Clause 33) shall

a) Support the creation of at least one Reaction Point (RP) (31.2.2.2);

b) Support, if CPs are supported, the ability to configure the variables controlling the operation of each CP, if any (12.21.1, 12.21.2, 12.21.3, 12.21.4);

c) Support, at each supported CP, if any, the generation of CNMs (32.7);

d) Support the ability to configure the variables controlling the operation of each RP (12.21.1, 12.21.5, 12.21.6);

e) Support the operation of its Port in at least the cptDisabled and cptInterior CND defense modes separately for each CNPV (32.1.1);

f) Conform to the required specifications of the LLDP of IEEE Std 802.1AB;

g) Support the use of the Congestion Notification TLV in LLDP (32.1.1);

h) Support, in each RP, the limiting of frames output in response to the reception of CNMs (31.2.2.2);

i) Support, if multiple RPs are supported, the ability to distinguish among CNMs pertaining to different RPs, and direct each such message to the correct RP (31.2.5).

A VLAN-aware end station implementation that conforms to the provisions of this standard for congestion notification (Clause 30 through Clause 33) may

j) Support the creation of one or more CPs (31.1.1);

k) Support the creation of more than one RP (31.2.2.2);

1) Support more than one CNPV per RP (31.2.1); and/or

m) Support the operation of its Port in both the cptInterior and cptInteriorReady CND defense modes separately for each CNPV (31.1.1);

n) Support the IEEE8021-MIRP-MIB (17.7.13).

5.22 MAC-specific bridging methods

MAC-specific bridging methods may exist. Use of a MAC-specific bridging method and the method specified in this standard on the same LAN shall

a) Not prevent communication between stations in a network.

b) Preserve the MAC Service.

c) Preserve the characteristics of each bridging method within its own domain.

d) Provide for the ability of both bridging techniques to coexist simultaneously on a LAN without adverse interaction.

5.23 EVB Bridge requirements

An EVB Bridge shall comprise a single conformant C-VLAN component (5.5) and zero or one Port-mapping S-VLAN component (5.6) per externally accessible port.

Each externally accessible port shall be capable of being configured as one of, and may be capable of being configured as any of the following:

a) A C-VLAN Bridge Port

b) A Station-facing Bridge Port (SBP)

c) An Uplink Access Port (UAP)

as specified in Clause 40.

A conformant EVB Bridge implementation shall

d) Support the functionality of a C-VLAN component (5.5).

e) Support at least one SBP on the C-VLAN component (Clause 40).

f) Support the EVB status parameters for EVBMode = EVB Bridge (40.4).

g) Support an LLDP nearest Customer Bridge database (Clause 40).

h) Support the EVB TLV on each SBP (D.2.13).

i) Support Edge Control Protocol (ECP) on each SBP (Clause 43).

j) Support the Bridge role of Virtual Station Interface (VSI) Discovery and Configuration Protocol (VDP) on each SBP (Clause 41).

A conformant EVB Bridge may support S-channels. A conformant EVB Bridge with S-channel support shall

k) Support at least one Port-mapping S-VLAN component (22.6.4) and associated UAP, configured as specified in 40.2 a)–d).

1) Support S-channel Discovery and Configuration Protocol (CDCP), as specified in Clause 42, operating in Bridge mode.

m) Support the enhanced filtering utility criteria (8.7.2) and not support the default filtering utility criteria (8.7.1).

A conformant EVB Bridge implementation may

n) Support configuration of reflective relay on each SBP of the C-VLAN component (8.6.1).

o) Support management for the EVB components (12.4–12.12, 12.26).

p) Support the MIB module defined in 17.7.20.

q) Support assignment of VIDs to GroupIDs (41.2.9).

r) Support the use of the M and S bits in VDP (41.2.3).

5.24 EVB station requirements

An EVB station shall comprise one or more conformant ERs (5.24.1) and zero or one Port-mapping S-VLAN component (5.6) per externally accessible port.

Each externally accessible port shall be capable of being configured as one of, and may be capable of being configured as any of the following:

a) An Uplink Access Port (UAP)

b) An uplink relay port (URP)

as specified in Clause 40.

Each downlink relay port (DRP) shall be capable of attaching to one or more VSIs.

Each URP shall be capable of attaching its ER to the LAN connecting to an EVB Bridge, or in the case where a Port-mapping S-VLAN component is present, to an internal LAN (6.14) connecting the URP to a S-channel Access Port (CAP).

A conformant EVB station implementation shall

c) Support at least one ER (5.24.1, Clause 40).

d) Support the EVB status parameters for EVBMode = EVB station on each URP (40.4).

e) Support an LLDP nearest Customer Bridge database (Clause 40).

f) Support the EVB TLV on each URP of each ER (D.2.13).

g) Support ECP on each URP of each ER (Clause 43).

h) Support the station role of VDP for each URP of each ER (Clause 41).

In addition, a conformant EVB station implementation that supports a Port-mapping S-VLAN components shall

i) Support a Port-mapping S-VLAN component (22.6.4) on each port configured as a UAP (40.2) configured as specified in 40.2 (a)-(d).

j) Support CDCP, as specified in Clause 42, operating in Station mode.

k) Support the enhanced filtering utility criteria (8.7.2) and not support the default filtering utility criteria (8.7.1).

A conformant EVB station implementation may

1) Support multiple ERs (Clause 40).

m) Support management for the EVB components (12.4–12.12, 12.26).

n) Support the MIB module defined in 17.7.20.

o) Support assignment of VIDs to GroupIDs (41.2.9).

p) Support the use of the M and S bits in VDP (41.2.3).

5.24.1 Edge relay (ER) requirements

A conformant implementation of an ER shall

a) Conform to the relevant standard for the MAC technology implemented at each Port in support of the MAC ISS, as specified in IEEE Std 802.1AC and 6.14.

b) Support the MAC EISS at each Port, as specified in 6.8 and 6.9.

c) Recognize and use C-TAGs (6.9).

d) Relay and filter frames as described in 8.1 and specified in 8.5, 8.6, and 8.8.

e) Support the following on each DRP Port that supports untagged and priority-tagged frames:

1) A PVID value (6.9)

2) Configuration of at least one VID whose untagged set includes that Port (8.8.2)

f) Support setting the Acceptable Frame Types parameter (6.9) to Admit Only VLAN-tagged Frames on the URP.

g) Allow tag headers to be inserted, modified, and removed from relayed frames, as specified in 8.1 and Clause 9, as required by the value(s) of the Acceptable Frame Types parameter supported on each Port, and by the ability of each Port to transmit VLAN-tagged and/or untagged frames.

h) Support at least one FID (IEEE Std 802.1AC, 8.8.3, 8.8.8, and 8.8.9).

i) Allow allocation of at least one VID to each FID that is supported (IEEE Std 802.1AC, 8.8.3, 8.8.8, and 8.8.9).

j) Support exactly one URP (Clause 40) supporting the parameters of 40.4 for EVBMode = EVB station.

k) Support one or more DRPs each supporting access to VSIs (Clause 40).

1) Filter the reserved MAC addresses specified in Table 8-1.

m) If more than one DRP is supported, support setting the Enable Ingress Filtering parameter (8.6.2) on each DRP and the URP.

n) Support the requirements of either a virtual edge bridge (VEB) ER (5.24.1.1) or a virtual edge port aggregator (VEPA) ER (5.24.1.2).

A conformant implementation of an ER may

o) Support the following if the URP supports untagged and priority-tagged frames:

1) A PVID value (6.9);

2) Configuration of at least one VID whose untagged set includes that Port (8.8.2).

p) Comprise a single conformant C-VLAN component (5.4).

q) Support disabling of learning on each DRP (8.6.1).

r) Support the ability to discard frames received at each DRP if there is no entry in the FDB that specifies forwarding on that Port for the frame's source MAC address and VLAN.

s) Support the operation of the learning process as described in 8.7.

5.24.1.1 VEB ER requirements

In addition to the requirements stated in 5.24.1, a conformant VEB ER implementation shall

a) Request that reflective relay service not be provided by setting adminReflectiveRelayRequest to FALSE (40.4).

5.24.1.2 VEPA ER requirements

In addition to the requirements stated in 5.24.1, a conformant VEPA ER implementation shall

a) Disable learning on the URP (8.6.1).

b) Filter frames as specified in 8.6.3.1.

A conformant VEPA ER implementation may

c) Filter frames received at each DRP that are destined for the URP until reflective relay is enabled (40.4).

A conformant VEPA ER implementation should

d) Request the provision of reflective relay service by setting adminReflectiveRelayRequest to TRUE (40.4).

NOTE—This item is optional because there can be cases where an EVB station is configured to prohibit VSIs from communicating with each other in VEPA mode.

6 Support of the MAC Service

VLAN Bridges interconnect the separate IEEE 802 LANs that compose a Virtual Bridged Network by relaying and filtering frames between the separate MACs of the bridged LANs.

The position of a VLAN Bridge's MAC Relay Entity (8.2) within the MAC Sublayer is shown in Figure 6-1.

!image

NOTE—The notation “IEEE Std 802.n” in this figure indicates that the specifications for these functions can be found in the relevant standard for the media access method concerned; for example, n would be 3 (IEEE Std 802.3) in the case of Ethernet.

Figure 6-1—Internal organization of the MAC sublayer

The MAC Sublayer comprises

a) Media access method-specific functions $^{15}$ that realize transmission and reception of MAC Protocol Data Units (MPDUs);

b) Media access method-dependent convergence functions that use item a) to provide a media access method-independent service;

c) Media access method-independent functions that use a media-independent service to provide the same or another media-independent service.

A MAC Bridge's MAC Relay Entity forwards frames between the instances of the media-independent ISS (IEEE Std 802.1AC).

A VLAN Bridge's MAC Relay Entity forwards frames between the instances of the media-independent EISS (6.8). The EISS is provided by the functions specified in 6.9 using the media-independent ISS (IEEE Std 802.1AC). The convergence functions that provide the ISS using the media-specific functions for each IEEE 802 LAN MAC type are specified in IEEE Std 802.1AC.

This clause

d) Summarizes basic architectural concepts and terms used throughout this standard, introduces the primitives and parameters of the MAC Service, and defines VLANs in terms of the connectivity provided to service users (IEEE Std 802.1AC, 6.2, 6.3);

e) Describes how Bridges preserve and maintain the quality of the MAC Service (6.4, 6.5);

f) Specifies the MAC ISS and MAC status parameters, their support by specific media access methods (IEEE Std 802.1AC), and support for signaled priority (IEEE Std 802.1AC, 6.14, 6.15, 6.20);

g) Specifies the EISS used by VLAN-aware stations, the encoding of VID and priority parameters in transmitted frames, and the classification of received frames that do not explicitly convey those parameters (6.8, 6.9, 6.12); and

h) Specifies how entities defined in terms of the ISS can support the EISS (6.17).

6.1 Basic architectural concepts and terms

The architectural concepts used in this and other IEEE 802.1 standards are based on the layered protocol model introduced by the OSI Reference Model (ISO/IEC 7498-1) and used in the MAC Service definition (IEEE Std 802.1AC), in IEEE Std 802, in other IEEE 802 standards, and elsewhere in networking. IEEE 802.1 standards in particular have developed terms and distinctions useful in describing the MAC Service and its support by protocol entities within the MAC Sublayer. $^{16}$ For further detailed discussion of these concepts and terms, see IEEE Std 802.1AC.

6.2 Provision of the MAC Service

The MAC Service provided in end stations attached to MAC Bridged Networks and Virtual Bridged Networks is the (unconfirmed) connectionless mode MAC Service defined in IEEE Std 802.1AC. The MAC Service is defined as an abstraction of the features common to a number of specific MAC Services; it describes the transfer of user data between source and destination end stations, via MA-UNITDATA request primitives and corresponding MA-UNITDATA indication primitives issued at MAC Service Access Points (MSAPs). Each MA-UNITDATA request and indication primitive has four parameters: Destination Address, Source Address, MAC Service data unit (MSDU), and Priority.

NOTE 1—The primitives of the MAC Service are closely aligned with those of the ISS (IEEE Std 802.1AC).

In a MAC Bridged Network, MAC Bridges provide a single instance of the MAC Service for the network as a whole—a single LAN, as defined in IEEE Std 802.1AC—by forwarding between the individual LANs that compose the network, though frames with specified group destination addresses are confined to individual LANs.

NOTE 2—MAC Bridges can be configured to completely partition a bridged network, though that is rarely intended.

In a Virtual Bridged Network, VLANs are defined in terms of the connectivity associations (IEEE Std 802.1AC) supported by the network: if service requests made at two different MSAPs both result in service indications at any third MSAP, then the two MSAPs are transmitting on the same VLAN; and if the service requests made at any given MSAP can result in service indications at either (or both) of two MSAPs, then those two MSAPs are receiving on the same VLAN. When only two MSAPs are in bidirectional communication, they are using the same VLAN for both transmit and receive if a third station could be added in such a way that it would receive transmissions from both.

NOTE 3—This definition of a VLAN accommodates an unavoidable and sometimes useful consequence of configuration possibilities: use of a single MSAP can result in transmission on one VLAN and reception on another.

NOTE 4—Protocol VLAN classification can be used to classify frames transmitted from a single MSAP into separate VLANs. Where protocol classification is used, the preceding rules apply to frames of a single classification.

6.2.1 Point-to-point, multipoint-to-multipoint, and rooted-multipoint connectivity

The types of connectivity supported by associations of Bridge Ports in Virtual Bridged Networks are often classified into three categories: point-to-point, multipoint-to-multipoint, and rooted-multipoint. Point-to-point connectivity is an association of exactly two Bridge Ports such that an ingress frame (for a given VLAN) at one Bridge Port may result in an egress frame at the other Bridge Port. Multipoint-to-multipoint connectivity is an association of two or more Bridge Ports such that an ingress frame at one Bridge Port may result in an egress frame at any or all of the other Bridge Ports. Rooted-multipoint connectivity is an association of two or more Bridge Ports where each Bridge Port is designated as either a Root or a Leaf Port, and an ingress frame at a Root Port may result in an egress frame at any or all Leaf Ports and other Root Ports, while an ingress frame at a Leaf Port may result in an egress frame at any or all Root Ports but never results in an egress frame at another Leaf Port. Note that point-to-point connectivity is a special case of the more general multipoint-to-multipoint connectivity, and that both point-to-point connectivity and multipoint-to-multipoint connectivity are special cases of rooted-multipoint connectivity where all Bridge Ports are designated as Root Ports.

6.3 Support of the MAC Service

In a MAC Bridged Network at most one LAN can be supported on each of the individual LANs that, bridged together, compose the network. On the individual LANs of a Virtual Bridged Network, frames for different VLANs can be distinguished by the addition of a VLAN tag as the initial octets of a frame's MSDU.

When a VLAN-unaware end station is attached to an individual LAN, it will transmit and receive only untagged frames, and thus uses the VID(s) assigned by the Bridge Ports that classify those frames.

NOTE 1—Where there are only two stations attached to an individual LAN, each can assign received untagged frames to a different VID. However, such assignments can defeat the operation of network configuration protocols and can only be recommended at the edge of a network to facilitate initial classification of untagged frames transmitted by VLAN-unaware end stations. Otherwise, a change in a frame's VID can severely impact network operation by introducing frame forwarding loops. The same considerations apply to the use of protocol VLAN classification. The use of different VID assignments by Bridge Ports attached to the same LAN is usually a network configuration error.

NOTE 2—The LLC Entity in a VLAN-unaware end station can receive MAC Service indications that correspond to the receipt of VLAN-tagged frames but, being unable to recognize the tag's EtherType value, will discard the frame and not deliver it to any LLC User.

A VLAN-aware end station can use the EISS Multiplex Entity (6.17) to provide multiple SAPs, one per VID of interest, to separate MAC Clients.

The objective of Bridge operation is to maximize the availability of the MAC Service to end stations and to assist in the maintenance of the network. Bridges can be configured to provide redundant paths between end stations, enabling the network to continue providing service in the event of component failure (of Bridge or LAN). The paths supported between end stations are predictable and configurable. Group addressed (multicast and broadcast) frames for any given VLAN take the same path as frames addressed to an individual end station (unicast), thus permitting the use of either individually addressed or group addressed frames to configure or diagnose paths for frames with either group or individual destination addresses. The paths taken for frames for any given VLAN between any two stations are symmetric, i.e., frames from station A (say) to station B traverse the same Bridges and LANs as those from B to A, only in the reverse order. This symmetry reduces the probability of one-way connectivity between stations and permits the use of station location learning to localize traffic (6.5.10).

The VLAN Identifier (VID) conveyed in the VLAN tag associates each frame with the following:

a) A VLAN.

b) A loop-free active topology.

6.4 Preservation of the MAC Service

The MAC Service offered by a network consisting of LANs interconnected by Bridges is similar to that offered by a single LAN (see 6.5).

a) Frames transmitted between end stations carry the MAC addresses of the peer-end stations in their destination and source address fields, not an address of a Bridge. The MAC Relay is not directly addressed by communicating end stations.

b) The MAC addresses of end stations are not restricted by the network's topology or configuration.

c) All MAC addresses need to be unique within a VLAN, and within any set of VLANs for which filtering information is shared by a Bridge.

6.5 Quality of service (QoS) maintenance

6.5.1 Service availability

Service availability is measured as that fraction of some total time during which the MAC Service is provided. The operation of a Bridge can increase or lower the service availability.

The service availability can be increased by automatic reconfiguration of the network in order to avoid the use of a failed component (e.g., repeater, cable, or connector) in the data path. The service availability can be lowered by failure of a Bridge, through denial of service by the Bridge, or through frame filtering by the Bridge. Changes in topology, caused by component failures, the addition or removal of components, or administrative changes, are detected and signaled by the following means:

a) Physical detection of component failure and signaling of that failure by the EISS (6.8 and 6.9);

b) Detection of component failure through the operation of a spanning tree algorithm and protocol;

c) Explicit signaling of reconfiguration events through the operation of a spanning tree algorithm and protocol.

NOTE 1—Each reference to spanning tree algorithms and protocols throughout Clause 6 includes any whose purpose is to verify that each transmitted frame gives rise to at most one service indication at any of the MSAPs for which frames for that LAN or VLAN are to be received. Such protocols include RSTP (13.4), MSTP (13.5), and SPB (Clause 27).

Automatic reconfiguration can be achieved rapidly on the detection of a physical topology change (see Clause 13), thus minimizing any service denial that is caused by the reconfiguration.

A Bridge may deny service and discard frames (6.5.2) in order to preserve other aspects of the MAC Service (6.5.3 and 6.5.4) when automatic reconfiguration takes place. Service may be denied to end stations that do not benefit from the reconfiguration; hence, the service availability is lowered for those end stations. Bridges may filter frames in order to localize traffic in the network. Should an end station move, it may then be unable to receive frames from other end stations until the filtering information held by the Bridges is updated.

To minimize the effects of service denial caused by reconfiguration events, filtering information that has been dynamically learned can be modified when automatic reconfiguration takes place, or in preparation for future reconfiguration events (Clause 13 and 13.16). However, filtering information that is statically configured cannot be modified in this way.

A Bridge may deny service and discard frames in order to prevent access to the network by devices that are not authorized for such access.

To maximize the service availability, no loss of service or delay in service provision should be caused by Bridges, except as a consequence of a failure, removal, or insertion of a network component; or as a consequence of the movement of an end station; or as a consequence of an attempt to perform unauthorized access. These events are regarded as extraordinary. The operation of any additional protocol necessary to maintain the quality of the MAC Service is thus limited to the configuration of the network and is independent of individual instances of service provision.

NOTE 2—This is true only in circumstances where admission control mechanisms are not present, i.e., where the Bridges provide a “best effort” service.

NOTE 3—The operation of management on the Bridge can result in the Bridge being reset, either as a result of a specific Bridge reset operation or as a consequence of manipulating the Bridge's configuration. From the point of view of service availability, resetting the Bridge is an extraordinary event that has a similar effect to physical removal of the Bridge from the network, followed by reinsertion of the Bridge into the network.

6.5.2 Frame loss

The MAC Service does not guarantee the delivery of Service Data Units (SDUs). Frames transmitted by a source station arrive, uncorrupted, at the destination station with high probability. The operation of a Bridge introduces minimal additional frame loss.

A frame transmitted by a source station can fail to reach its destination station as a result of

a) Frame corruption during physical layer transmission or reception.

b) Frame discard by a Bridge because

1) It is unable to transmit the frame within some maximum period of time and, hence, must discard the frame to prevent the maximum frame lifetime (6.5.6) from being exceeded.

2) It is unable to continue to store the frame due to exhaustion of internal buffering capacity as frames continue to arrive at a rate in excess of that at which they can be transmitted.

3) The size of the SDU carried by the frame exceeds the maximum supported by the MAC procedures employed on the LAN to which the frame is to be relayed.

4) Changes in the connected topology of the network necessitate frame discard for a limited period of time to maintain other aspects of QoS (13.16).

5) The device attached to the Bridge is not authorized for access to the network.

6) The configuration of Static Filtering Entries or Static VLAN Registration Entries in the FDB (8.8.1, 8.8.2) disallows the forwarding of frames with particular destination addresses or VLAN classifications on specific Ports.

7) A flow metering algorithm (8.6.5) determines that discard is necessary.

NOTE—As Static Filtering Entries and Static VLAN Registration Entries are associated with particular Ports or combinations of Ports, there is a possibility that misconfiguration of such entries will lead to unintended frame discard during or following automatic reconfiguration of the network.

6.5.3 Frame misordering

The MAC Service (IEEE Std 802.1AC) permits a negligible rate of reordering of frames with a given priority for a given combination of destination address, 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, 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 [B9]), 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 (ISO/IEC 8802-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 [B10].

6.5.4 Frame duplication

The MAC Service (IEEE Std 802.1AC) permits a negligible rate of duplication of frames. The operation of Bridges introduces a negligible rate of duplication of user data frames.

The potential for frame duplication in a bridged network arises through the possibility of the following:

a) Repeated transmission, through a given Bridge Port, of a frame received on another Bridge Port;

b) Multiple paths between source and destination end stations;

c) A loop in a path between source and destination stations.

A Bridge does not transmit any received frame more than once through any Port (8.6.7).

When Bridges in a network connect individual LANs in such a way that physical topology is capable of providing multiple paths between any source and destination, a protocol is required to ensure that the active topology comprises a single path. SST Bridges assign all frames to a single active topology, other Bridges assign frames to an active topology using the VID or VID and destination address. For frames assigned to Ethernet Switched Paths (ESPs) by PBB-TE, the protocol comprises the operation of an external agent that configures Static Filtering Entries in the FDB (see 25.10); for all other frames RSTP, MSTP, or Intermediate System to Intermediate System Protocol for Shortest Path Bridging (ISIS-SPB) is used to configure the controls used for active topology enforcement (8.6.1). Reception of duplicate copies of a single transmitted frame can be avoided by loop prevention (6.5.4.1) or loop mitigation (6.5.4.2).

NOTE—Where RSTP, MSTP, or SPB is used (see Clause 13), there is a probability that a reconfiguration event can cause frames that are in transit through the network to be duplicated, because a Bridge can buffer frames awaiting transmission through its Ports. As the probability of duplication occurring as a result of such an event is small, and the frequency of reconfiguration events is also small, the degradation of the properties of the MAC Service caused by this source of frame duplication is considered to be negligible. A more detailed discussion of frame duplication in RSTP can be found in K.2 of IEEE Std 802.1D-2004 [B10].

6.5.4.1 Loop prevention

Each Bridge that participates in RSTP, MSTP, or ISIS-SPB calculates a spanning tree for each active topology, and prevents loops by exchanging information between neighboring Bridges to ensure either that their topology calculations are consistent and each frame is consistently allocated to the same active topology, or that frames are not relayed.

6.5.4.2 Loop mitigation

Each Bridge that participates in SPBM may mitigate loops. The properties of loop mitigation are listed below. Allowing temporary loops to form for unicast traffic and using loop mitigation provides for faster response to topology changes. Loop mitigation is accomplished if a unicast frame can only be forwarded by the Bridges as follows:

a) From at most one reception Port to at most one transmission Port; and

b) To a different transmission Port from the reception Port;

and

c) Each Bridge does not relay, from any reception Port, a frame whose source address and VID are the same as that used by any entity within the Bridge; and

d) Each Bridge does not transmit, through any Port, a frame whose destination address and VID are the same as that used by any entity within the Bridge;

and

e) All LANs in the network provide only point-to-point connectivity.

Loop mitigation limits the effect of loops since any loop in the active topology cannot include either the source or destination of the frame, nor can the loop cause multiple copies of the initial frame to be delivered to the destination, or to or from any LAN in the network that is not part of the loop.

Loop mitigation does not require that neighboring Bridges assign a given frame to the same active topology; or even that the reception and transmission Ports for that frame have been derived from the same topology calculation within a given Bridge. While this standard specifies the calculation of paths that are reverse path congruent (Clause 3) to support bidirectional communication, that property has no bearing on loop mitigation. As a consequence, the Dynamic Filtering Entries that are used for active topology enforcement (8.6.1) and loop mitigation with SPBM (27.4.1) can be updated one at a time after ISIS-SPB has completed a link state calculation or during the course of that calculation.

6.5.5 Transit delay

The MAC Service introduces a frame transit delay that is dependent on the particular media and MAC method employed. Frame transit delay is the elapsed time between an MA_UNITDATA.request primitive and the corresponding MA_UNITDATA.indication primitive. Elapsed time values are calculated only on SDUs that are successfully transferred.

Since the MAC Service is provided at an abstract interface within an end station, it is not possible to specify precisely the total frame transit delay. It is, however, possible to measure those components of delay associated with media access and with transmission and reception; and the transit delay introduced by an intermediate system, in this case a Bridge, can be measured.

The minimum additional transit delay introduced by a Bridge is the time taken to receive a frame plus that taken to access the media onto which the frame is to be relayed. Note that the frame is completely received before it is relayed as the Frame Check Sequence (FCS) is to be calculated and the frame discarded if in error.

6.5.6 Frame lifetime

The MAC Service ensures that an upper bound to the transit delay is experienced for a particular instance of communication. This maximum frame lifetime is necessary to ensure the correct operation of higher layer protocols. The additional transit delay introduced by a Bridge is discussed in 6.5.5.

To enforce the maximum frame lifetime, a Bridge may be required to discard frames. Since the information provided by the MAC Sublayer to a Bridge does not include the transit delay already experienced by any particular frame, Bridges discard frames to enforce a maximum delay in each Bridge.

The value of the maximum Bridge transit delay is based on both the maximum delays imposed by all Bridges in the network and the desired maximum frame lifetime. A recommended and an absolute maximum value are specified in Table 6-1.

Table 6-1—Bridge transit delay

<table><tr><td>Parameter</td><td>Recommended value</td><td>Absolute maximum</td></tr><tr><td>Maximum Bridge transit delay</td><td>1.0s</td><td>4.0s</td></tr></table>

6.5.7 Undetected frame error rate

The MAC Service introduces a very low undetected frame error rate in transmitted frames. Undetected errors are protected against by the use of an FCS that is appended to the frame by the MAC Sublayer of the source station prior to transmission, and checked by the destination station on reception.

The FCS calculated for a given SDU is dependent on the MAC method employed. It is therefore necessary to recalculate the FCS within a Bridge providing a relay function between IEEE 802 LAN MACs of dissimilar types if differences in the method of calculation and/or the coverage of the FCS, or changes to the data that is within the coverage of the FCS, would lead to a different FCS being calculated for the SDU by the two MAC methods. This introduces the possibility of additional undetected errors arising from the operation of a Bridge. For frames relayed between LANs of the same MAC type, the Bridge shall not introduce an undetected frame error rate greater than that which would have been achieved by preserving the FCS.

NOTE—Application of the techniques described in Annex O allows an implementation to achieve an arbitrarily small increase in undetected frame error rate, even in cases where the data that is within the coverage of the FCS is changed.

6.5.8 Maximum Service Data Unit Size

The Maximum Service Data Unit Size that can be supported by an IEEE 802 LAN varies with the MAC method and its associated parameters (e.g., speed, electrical characteristics). It may be constrained by the owner of the LAN. The Maximum Service Data Unit Size supported by a Bridge between two LANs is the smaller of that supported by the LANs. No attempt is made by a Bridge to relay a frame to a LAN that does not support the size of SDU conveyed by that frame.

6.5.9 Priority

The MAC Service includes priority as a QoS parameter. MA_UNITDATA.request primitives with a high priority may be given precedence over other request primitives made at the same station, or at other stations attached to the same LAN and can give rise to earlier MA_UNITDATA.indication primitives.

The MAC Sublayer maps the requested priority onto the priorities supported by the individual MAC method. The requested priority may be conveyed to the destination station.

The transmission delay experienced by a frame in a Bridge can be managed by associating a priority with the frame.

The transmission delay comprises

a) A queuing delay until the frame becomes first in line for transmission on the Port, in accordance with the procedure for selecting frames for transmission described in 8.6.8;

b) The access delay for transmission of the frame.

Queuing delays can be managed using priority. Access delays can be managed using priority in MAC methods that support more than one priority.

The priority associated with a frame can be signaled by means of the priority signaling mechanisms inherent in some IEEE 802 LAN MAC types. Since not all IEEE 802 LAN MAC types are able to signal the priority associated with a frame, VLAN Bridges regenerate priority based on a combination of signaled information and configuration information held in the Bridge.

The Bridge maps priority values onto one or more traffic classes; Bridges that support more than one traffic class are able to support expedited classes of traffic. The Forwarding Process, 8.6, describes the use of priority and traffic classes in Bridges. Given the constraints placed on frame misordering in a Bridge, as expressed in 6.5.3, the mappings of priority and traffic class are static.

NOTE 1—The term “traffic class,” as used in this standard, is used only in the context of the operation of the priority handling and queuing functions of the Forwarding Process, as described in 8.6. Any other meanings attached to this term in other contexts do not apply to the use of the term in this standard.

The ability to signal priority in IEEE 802 LANs, coupled with a consistent approach to the mapping of priority to traffic classes, and of priority to the priority requested from the individual LAN or supporting service, allows consistent use of priority information to be made, according to the capabilities of the Bridges and MAC methods that are involved in the transmission path.

NOTE 2—This standard defines a frame format and associated procedures that can be used to carry priority information across LAN MAC types that are not able to signal priority.

Under normal circumstances, priority is not modified in transit through the relay function of a Bridge; however, there may be some circumstances where it is desirable for management purposes to control how priority is propagated. The Priority Regeneration Table (Table 6-4) provides the ability to map incoming priority values on a per-Port basis, under management control. In its default state, this table provides an identity mapping from priority values to Regenerated priority values; i.e., by default, the Regenerated priority is identical to the incoming priority.

6.5.10 Throughput

The total throughput provided by a network can be significantly greater than that provided by an equivalent single LAN. Bridges may localize traffic within the network by filtering frames. Filtering services available in bridged networks are described in 6.16.

The throughput between end stations on individual LANs, communicating through a Bridge, can be lowered by frame discard in the Bridge due to the inability to transmit at the required rate on the LAN forming the path to the destination for an extended period.

6.6 Internal Sublayer Service (ISS)

The service primitives and parameters, the status parameters, and the point-to-point parameters of the ISS are specified in IEEE Std 802.1AC.

6.6.1 Control primitives and parameters

The ISS provides two control primitives, an M_CONTROL.request and an M_CONTROL.indication, and their associated parameters.

The M_CONTROL.request primitive has the form:


  M_CONTROL.request (
  destination_address
  opcode
  request_operand_list
  )

The M_CONTROL.indication primitive has the form:


  M_CONTROL.indication (opcode indication_operand_list)

See 36.1.2 for a description of the M_CONTROL parameters used for PFC.

6.7 Support of the ISS by specific MAC procedures

Support of the ISS by MAC Entities that use specific IEEE 802 media access methods is specified in IEEE Std 802.1AC.

6.7.1 Support of the ISS by IEEE Std 802.3 (Ethernet)

In addition to the provisions of 12.1.1 of IEEE Std 802.1AC-2012, an M_CONTROL.request primitive is mapped to an IEEE 802.3 MA_CONTROL.request primitive having the same parameters. An IEEE 802.3 MA_CONTROL.indication primitive is mapped to an M_CONTROL.indication primitive having the same parameters.

6.8 Enhanced Internal Sublayer Service (EISS)

The EISS is derived from the ISS (IEEE Std 802.1AC) by augmenting that specification with elements necessary to the operation of the tagging and untagging functions of a VLAN Bridge (3.259). Within the attached end station, these elements can be considered either to be below the MAC Service boundary, and pertinent only to the operation of the service provider, or to be local matters not forming part of the peer-to-peer nature of the MAC Service.

The EISS provides the same service status and point-to-point parameters as the ISS (IEEE Std 802.1AC).

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
  )

  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—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. Two options for regenerating the FCS under these circumstances are discussed in Annex O.

The vlan_identifier parameter carries the VID.

The flow_hash parameter either is 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 either is 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.

6.8.2 Status parameters

The EISS also makes available the MAC_Enabled and MAC_Operational status parameters that reflect the operational state and administrative controls over each instance of the service provided. The values of these parameters are mapped directly from the values made available by the ISS (IEEE Std 802.1AC).

6.8.3 Point-to-point parameters

The EISS also makes available the operPointToPointMAC and adminPointToPointMAC status parameters that reflect the point-to-point status of each instance of the service provided and provide administrative control over the use of that information. The values of these parameters are mapped directly from the values made available by the ISS (IEEE Std 802.1AC).

6.8.4 Control primitives and parameters

The EISS provides two control primitives, an EM_CONTROL.request and an EM_CONTROL.indication, and their associated parameters. The values of these parameters are mapped directly to/from the values made available by the corresponding ISS primitives (6.6.1).

The EM_CONTROL.request primitive has the form:


  EM_CONTROL.request (
  destination_address
  opcode
  request_operand_list
  )

The EM_CONTROL.indication primitive has the form:


  EM_CONTROL.indication (opcode indication_operand_list)

6.9 Support of the EISS

The EISS is supported by tagging and detagging functions that in turn use the ISS (IEEE Std 802.1AC). Any given instance of the EISS shall be supported by using one but not both of the following VLAN tag types:

a) C-VLAN tag (C-TAG); or

b) S-VLAN tag (S-TAG);

selected as specified in 9.5.

Each Bridge Port shall support the following parameters for use by these functions:

c) an Acceptable Frame Types parameter with at least one of the following values:

1) Admit Only VLAN-tagged frames;

2) Admit Only Untagged and Priority-tagged frames;

3) Admit All frames.

d) a PVID parameter for Port-based VLAN classification;

and may support the following parameter:

e) a VID Set for Port-and-Protocol-based classification (6.12).

f) A VID translation table;

g) An Egress VID translation table.

All three values for Acceptable Frame Types may be supported; if so, they shall be configurable using the management operations defined in Clause 12, and the default shall be Admit All Frames. A frame is treated as Untagged if the initial octets of the mac_service_data_unit parameter do not contain a VLAN tag of the type used to support the EISS (9.5), as Priority-tagged if the value contained in the VID field of the VLAN tag is zero, and as VLAN-tagged if the value is nonzero.

NOTE 1—The VID translation tables are for use only at the edge of administrative or control protocol domains, e.g., Network-Network Interfaces, SPB domains, or Root and Leaf interfaces to a rooted-multipoint service, as described in this standard. Control protocols that are designed for operation through ports where VID translation is permitted (e.g., MSTP, MVRP, CFM) explicitly compensate for the translation of VID values carried within their PDUs. Successful operation and maintenance of Bridged Networks depends on the fact that VID values are not translated at other ports or at ports within the operational span of control protocols that do not recognize translation.

The PVID and VID Set shall contain valid VID values (Table 9-2) and may be configured by management. If they have not been explicitly configured, the PVID shall assume the value of the default PVID defined in Table 9-2 and the VID Set shall be empty.

NOTE 2—The default behavior of a Bridge that supports Port-and-Protocol-based classification is the same as that of a Bridge that supports only Port-based classification, since all the Protocol Group Identifiers in the VID Set for each Port assign the same VID as the PVID.

The VID translation table and Egress VID translation table provide a mapping between “local VID” values and “relay VID” values. The local VID is the value encoded in a VLAN tag header in the initial octets of the mac_service_data_unit parameter of an ISS service primitive (M_UNITDATA.indication or M_UNITDATA.request). The relay VID is the value contained in the vlan_identifier parameter of an EISS service primitive (EM_UNITDATA.indication or EM_UNITDATA.request). The VID translation table may be supported by itself, or in combination with the Egress VID translation table. When only the VID translation table is supported it is used for bidirectional mapping between the local VID and the relay VID in both indication and request service primitives. This enforces a symmetric one-to-one translation (i.e., if local VID A maps to relay VID B then relay VID B will map to local VID A). When both tables are supported the VID translation table is used only for mapping the local VID to a relay VID in indication service primitives, and the Egress VID translation table is used for mapping the relay VID to a local VID in request service primitives. This allows asymmetric and many-to-one translations (e.g., for translating to and from SPVIDs at the edge of an SPT Region). Both tables are configurable by management, and the default configuration maps each value of the local VID to the same value for the relay VID, and vice versa. For Bridge Ports at the boundary of an SPBV SPT Region the tables are dynamically modified by the ISIS-SPB.

6.9.1 Data indications

On receipt of an M_UNITDATA.indication primitive from the ISS, the received frame is discarded if

a) The initial octets of the mac_service_data_unit do not contain a valid VLAN tag header (9.3) of the type used to support the EISS (9.5), and the Acceptable Frame Types is Admit Only VLAN-tagged frames; or

b) The initial octets of the mac_service_data_unit contain a valid VLAN tag header (9.3) of the type used to support the EISS (9.5), and

1) The VID value is FFF, reserved in Table 9-2 for future implementation use; or

2) The VID translation table is supported and the translated VID value (relay VID) is FFF (indicating local discard); or

3) The VID value is 000 (indicating Priority-tagged), and the Acceptable Frame Types is Admit Only VLAN-tagged frames; or

4) The VID value is in the range 001-FFE, and the Acceptable Frame Types is Admit Only Untagged and Priority-tagged frames.

Otherwise, an EM_UNITDATA.indication primitive is invoked, with parameter values determined as follows:

The destination_address, source_address, and frame_check_sequence parameters carry values equal to the corresponding parameters in the received data indication. The values of the remaining parameters are affected by the contents of the tag header if the frame contains a VLAN tag of the type supported by this instance of the EISS.

The value of the mac_service_data_unit parameter is as follows:

c) If the frame is tagged, then the value used is equal to the value of the received mac_service_data_unit following removal of the tag header.

d) Otherwise, the value used is equal to the value of the received mac_service_data_unit.

The value of the vlan_identifier parameter is as follows:

e) The value contained in the VID field, optionally translated using the VID translation table, if the frame is VLAN-tagged;

f) The value of the PVID for the Port, if Port-and-Protocol-based VLAN classification is not supported and the frame is untagged, Priority-tagged, or the VID translation table is supported and the translated VID value (relay VID) is zero;

g) As determined by Port-and-Protocol-based VLAN classification (6.12) if that capability is implemented and the frame is untagged or Priority-tagged or the VID translation table is supported and the translated VID value (relay VID) is zero.

The value of the drop_eligible and priority parameters are determined as follows:

h) If the frame is tagged, the value of the drop_eligible parameter and the received priority value are decoded from the tag header as described in 6.9.3. Otherwise,

i) The received priority value and the drop_eligible parameter value are the values in the M_UNITDATA.indication.

j) The value of the priority parameter is then regenerated from the received priority, as specified in 6.9.4.

6.9.2 Data requests

On invocation of an EM_UNITDATA.request primitive by a user of the EISS, the frame is discarded if the Egress VID translation table is supported and the translated VID value (local VID) is FFF (reserved in Table 9-2). Otherwise, an M-UNITDATA.request primitive is invoked, with parameter values as follows:

The destination_address, source_address, drop_eligible, and priority parameters carry values equal to the corresponding parameters in the received data request.

Unless the Bridge Port is a member of the untagged set (8.8.2) for the VID identified by the vlan_identifier parameter, then a tag header, formatted as necessary for the destination MAC type, is inserted as the initial octets of the mac_service_data_unit parameter. The values of the vlan_identifier (optionally translated using the VID translation table or Egress VID translation table), priority, and drop_eligible parameters are used to determine the contents of the tag header, in accordance with Clause 9.

If the Bridge Port is a member of the untagged set (8.8.2) for the VID identified by the vlan_identifier parameter, no tag header is inserted.

The remaining octets of the mac_service_data_unit parameter are those accompanying the EISS-request. If the data request is a consequence of relaying a frame and the MAC type of the Port differs from that used to receive the frame, they are modified, if necessary, in accordance with the procedures described in ISO/IEC 11802-5, IETF RFC 1042 (1988), and IETF RFC 1390.

The value of the frame_check_sequence parameter is determined as follows:

a) If the frame_check_sequence parameter received in the data request either is unspecified or still carries a valid value, then that value is used.

b) Otherwise, the value used is either unspecified or derived from the received FCS information by modification to take account of the conditions that have caused it to become invalid.

6.9.3 Priority Code Point encoding

The priority and drop_eligible parameters are encoded in the 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. For each Port, the Priority Code Point Encoding Table has 16 entries, corresponding to each of the possible combinations of the eight possible values of priority (0 through 7) with the two possible values of drop_eligible (True or False). For each Port, the Priority Code Point Decoding Table has 8 entries, corresponding to each of the possible PCP values.

Alternative values for each table are specified as rows in Table 6-2 and Table 6-3, with each alternative labeled by the number of distinct priorities that can be communicated, and the number of these for which drop precedence can be communicated. For example, the table entries 6P2D allow six distinct priorities with drop precedence for two. The default values (8P0D) specify a PCP value equal to the priority value and do not support communication of drop precedence in the PCP field. The combination of the priority and drop_eligible parameters is shown by the priority alone if drop_eligible is False, and by the priority followed by the letters “DE” if drop_eligible is True.

If the VLAN tag is an S-TAG, then Table 6-2 and Table 6-3 shall be supported. If the VLAN tag is a C-TAG, then the 8P0D row of each table shall be supported, and the remaining rows may be supported.

NOTE—To avoid potential misordering of packets, all Ports on a LAN should select the same row of Table 6-2 and Table 6-3. Interoperability considerations with Bridges supporting only the 8P0D row are discussed in I.8.

Table 6-2—Priority Code Point encoding

<table><tr><td colspan="2">priority drop_eligible</td><td>7</td><td>7DE</td><td>6</td><td>6DE</td><td>5</td><td>5DE</td><td>4</td><td>4DE</td><td>3</td><td>3DE</td><td>2</td><td>2DE</td><td>1</td><td>1DE</td><td>0</td><td>0DE</td></tr><tr><td rowspan="4">PCP</td><td>8P0D (default)</td><td>7</td><td>7</td><td>6</td><td>6</td><td>5</td><td>5</td><td>4</td><td>4</td><td>3</td><td>3</td><td>2</td><td>2</td><td>1</td><td>1</td><td>0</td><td>0</td></tr><tr><td>7P1D</td><td>7</td><td>7</td><td>6</td><td>6</td><td>5</td><td>4</td><td>5</td><td>4</td><td>3</td><td>3</td><td>2</td><td>2</td><td>1</td><td>1</td><td>0</td><td>0</td></tr><tr><td>6P2D</td><td>7</td><td>7</td><td>6</td><td>6</td><td>5</td><td>4</td><td>5</td><td>4</td><td>3</td><td>2</td><td>3</td><td>2</td><td>1</td><td>1</td><td>0</td><td>0</td></tr><tr><td>5P3D</td><td>7</td><td>7</td><td>6</td><td>6</td><td>5</td><td>4</td><td>5</td><td>4</td><td>3</td><td>2</td><td>3</td><td>2</td><td>1</td><td>0</td><td>1</td><td>0</td></tr></table>

Table 6-3—Priority Code Point decoding

<table><tr><td colspan="2">PCP</td><td>7</td><td>6</td><td>5</td><td>4</td><td>3</td><td>2</td><td>1</td><td>0</td></tr><tr><td rowspan="4"><eq>priority</eq> drop eligible</td><td>8P0D (default)</td><td>7</td><td>6</td><td>5</td><td>4</td><td>3</td><td>2</td><td>1</td><td>0</td></tr><tr><td>7P1D</td><td>7</td><td>6</td><td>4</td><td>4DE</td><td>3</td><td>2</td><td>1</td><td>0</td></tr><tr><td>6P2D</td><td>7</td><td>6</td><td>4</td><td>4DE</td><td>2</td><td>2DE</td><td>1</td><td>0</td></tr><tr><td>5P3D</td><td>7</td><td>6</td><td>4</td><td>4DE</td><td>2</td><td>2DE</td><td>0</td><td>0DE</td></tr></table>

The values in the Priority Code Point Encoding Table and Priority Code Point Decoding Table may be modified by management, as described in Clause 12. If this capability is provided, the value of the table entries shall be independently settable for each Port. The values shall be constrained as follows:

a) For any two priority values with the same drop_eligible value, the lower priority shall not map to a higher PCP than the higher priority.

b) The lower of any two PCP values shall not map to a higher priority than the higher PCP.

c) With the exception of values 0 and 1, any priority value combined with drop_eligible True shall not map to a higher PCP than the same priority value combined with drop_eligible False.

d) With the exception of values 0 and 1, any PCP value shall not map to a priority value combined with drop_eligible True if a lower PCP maps to the same priority value combined with drop_eligible False.

The values may be further constrained, but if the tables can be modified, the default values shown in Table 6-2 and Table 6-3, and the alternative sets of values in Table 6-2 and Table 6-3 shall be settable.

The drop_eligible parameter may also be encoded in and decoded from the Drop Eligible Indicator (DEI) in the VLAN tag. Use of the DEI allows the VLAN tag to convey eight distinct priorities, each with a DEI. If this capability is provided, it shall be independently manageable for each Port by means of a Use_DEI parameter. If the Use_DEI is True for the Port, the drop_eligible parameter is encoded in the DEI of transmitted frames, and the drop_eligible parameter shall be True for a received frame if the DEI is set in the VLAN tag or the Priority Code Point Decoding Table indicates drop_eligible True for the received PCP value. If the Use_DEI parameter is False, the DEI shall be transmitted as zero and ignored on receipt. The default value of the Use_DEI parameter is False.

6.9.4 Regenerating priority

The priority of each received frame is regenerated using priority information contained in the frame and the Priority Regeneration Table for the reception Port. For each reception Port, the Priority Regeneration Table has eight entries, corresponding to the eight possible values of priority (0 through 7). Each entry specifies, for the given value of received priority, the corresponding regenerated value.

For untagged frames, the priority parameter signaled in the corresponding M_UNITDATA.indication is taken to be the received priority. For tagged frames, the priority signaled in the PCP field of the tag header is taken to be the received priority.

NOTE 1—IEEE 802 LAN technologies signal a maximum of eight priority values. Annex I further explains the use of priority values and how they map to traffic classes.

Table 6-4 specifies default regenerated priority values for each of the eight possible values of the received priority. These default values shall be used as the initial values of the corresponding entries of the Priority Regeneration Table for each Port.

The values in the Priority Regeneration Table may be modified by management, as described in Clause 12. If this capability is provided, the value of the table entries shall be independently settable for each reception Port and for each value of received priority, and the Bridge shall have the capability to use the full range of values in the parameter ranges specified in Table 6-4.

NOTE 2—The regeneration and mapping of priority within the Bridge should be consistent with the end-to-end significance of that priority across the rest of the Bridged Network. The regenerated priority value is used:

— Via the traffic class table (8.6.6) to determine the traffic class for a given outbound Port, and

— Via fixed, MAC type-specific mappings (IEEE Std 802.1AC) to determine the access priority that will be used for certain media access methods.

Table 6-4—Priority regeneration

<table><tr><td>Received priority</td><td>Default regenerated priority</td><td>Range</td></tr><tr><td>0</td><td>0</td><td>0–7</td></tr><tr><td>1</td><td>1</td><td>0–7</td></tr><tr><td>2</td><td>2</td><td>0–7</td></tr><tr><td>3</td><td>3</td><td>0–7</td></tr><tr><td>4</td><td>4</td><td>0–7</td></tr><tr><td>5</td><td>5</td><td>0-7</td></tr><tr><td>6</td><td>6</td><td>0–7</td></tr><tr><td>7</td><td>7</td><td>0–7</td></tr></table>

In Bridges that support SRP, an SRP domain boundary port priority regeneration override table is maintained for each reception Port. This table associates a priority value with each SR class supported by the Bridge, and specifies the priority value to be used as the regenerated priority, in preference to the value in the

Priority Regeneration table, when the SRPdomainBoundaryPort parameter (35.1.4) for that SR class has the value TRUE. Table 6-5 specifies the default values for priority and regenerated priority for two SR classes, SR class A and SR class B. In cases where only SR class B is supported, only the default value shown in the table for SR Class B is used.

Table 6-5—Default SRP domain boundary port priority regeneration override values

<table><tr><td>SR class</td><td>Default priority</td><td>Default regenerated priority for SRP domain boundary Ports</td><td>Range</td></tr><tr><td>A</td><td>3</td><td>0</td><td>0–7</td></tr><tr><td>B</td><td>2</td><td>0</td><td>0–7</td></tr></table>

The priority values contained in the SRP domain boundary port priority regeneration override table may be modified by management, as described in Clause 12. If this capability is provided, the value of the table entries shall be independently settable for each reception Port and for each supported SR class, and the Bridge shall have the capability to use the full range of values in the parameter ranges specified in Table 6-5.

NOTE 3—The default values specified for the SRP domain boundary port Priority Regeneration Table map inbound PCP values onto the next lowest priority that is available, leaving the remaining priority values unchanged. The consequence of this remapping is that traffic entering an SRP domain that carries the priority value associated with that domain is forwarded by the Bridge at the domain boundary using a lower priority. There is no means of mapping these priority values back to their original values as frames exit from an SRP domain. The default mappings are based on the assumption that normally, two SR classes (A and B) are used to support traffic for which bandwidth has been reserved; if only the lower class (B) is supported, then the default override value for the unsupported A class does not apply.

NOTE 4—The ability for the priority regeneration table to be freely modified by management means that it is possible to create mappings that result in reserved and nonreserved traffic sharing the same priority. This will have unpredictable effects upon the behavior of the network with respect to the worst-case latency that can be assumed for reserved traffic.

6.10 Support of the ISS/EISS by PIPs

Each PIP on a BEB uses a single ISS-SAP (IEEE Std 802.1AC) and the I-TAG (9.5) to provide a separate Bridge Port (the VIP) for each backbone service instance configured for the PIP. Each VIP supports either the VLAN-unaware MAC Relay Entity of a T-component or the VLAN-aware MAC Relay Entity of an I-component. A single VIP ISS-SAP is provided to a T-component. An I-component uses an EISS-SAP, supported by its own instance of the functions specified in 6.9 with the S-TAG (9.5), for each VIP ISS-SAP. See Figure 6-2.

The EISS of each Virtual Instance Port (VIP-EISS) shall be supported by an instance of the functions of 6.9 using the S-TAG type (9.5). The ISS of all of the Virtual Instance Ports (VIP-ISS) shall be supported by a single instance of the functions specified in this subclause using the I-TAG type (9.5).

NOTE 1—Higher Layer Entities may interface to any VIP and/or the PIP at the Service Access Points (SAPs) represented by any VIP-ISS and/or the PIP-ISS using the Bridge Port Connectivity specified in 8.5.1. Protocol shims such as CFM MPs may interface at any VIP-EISS using the EISS Multiplex Entity specified in 6.17, or at the PIP-ISS using the Backbone Service Instance Multiplex Entity specified in 6.18. Figure 26-2 shows a PIP with both Bridge Port Connectivity and CFM shims.

Each PIP shall have an individual Backbone Media Access Control (B-MAC) address referred to as the PIP MAC address (26.4) for use by the functions specified in this subclause.

!image

I-component

!image

T-component

Figure 6-2—Provider Instance Ports (PIPs)

Each VIP shall support the following parameters for use by these functions:

a) A VIP-ISID parameter for the I-SID of the backbone service instance associated with this VIP;

b) A Default Backbone Destination;

c) An adminPointToPointMAC;

d) An enableConnectionIdentifier.

The VIP-ISID shall contain a valid I-SID value (9.7), which is configured by management.

The Default Backbone Destination parameter contains a MAC address to be used in the destination_address parameter of an M_UNITDATA.request at the PIP-ISS when a backbone destination address cannot be derived from the connection_identifier parameter of the M_UNITDATA.request from the VIP-ISS. The default value of the Default Backbone Destination is the Backbone Service Instance Group address for the VIP-ISID (generated by concatenating the Provider Backbone Bridge (PBB) organizationally unique identifier (OUI) with the VIP-ISID value as specified in 26.4).

The adminPointToPointMAC parameter of the VIP-ISS reflects the point-to-point status of the backbone service instance associated with the VIP. The default value of the adminPointToPointMAC parameter is ForceFalse. The value may be configured by management to ForceTrue when instantiating a VIP for a point-to-point backbone service instance. A value of ForceFalse or Auto results in a operPointToPointMAC value of FALSE; a value of ForceTrue results in a operPointToPointMAC value of TRUE. Whenever the operPointToPointMAC parameter transitions to FALSE, the value for the Default Backbone Destination parameter is set to the Backbone Service Instance Group address for the VIP-ISID. When the operPointToPointMAC parameter is TRUE, the Default Backbone Destination parameter is modified by subsequent M_UNITDATA.indications as specified in 6.10.1 (and described in 26.4.1).

The enableConnectionIdentifier parameter allows the VIP to use the connection_identifier parameter to learn associations between a B-MAC address and a Customer Media Access Control (C-MAC) address. The default value is TRUE. This parameter should be configured to FALSE at the root node of a point-to-multipoint TESI.

NOTE 2—There is a 1:1 relationship between a given value of the connection_identifier and a B-MAC address. This level of indirection is provided to allow the use of the connection_identifier parameter for other purposes by other types of Bridge Ports. The relationship between a given connection_identifier value and a B-MAC address is maintained as long as any FDB entry contains this value for the connection_identifier. No ageing mechanism other than that specified for Dynamic Filtering Entries is implied.

6.10.1 Data indications

On receipt of an M_UNITDATA.indication primitive from the PIP-ISS, if the PIP is congestion aware (5.4.1.4) and the initial octets of the mac_service_data_unit contain a valid CNM encapsulation, the received frame is processed according to 32.16. Otherwise, the received frame shall be discarded if

a) The initial octets of the mac_service_data_unit do not contain a valid I-TAG header; or

b) The Use Customer addresses (UCA) bit in the I-TAG is not zero; or

c) The Res2 field in the I-TAG is not zero; or

d) The I-SID value in the I-TAG does not match the VIP-ISID parameter for one of the VIPs supported by this PIP; or

e) The destination_address parameter of the received M_UNITDATA.indication primitive does not match one of the following:

1) The PIP MAC address; or

2) A Backbone Service Instance Group address; or

3) The broadcast address.

NOTE 1—The generation of I-tagged frames specified in 6.10.2 and the allowed manipulation of backbone addresses specified in 6.11 never result in an I-tagged frame with a broadcast destination address. The broadcast address is included in the previous list on the principle that the broadcast address is a valid address at any reception port by definition.

The received frame may be discarded if

f) The source_address parameter of the received M_UNITDATA.indication primitive is the PIP MAC address.

Otherwise, an M_UNITDATA.indication primitive is invoked at the VIP-ISS with a VIP-ISID value matching the I-SID in the I-TAG. The parameter values of the indication are determined as follows:

The destination_address parameter contains the value of the encapsulated C-DA field of the I-TAG.

The source_address parameter contains the value of the encapsulated C-SA field of the I-TAG.

If enableConnectionIdentifier is TRUE, then the connection_identifier parameter references the value of the source_address parameter (B-SA) of the M_UNITDATA.indication primitive received from the PIP-ISS; otherwise, the connection_identifier parameter is null. The connection_identifier parameter in the M_UNITDATA.indication primitive received from the PIP-ISS is ignored.

NOTE 2—The connection_identifier has only local significance meaning that it is used only at a specific PIP. The only requirement imposed by this subclause is that the connection_identifier uniquely identifies an individual B-MAC address. Whether the connection_identifier takes the value of that address, or a value from which that address can be determined, is an implementation decision that is not externally observable.

If the value of the operPointToPointMAC parameter of the VIP-ISS is TRUE, then the Default Backbone Destination parameter is set to the value of the source_address parameter of the M_UNITDATA.indication primitive.

The service_access_point_identifier parameter contains a value that uniquely identifies the VIP within the I-component. This is a local value that is used only within the I-component, and is used by the relay functions (Clause 8) as the port number of the VIP. The service_access_point_identifier parameter received in the M_UNITDATA.indication primitive is ignored.

The value of the drop_eligible and priority parameters are decoded from the I-PCP and I-DEI fields of the I-TAG as described in 6.10.3.

The value of the mac_service_data_unit parameter is the value of the received mac_service_data_unit following the removal of the I-TAG.

The value of the frame_check_sequence parameter is either unspecified or derived from the received FCS information modified to take into account the changes to the frame.

6.10.2 Data requests

On invocation of an M_UNITDATA.request primitive at any VIP-ISS, an M_UNITDATA.request primitive is invoked at the PIP-ISS, with parameter values as follows:

If enableConnectionIdentifier is TRUE, the connection_identifier is not null, and the connection_identifier references an address retained by the PIP, then the value for the destination_address is the address referenced by the connection_identifier. Otherwise, the value for the destination_address is the contents of the Default Backbone Destination parameter of the VIP.

The value for the source_address is the PIP MAC address.

The priority and drop_eligible parameters carry the same value as the corresponding parameter in the VIP-ISS request.

The connection_identifier parameter is NULL.

The mac_service_data_unit parameter is constructed from the mac_service_data_unit of the M_UNITDATA.request primitive from the VIP-ISS by prepending an I-TAG as follows:

a) The encapsulated C-SA field is the value of the source address parameter of the VIP-ISS request;

b) The encapsulated C-DA field is the value of the destination_address parameter of the VIP-ISS request;

c) The UCA, Res1, and Res2 fields are all zero;

d) The I-SID field is the value contained in the VIP-ISID parameter;

e) The I-PCP and I-DEI fields are encoded from the priority and drop_eligible parameters of the VIP-ISS request as specified in 6.10.3.

The value of the frame_check_sequence parameter is either unspecified or derived from the received FCS information modified to take into account the changes to the frame.

6.10.3 Priority Code Point encoding

The encoding (and decoding) of the I-PCP and I-DEI fields from (to) the priority and drop_eligible parameters is accomplished using a Priority Code Point Encoding Table (and Priority Code Point Decoding Table) as described in 6.9.3.

6.11 Support of the EISS by CBPs

The functions specified in this subclause replace the functions specified in 6.9 when the EISS is supported by a CBP in a BEB (Clause 25). See Figure 6-3. The functions specified in this subclause use a single instance of the ISS (IEEE Std 802.1AC) and provide a single instance of the EISS. The EISS shall be supported by functions using both the S-TAG and the I-TAG as specified in 9.5.

NOTE 1—Although the CBP does not transmit or receive S-tagged frames, it supports the S-TAG type in the sense that it is a port on an S-VLAN component and the vlan_identifier parameter contains a S-VID.

!image

Figure 6-3—B-Component CBP

NOTE 2—Higher Layer Entities may interface to the CBP at the SAP represented by the ISS using the Bridge Port Connectivity specified in 8.5.1. Protocol shims such as CFM MPs may interface at the EISS using the EISS Multiplex Entity specified in 6.17, or at the ISS using the Backbone Service Instance Multiplex Entity specified in 6.18. Figure 26-2 shows a CBP with both Bridge Port Connectivity and CFM shims.

The CBP shall support the following parameters for use by these functions:

a) A PVID parameter for Port-based B-VLAN classification;

b) A Backbone Service Instance table.

The PVID shall contain a valid VID value (Table 9-2) and may be configured by management. If it has not been explicitly configured, the PVID shall assume the value of the default PVID defined in Table 9-2.

The Backbone Service Instance table is configurable by management and has one entry for each backbone service instance supported on the CBP. The Backbone Service Instance table is used to filter frames containing an I-SID value that is not configured on this CBP. It may also be used to provide backbone service instance-specific assignment of a B-VID, to translate I-SID values, and/or to translate backbone destination addresses. Entries in the Backbone Service Instance table may be set automatically by the protection switching procedures described in 26.10.3.4. The Backbone Service Instance table shall contain the following field for each entry:

c) Backbone-SID (I-SID). This contains the identifier used in the backbone network for the backbone service instance.

The Backbone Service Instance table may also contain one or more of the following additional fields for each entry:

d) B-VID (Backbone VLAN Identifier). If the B-VID field is supported, it shall contain a valid VID value (Table 9-2) for that backbone service instance. The default value is the same as the PVID.

e) Local-SID (Local Service Instance Identifier). This field is used to perform a bidirectional 1:1 mapping between the Backbone-SID (contained in the I-TAG in the mac_service_data_unit at the

EISS) and the Local-SID (contained in the I-TAG in the mac_service_data_unit at the ISS). The default value of the Local-SID field is the value of the Backbone-SID field.

f) Default Backbone Destination. If this field is present, it is used as the destination_address in the EISS indication when the destination_address parameter of the ISS indication is the Backbone Service Instance Group address. It allows the backbone provider to replace the Backbone Service Instance Group address with an individual or group address to limit the distribution of the frame within a B-VLAN. The default value is the Backbone Service Instance Group address.

NOTE 3—If a CBP is associated with a TESI the Default Backbone Destination field and the B-VID field is supported.

6.11.1 Data indications

On receipt of an M_UNITDATA.indication primitive from the ISS, the received frame shall be discarded if

a) The initial octets of the mac_service_data_unit do not contain a valid I-TAG; or

b) The Res2 field in the I-TAG is not zero; or

c) The Local-SID field of the Backbone Service Instance table is supported and the I-SID value in the I-TAG does not match the Local-SID value in any entry in the Backbone Service Instance table; or

d) The Local-SID field of the Backbone Service Instance table is not supported and the I-SID value in the I-TAG does not match the Backbone-SID value in any entry in the Backbone Service Instance table.

Otherwise, an EM_UNITDATA.indication primitive is invoked at the EISS with parameter values determined using one entry in the Backbone Service Instance table. If the Local-SID field of the Backbone Service Instance table is supported then the entry with a Local-SID value that matches the I-SID value in the I-TAG is selected. Otherwise, the entry with a Backbone-SID value that matches the I-SID value in the I-TAG is selected. The parameter values are then determined as follows:

The mac_service_data_unit parameter is determined as follows:

e) If the Local-SID field of the Backbone Service Instance table is supported, then value of the mac_service_data_unit parameter is the value of the mac_service_data_unit parameter of the ISS indication modified by replacing the value of the I-SID field in the I-TAG with the value of Backbone-SID field in the selected Backbone Service Instance table entry;

f) Otherwise, the mac_service_data_unit parameter contains the same value as the mac_service_data_unit parameter of the ISS indication.

The destination_address parameter is determined as follows:

g) If the destination_address in the ISS indication is the Backbone Service Instance Group address and the Default Backbone Destination field of the Backbone Service Instance table is supported, then the destination_address parameter is the Default Backbone Destination value in the selected Backbone Service Instance table entry;

h) Otherwise, if the destination_address in the ISS indication is the Backbone Service Instance Group address and the Local-SID field of the Backbone Service Instance table is supported, then the destination_address parameter is the Backbone Service Instance Group address constructed using the Backbone-SID value in the selected Backbone Service Instance table entry;

i) Otherwise, the destination_address parameter contains the same value as the destination_address parameter of the ISS indication.

The source_address parameter contains the same value as the source_address parameter of the ISS indication.

The value of the vlan_identifier parameter is determined as follows:

j) If the B-VID field of the Backbone Service Instance table is supported, then the vlan_identifier parameter contains the B-VID value in the selected Backbone Service Instance table entry;

k) Otherwise, the vlan_identifier parameter contains the value of the PVID parameter.

The value of the drop_eligible and priority parameters are determined as follows:

1) The value of the drop_eligible parameter and the received_priority value are decoded from the I-DEI and the I-PCP fields of the I-TAG in the mac_service_data_unit as described in 6.11.3;

m) The value of the priority parameter is then regenerated from the received_priority value, as specified for the received_priority in 6.11.4.

The value of the frame_check_sequence parameter is either unspecified or derived from the received FCS information modified as necessary to take into account changes to the frame.

6.11.2 Data requests

On invocation of an EM_UNITDATA.request primitive by a user of the EISS, the frame shall be discarded if

a) The initial octets of the mac_service_data_unit do not contain a valid I-TAG;

b) The Res2 field in the I-TAG is not zero;

c) The I-SID value in the I-TAG does not match the Backbone-SID value in any of the entries in the Backbone Service Instance table.

Otherwise, an M_UNITDATA.request primitive is invoked, with parameter values determined using the Backbone Service Instance table entry with a Backbone-SID value that matches the I-SID value in the I-TAG. The parameter values are determined as follows:

The value of the mac_service_data_unit parameter is determined as follows:

d) If the Local-SID field of the Backbone Service Instance table is supported, then mac_service_data_unit parameter contains the value of the mac_service_data_unit parameter of the EISS request modified by replacing the I-SID in the I-TAG with the Local-SID value in the selected Backbone Service Instance table entry;

e) Otherwise, the mac_service_data_unit parameter contains the same value as the mac_service_data_unit parameter of the EISS request.

The destination_address parameter is determined as follows:

f) If the Local-SID field of the Backbone Service Instance table is supported and the destination_address in the EISS request is the address of this CBP, or is a group address, then the destination_address parameter is the Backbone Service Instance Group address constructed from the Local-SID value in the selected Backbone Service Instance table entry;

g) If the Local-SID field of the Backbone Service Instance table is not supported and the destination_address in the EISS request is the address of this CBP, or is a group address, then the destination_address parameter is the Backbone Service Instance Group address constructed from the Backbone-SID value in the selected Backbone Service Instance table entry;

h) Otherwise, the destination_address parameter contains the same value as the destination_address parameter of the EISS request.

The source_address parameter contains the same value as the source_address parameter of the EISS request.

The priority and drop_eligible parameters carry the same value as the corresponding parameter in the EISS request.

The value of the frame_check_sequence parameter is either unspecified or derived from the received FCS information modified to take into account any changes to the frame.

6.11.3 Priority Code Point decoding

The decoding of the I-PCP and I-DEI fields to the priority and drop_eligible parameters is accomplished using a Priority Code Point Decoding Table as described in 6.9.3.

6.11.4 Regenerating priority

The priority of received frames is regenerated using priority information contained in the I-PCP and the Priority Regeneration table for the reception Port. For each reception Port, the Priority Regeneration table has eight entries, corresponding to the eight possible values of priority (0 through 7). Each entry specifies, for the given value of received_priority, the corresponding regenerated value. The priority decoded from the I-PCP field of the I-TAG is taken to be the received_priority.

NOTE—IEEE 802 LAN technologies signal a maximum of eight priority values. Annex I further explains the use of priority values and how they map to traffic classes.

Table 6-4 specifies default regenerated priority values for each of the eight possible values of the received_priority. These default values shall be used as the initial values of the corresponding entries of the Priority Regeneration table for each Port. The table may be configured as described in 6.9.4.

6.12 Protocol VLAN classification

Each instance of the tagging and detagging functions that supports the EISS (6.9), and implements the optional Port-and-Protocol-based VLAN classification, shall implement a VID Set, each member of which associates values of a Protocol Group Identifier (6.12.2) with a VID. Each Untagged and Priority-tagged frame received is assigned a vlan_identifier equal to the VID Set value for the reception Port and the Protocol Group Identifier selected by matching the received frame with a Protocol Template. See Figure 6-4.

The detagged_frame_type parameter indicates the frame format. Its value is determined as follows:

a) If the frame is Untagged or Priority-tagged, this parameter is present and indicates the link-layer encapsulation format of the Detagged Frame. The Detagged Frame of an Untagged Frame is the frame itself. The Detagged Frame of a Tagged Frame or Priority-tagged Frame is the frame that results from untagging the frame in accordance with the frame format described in Clause 9. The value of detagged_frame_type is as follows:

1) Ethernet, if the Detagged Frame uses EtherType-encapsulated IEEE 802.3 format.

2) RFC_1042, if the Detagged Frame is of the format specified by 10.5 in IEEE Std 802-2001 for the encoding of an IEEE 802.3 EtherType Field in an ISO/IEC 8802-2/SNAP header (this supersedes the original definition, which appeared in IETF RFC 1042 (1988)).

3) SNAP_Other, if the Detagged Frame contains an LLC UI PDU with DSAP and SSAP fields equal to the LLC address reserved for SNAP and the 5-octet Subnetwork Access Protocol (SNAP) Protocol Identifier (PID) value is not in either of the ranges used for RFC_1042 above.

4) LLC_Other, if the Detagged Frame contains both a DSAP and an SSAP address field in the positions specified by ISO/IEC 8802-2 Logical Link Control, but is not any of the formats described for LLC frames above.

b) Else the parameter is not present.

!image

NOTE—The PID shown in this figure is a Protocol Identifier, as defined in 5.3 of IEEE Std 802. It is a 5-octet value, consisting of a 3-octet OUI or Company Identifier (CID) value followed by a 2-octet locally administered identifier.

Figure 6-4—Example of operation of Port-and-Protocol-based classification

The EtherType value is present if the detagged_frame_type parameter is present and has the value Ethernet or RFC_1042. Its value is the value of the IEEE 802.3 Length/Type Field present in the Detagged Frame. The value is determined as follows:

c) If the detagged_frame_type parameter is present and has the value Ethernet or RFC_1042, then this parameter is present and has the value of the IEEE 802.3 EtherType Field present in the Detagged Frame.

d) Else the parameter is not present.

The llc_saps parameter is present if the detagged_frame_type parameter is present and has the value LLC_Other. Its value is determined as follows:

e) If the detagged_frame_type parameter is present and has the value LLC_Other, then this parameter is present and its value is the pair of LLC ISO/IEC 8802-2 DSAP and SSAP address field values.

f) Else the parameter is not present.

NOTE 1—A frame that is encapsulated using values of hex FF/FF in the position where an LLC header is to be expected (as defined by ISO/IEC 8802-2) is known as a “Novell IPX Raw” encapsulation. Such frames do not conform to ISO/IEC 8802-2, in that they do not include some of the other required LLC fields. For the purposes of this standard, they are treated as LLC_Other, regardless of whether they are legal LLC frames.

NOTE 2—Bridges are not required, for the purposes of this standard, to completely verify whether the format of frames meets ISO/IEC 8802-2. They are required only to recognize the DSAP and SSAP fields of such frames.

The snap_pid parameter is present if the detagged_frame_type parameter is present and has the value SNAP_Other. Its value is determined as follows:

g) If the detagged_frame_type parameter is present and has the value SNAP_Other, then the parameter is present and its value is the contents of the 5 octets following the LLC header, i.e., the PID field.

h) Else the parameter is not present.

6.12.1 Protocol Templates

In a Bridge that supports Port-and-Protocol-based VLAN classification, a Protocol Template is a tuple that specifies a protocol to be identified in received frames. A Protocol Template has one of the following formats:

a) A value “Ethernet” and a 16-bit IEEE 802.3 EtherType Field value

b) A value "RFC_1042" and a 16-bit IEEE 802.3 EtherType Field value

c) A value "SNAP Other" and a 40-bit PID value

d) A value “LLC_Other” and a pair of ISO/IEC 8802-2 LSAP values: DSAP and SSAP

A Protocol Template matches a frame if

e) The frame's detagged_frame_type is Ethernet, the Protocol Template is of type Ethernet, and the frame's IEEE 802.3 EtherType Field is equal to the value of the IEEE 802.3 EtherType Field of the Protocol Template, or

f) The frame's detagged_frame_type is RFC_1042, the Protocol Template is of type RFC_1042 and the frame's IEEE 802.3 EtherType Field is equal to the IEEE 802.3 EtherType Field of the Protocol Template, or

g) The frame's detagged_frame_type is SNAP_Other, the Protocol Template is of type SNAP_Other, and the frame's snap_pid is equal to the PID of the Protocol Template, or

h) The frame's detagged_frame_type is LLC_Other, the Protocol Template is of type LLC_Other, and the frame's llc_saps matches the value of the DSAP and SSAP of the Protocol Template.

NOTE—If a port does not support Protocol Templates of the frame's detagged_frame_type, then no match will occur.

6.12.2 Protocol Group Identifiers

A Bridge that supports Port-and-Protocol-based VLAN classification shall support Protocol Group Identifiers.

A Protocol Group Identifier, shown as “Group Id” in Figure 6-4, designates a group of protocols that will be associated with one member of the VID Set of a Port. The association of protocols into groups is established by the contents of the Protocol Group Database, as described in 6.12.3. The identifier has scope only within a single Bridge.

An implicit Protocol Group Identifier is assigned to frames that match none of the entries in the Protocol Group Database. Therefore, every incoming frame can be assigned to a Protocol Group Identifier.

6.12.3 Protocol Group Database

A Bridge that supports Port-and-Protocol-based VLAN classification shall support a single Protocol Group Database. The Protocol Group Database groups together a set of one or more Protocols by assigning them the same Protocol Group Identifier (6.12.2). Each entry of the Protocol Group Database comprises the following:

a) A Protocol Template

b) A Protocol Group Identifier

The Protocol Group Database specifies a mapping from Protocol Templates to Protocol Group Identifiers. If two entries of the Protocol Group Database contain different Protocol Group Identifiers, then their Protocol Templates must also be different.

The entries of the Protocol Group Database may be configured by management. A Bridge that supports Port-and-Protocol-based VLAN classification shall support at least one of the Protocol Template formats.

An implicit Protocol Group Database entry exists that matches all frames. This entry is invoked for frames that do not match the template of any of the other entries. It references an implicit Protocol Group Identifier that selects the PVID on each port. In this way, it is ensured that all incoming frames are matched by a Protocol Group Identifier and, hence, are assigned to a VID.

NOTE—If there are no entries in the Protocol Group Database, then the frame relay behavior of this Bridge is identical to the frame relay behavior of a Bridge having the same number of Ports that supports only Port-based VLAN classification.

6.13 Support of the ISS for attachment to a PBN

This standard specifies both Customer Bridges (3.24) and Provider Bridges (3.169). The operation of Provider Bridges and PBNs is, by design, largely transparent to Customer Bridges and Customer Bridged Networks (CBNs). Figure 15-1 illustrates the relationship of the service provided by the MAC Sublayer functionality of Provider Bridges to that used by a Customer Bridge. This subclause enables a mechanism for a Customer Bridge attached to a PBN to request priority handling of frames.

The functions specified in this subclause provide the ISS to the MAC Relay Entity of a Customer Bridge by making use of the underlying ISS provided by the Media Access Method Convergence function as shown in Figure 6-5. These functions shall be one of the following:

a) When Service Access Priority Selection is disabled, the functions shall be null; i.e., each M_UNITDATA.request received from the provided ISS results in an M_UNITDATA.request with identical parameters presented to the underlying ISS, and each M_UNITDATA.indication received from the underlying ISS results in an M_UNITDATA.indication with identical parameters presented to the provided ISS.

b) When Service Access Priority Selection is enabled, the mac_service_data_unit in each M_UNITDATA.request is Priority-tagged with an S-TAG header when presented to the underlying ISS, and if an S-TAG header is present in the mac_service_data_unit parameter in an M_UNITDATA.indication received from the underlying ISS, the S-TAG header is removed before the M_UNITDATA.indication is presented to the provided ISS.

!image

Figure 6-5—Service access priority selection

Specification of a null function allows a Customer Bridge without additional functionality to connect to a PBN.

Specification of the Service Access Priority Selection function allows the Customer Bridge Port to request priority handling of the frame from a Port-based service interface (15.3) to a PBN on the basis of the priority assigned within the CBN, while allowing for differences in cost and service level ascribed to individual values of priority within the service provider and customer networks.

6.13.1 Data requests

For each M_UNITDATA.request received from the provided ISS, an M_UNITDATA.request is presented to the underlying ISS with the following parameters:

The destination_address, source_address, and priority parameters are unchanged.

A tag header, formatted as necessary for the destination MAC type, is inserted as the initial octets of the mac_service_data_unit parameter. The Tag Protocol Identification is the Service VLAN Tag EtherType (9.5). The Tag Control Information (TCI) contains a null VID field, and PCP and DEI fields constructed as specified in 6.9.3 using a drop_eligible value of FALSE and a service_access_priority value derived from the priority parameter using Table 6-6.

Table 6-6—Service Access Priority

<table><tr><td>Received priority</td><td>Default service access priority</td><td>Range</td></tr><tr><td>0</td><td>0</td><td>0–7</td></tr><tr><td>1</td><td>1</td><td>0–7</td></tr><tr><td>2</td><td>2</td><td>0–7</td></tr><tr><td>3</td><td>3</td><td>0–7</td></tr><tr><td>4</td><td>4</td><td>0–7</td></tr><tr><td>5</td><td>5</td><td>0-7</td></tr><tr><td>6</td><td>6</td><td>0–7</td></tr><tr><td>7</td><td>7</td><td>0–7</td></tr></table>

Table 6-6 specifies default service_access_priority values for each of the eight possible values of the priority parameter in the M_UNITDATA.request received from the provided ISS. These default values shall be used as the initial values of the corresponding entries of the Service Access Priority Table for each Port supporting Service Access Priority Selection. The values in the table may be modified by management. If this capability is provided, the value of the table entries shall be independently settable for each Port and for each value of priority, and the Bridge shall have the capability to use the full range of the values in the parameter ranges specified in the table.

The frame_check_sequence parameter is either unspecified or contains a value modified from the received frame_check_sequence value taking into account the changes in the mac_service_data_unit parameter.

NOTE—The priority of the original service request made of the customer network can be carried transparently and unchanged across the PBN in the C-TAG.

6.13.2 Data indications

For each M_UNITDATA.indication received from the underlying ISS, an M_UNITDATA.request is presented to the supported ISS with the following parameters:

The destination_address and source_address parameters are unchanged.

If the initial octets of the mac_service_data_unit do not contain a tag header with the Service VLAN Tag EtherType value (9.5), then the mac_service_data_unit and frame_check_sequence parameters are unchanged; otherwise,

a) the mac_service_data_unit is detagged by removing the octets of the S-TAG header, and

b) the priority parameter is decoded from the PCP field (6.9.3),

c) the drop_eligible parameter is decoded from the Drop Eligible Indicator field (6.9.3), and

d) the frame_check_sequence parameter is either unspecified or contains a value modified from the received frame_check_sequence value taking into account the changes in the mac_service_data_unit parameter.

6.14 Support of the ISS within a system

A single system can comprise two or more instances of VLAN Bridge components connected by one or more of their Ports. If those Ports are not otherwise accessible, the ISS may be provided by means outside the scope of this specification. Figure 15-4 provides an example. Each instance of such an implementation of the ISS shall support the MAC status and Point-to-point parameters. An M_UNITDATA.request at one of the Ports connected to such an instance of the ISS shall result in M_UNITDATA.indications with identical parameters at all other Ports connected to that instance.

For convenience of management, such instances of ISS provision are assigned the LAN MAC Type 802.1. Management parameters common to MACs of this type are specified in Clause 12.

NOTE—The ISS can also be supported at Bridge Ports wholly contained within a system by any IEEE 802 LAN technology, subject to the system requirements of the particular media access method.

6.15 Support of the ISS by additional technologies

The ISS may be supported by other technologies that provide either an IEEE 802 MAC Service or an emulated IEEE 802 MAC Service. The technology is responsible for invoking an M_UNITDATA.indication with appropriate parameters (IEEE Std 802.1AC) for each received frame, and transmitting a frame in response to each M_UNITDATA.request. The mac_service_data_unit parameter in an M_UNITDATA.indication may include a tag header of a type recognized by the functions using the EISS (6.8). If multiplexing of multiple virtual instances of the MAC Service is provided, each virtual service must be

a) identified by the VID field in a tag header of a type recognized by the functions using the EISS, or

b) attached to separate instance of the ISS with no tag header in the mac_service_data_unit

(i.e., the only multiplexing recognized by the functions of the MAC Relay are those identified by a VID).

6.16 Filtering services in Bridged Networks

Bridges provide filtering services that support aspects of the maintenance of QoS—in particular, transit delay, priority, and throughput. In addition, these services provide a degree of administrative control over the propagation of particular MAC addresses in the network.

The services described are services in the most general sense; i.e., descriptions of functionality available to a MAC Service user or an administrator to control and access filtering capabilities. The descriptions make no assumptions about how the service might be realized. There are at least the following possibilities:

a) Use of existing protocols and mechanisms, defined in IEEE 802 standards and elsewhere.

b) Use of management functionality, either locally defined or via remote management protocols.

c) Other means, standardized or otherwise.

6.16.1 Purpose(s) of filtering service provision

Filtering services are provided for the purposes described in 6.16.1.1 and 6.16.1.2.

6.16.1.1 Administrative control

Filtering services provide administrative control over the use of particular source and destination addresses in designated parts of the network. Such control allows network managers and administrators to limit the extent of operation of network layer and other protocols that use individual and group MAC addresses by establishing administrative boundaries across which specific MAC addresses are not forwarded.

6.16.1.2 Throughput and end station load

Filtering services increase the overall throughput of the network, and reduce the load placed on end stations caused by the reception of frames that are destined for other end stations, by

a) Limiting frames destined for specific MAC addresses to parts of the network that, to a high probability, lie along a path between the source MAC address and the destination MAC address.

b) Reducing the extent of group addressed frames to those parts of the network that contain end stations that are legitimate recipients of that traffic.

c) In Virtual Bridged Networks, reducing the extent of frames on specific VLANs to those parts of the network that contain stations that are legitimate recipients of traffic on that VLAN.

NOTE—Some aspects of the filtering services described in this standard are dependent upon the active participation of end stations. Where such participation is not possible, those aspects of the filtering services will be unavailable.

6.16.2 Goals of filtering service provision

The filtering services provided can be used to

a) Allow the MAC Service provider to dynamically learn where the recipients of frames addressed to individual MAC addresses are located.

b) Allow end stations that are the potential recipients of MAC frames destined for group MAC addresses to dynamically indicate to the MAC Service provider which destination MAC address(es) they wish to receive.

c) Exercise administrative control over the extent of propagation of specific MAC addresses.

6.16.3 Users of filtering services

The filtering services provided are available to the following users:

a) Network management and administration, for the purposes of applying administrative control. Interactions between administrators of the network and the filtering service provider may be achieved by local means or by means of explicit management mechanisms.

b) End stations, for the purposes of controlling the destination addresses that they will receive. Interactions between end stations and the filtering service provider may be implicit, as is the case with the Learning Process (8.7), or by explicit use of filtering service primitives.

6.16.4 Basis of service

Filtering in Bridged Networks relies on the establishment of filtering rules, and subsequent filtering decisions, that are based on the value(s) contained in the Source MAC Address, Destination MAC Address, or VID fields in MAC frames.

NOTE—The filtering services defined by this standard use source address learning, destination address, and VID filtering.

6.16.5 Categories of service

Filtering services in Bridged Networks fall into the following categories:

a) Basic Filtering Services. These services are supported by the Forwarding Process (8.6) and by Static Filtering Entries (8.8.1), Static VLAN Registration Entries (8.8.2), Dynamic Filtering Entries (8.8.3), and Dynamic VLAN Registration Entries (8.8.5) in the FDB. The information contained in the Dynamic Filtering Entries is maintained through the operation of the Learning Process (8.7), while the information contained in the Dynamic VLAN Registration Entries is maintained through the operation of MVRP (11.2) and MIRP (Clause 39).

b) Extended Filtering Services. These services are supported by the Forwarding Process (8.6), and the Static Filtering Entries (8.8.1) and MAC Address Registration Entries (8.8.4) in the FDB. The information contained in the MAC Address Registration Entries is maintained through the operation of MMRP (10.9).

All Bridges shall support Basic Filtering Services and may support Extended Filtering Services.

6.16.6 Service configuration

In the absence of explicit information in the FDB, the behavior of the Forwarding Process with respect to the forwarding or filtering of frames destined for group MAC addresses depends upon the categories of service supported by the Bridge.

Basic Filtering Services support the filtering behavior required for regions of a Bridged Network in which potential recipients of multicast frames exist, but where either the recipients or the Bridges are unable to support the dynamic configuration of filtering information for those group MAC addresses, or the recipients have a requirement to receive all traffic destined for group MAC addresses.

Extended Filtering Services support the filtering behavior required for regions of a network in which potential recipients of multicast frames exist, and where both the potential recipients of frames and the Bridges are able to support dynamic configuration of filtering information for group MAC addresses. In order to integrate this extended filtering behavior with the needs of regions of the network that support only Basic Filtering Services, Bridges that support Extended Filtering Services can be statically and dynamically configured to modify their filtering behavior on a per-group MAC address basis, and also on the basis of the overall filtering service provided by each outbound Port with regard to multicast frames. The latter capability permits configuration of the Port's default forwarding or filtering behavior with regard to group MAC addresses for which no specific static or dynamic filtering information has been configured.

Service configuration provides the ability to configure the overall filtering for the following cases:

a) Bridges that only implement Basic Filtering Services.

b) Bridges that support Extended Filtering Services in a heterogeneous environment, where some equipment is unable to participate in Dynamic Multicast Filtering, or where some equipment (e.g., routers) has specific needs to see unfiltered traffic.

c) Bridges that support Extended Filtering Services in a homogeneous environment, where all equipment is able to participate in Dynamic Multicast Filtering.

6.16.7 Service definition for Extended Filtering Services

The Filtering Services are described by means of service primitives that define particular types of interaction between MAC Service users and the MAC Service provider across the MAC Service boundary. As these interactions are not defined between peer entities, they are described simply in terms of service requests sent from the MAC Service user to the MAC Service provider.

6.16.7.1 Dynamic registration and deregistration services

These services allow MAC Service users dynamic control over the set of destination MAC addresses that they will receive from the MAC Service provider, by

a) Registering/deregistering membership of specific Groups associated with those addresses.

b) Registering/deregistering individual MAC address information.

c) Registering/deregistering service requirements with regard to the overall forwarding/filtering behavior for Groups.

Provision of these services is achieved by means of MMRP and its associated procedures, as described in 10.9.

NOTE 1—These services can provide the MAC Service user with dynamic control over access to multicast data streams, for example, multiple video channels made available by a server using a different group MAC address for each channel. The ability to both register and deregister Group membership, coupled with the filtering action associated with the Group membership, limits the impact of such services on the bandwidth available in the network. These services can be used to control the reception of other categories of multicast traffic, for similar reasons.

REGISTER_MAC_ADDRESS (MAC_ADDRESS)

Indicates to the MAC Service provider that the MAC Service user wishes to receive frames containing the MAC address indicated in the MAC_ADDRESS parameter as the destination address. The MAC addresses that can be carried by this parameter do not include the following:

d) Any of the Reserved Addresses identified in Table 8-1, Table 8-2, or Table 8-3.

e) Any of the MRP Application addresses, as defined in Table 10-1.

DEREGISTER_MAC_ADDRESS (MAC_ADDRESS)

Indicates to the MAC Service provider that the MAC Service user no longer wishes to receive frames containing the MAC address indicated in the MAC_ADDRESS parameter as the destination address.

REGISTER_SERVICE_REQUIREMENT (REQUIREMENT_SPECIFICATION)

Indicates to the MAC Service provider that the MAC Service user has a requirement for any devices that support Extended Filtering Services to forward frames in the direction of the MAC Service user in accordance with the definition of the service requirement defined by the REQUIREMENT_SPECIFICATION parameter. The values that can be carried by this parameter are as follows:

f) Forward All Groups.

g) Forward Unregistered Groups.

DEREGISTER_SERVICE_REQUIREMENT (REQUIREMENT_SPECIFICATION)

Indicates to the MAC Service provider that the MAC Service user no longer has a requirement for any devices that support Extended Filtering Services to forward frames in the direction of the MAC Service user in accordance with the definition of the service requirement defined by the REQUIREMENT_SPECIFICATION parameter. The values that can be carried by this parameter are as follows:

h) Forward All Groups.

i) Forward Unregistered Groups.

The use of these services can result in the propagation of group MAC address and service requirement information across the spanning tree, affecting the contents of MAC Address Registration Entries (8.8.4) in Bridges and end stations, and thereby affecting the frame forwarding behavior of the Bridges and end stations with regard to multicast frames.

NOTE 2—If the EISS is supported, the Extended Filtering Service primitives issued by the MAC Service user should also include a VID parameter in order to identify the VLAN associated with the MAC_ADDRESS or REQUIREMENT_SPECIFICATION specified.

6.17 EISS Multiplex Entity

The EISS Multiplex Entity enables shims defined for the ISS to use the EISS. Figure 6-6 illustrates two EISS Multiplex Entities placed back-to-back.

!image

Figure 6-6—Two back-to-back EISS Multiplex Entities

An EISS Multiplex Entity has one EISS SAP, and a number of multiplexed SAPs, each either an ISS SAP or an EISS SAP. Each multiplexed ISS SAP is assigned to a single vlan_identifier value. Each multiplexed EISS SAP is assigned to one or more vlan_identifier values. Every vlan_identifier is assigned to some multiplexed SAP. Upon receiving a Request or Indication from its single EISS SAP, the EISS Multiplex Entity uses the vlan_identifier to select the corresponding one of its multiplexed SAPs to present the Request or Indication. Similarly, any Request or Indication received from a multiplexed SAP is presented to the single EISS SAP; the vlan_identifier parameter presented on the single EISS SAP is the one associated with the multiplexed ISS SAP, or the one obtained from the multiplexed EISS SAP.

Shims can be multiplexed in this fashion to separately serve multiple vlan_identifiers. Figure 22-1 illustrates CFM shims deployed in this manner.

The MAC_Operational status parameter (IEEE Std 802.1AC) presented to the uppermost EISS-SAP in Figure 6-6 is TRUE if and only if

a) The uppermost EISS-SAP's MAC_Enabled parameter is TRUE; and

b) At least one of its multiplexed SAPs' MAC_Operational status parameters is TRUE.

The MAC_Operational status parameter of each of the lower EISS Multiplex Entity's multiplexed SAPs in Figure 6-6 is computed separately and is TRUE if and only if

c) The lowermost EISS-SAP's MAC_Operational parameter is TRUE; and

d) That multiplexed SAP's MAC_Enabled parameter is TRUE.

6.18 Backbone Service Instance Multiplex Entity

The Backbone Service Instance Multiplex Entity allows shims defined for the ISS to be instantiated per backbone service instance at a SAP that supports multiple backbone service instances. Figure 6-7 illustrates two Backbone Service Instance Multiplex Entities placed back-to-back. A set of back-to-back Backbone Service Instance Multiplex Entities may be used at the ISS of a PIP or CBP to provide per Backbone Service Instance SAPs that support CFM shims at the Backbone Service Instance MD Level as shown in Figure 6-8 and the figures of 26.8.

!image

Figure 6-7—Two back-to-back Backbone Service Instance Multiplex Entities

!image

Figure 6-8—Backbone Service Instance Multiplex Entities with example CFM shims

NOTE 1—Figure 6-8 shows a representative placement of CFM shims between back-to-back Backbone Service Instance Multiplex Entities. This is not intended to imply any restriction that this is the only possible configuration of MEPs and MIPs.

A Backbone Service Instance Multiplex Entity has one ISS SAP that supports multiple backbone service instances, and a number of multiplexed ISS SAPs each supporting a single backbone service instance. Each multiplexed SAP has a single assigned I-SID value. Every I-SID value is assigned to a multiplexed SAP, and no I-SID value is assigned to more than one multiplexed SAP.

NOTE 2—There are implicitly $2^{24}$ multiplexed SAPs—one for each potential I-SID value. This does not require any implementation to support $2^{24}$ SAPs. The combined structure of back-to-back Backbone Service Instance Multiplex Entities is transparent to any frames with an I-SID value corresponding to a multiplexed SAP that does not have a protocol entity (e.g., CFM) instantiated at that SAP.

In the multiplexing direction, any Request or Indication received from a multiplexed SAP results in the generation of a corresponding Request or Indication to the single ISS SAP, with an I-TAG header added to the mac_service_data_unit as specified in 6.18.2. Similarly, in the demultiplexing direction any Request or Indication received from the single ISS SAP results in the generation of a corresponding Request or Indication at one of the multiplexed SAPs (determined by the I-SID contained in a I-TAG in the mac_service_data_unit), with the I-TAG removed from the mac_service_data_unit as specified in 6.18.1. When an I-TAG header with the UCA field containing a value of zero is removed, the C_DA and C_SA fields of the I-TAG remain in the mac_service_data_unit. In this case, a new EtherType field is prepended so the mac_service_data_unit still begins with a valid EtherType value. The Encapsulated Addresses EtherType value in Table 6-7 is allocated for this purpose.

Table 6-7—Encapsulated Addresses EtherType

<table><tr><td>Name</td><td>Value</td></tr><tr><td>IEEE 802.1Q Encapsulated Addresses EtherType</td><td>89-10</td></tr></table>

NOTE 3—This EtherType value is used only internally at the Backbone Service Multiplex Entity and does not appear in any frame on a LAN in the PBBN.

6.18.1 Demultiplexing direction

On receipt of an M_UNITDATA.request or M_UNITDATA.indication primitive from the single ISS SAP, the received frame shall be discarded if

a) The initial octets of the mac_service_data_unit do not contain a valid I-TAG; or

b) The Res2 field in the I-TAG is not zero.

Otherwise, an M_UNITDATA.request or M_UNITDATA.indication primitive is invoked at the multiplexed ISS SAP corresponding to the I-SID value in the I-TAG. The parameter values are determined as follows:

The connection_identifier parameter contains the same value as in the received primitive.

The destination_address and source_address parameters are determined as follows:

c) If the UCA bit is zero, the destination_address and source_address parameters contain the respective values in the received primitive;

d) Otherwise, the destination_address and source_address parameters contain the respective values in the C-DA and C-SA fields of the I-TAG.

The value of the drop_eligible and priority parameters are decoded from the I-DEI and the I-PCP fields of the I-TAG header in the mac_service_data_unit as described in 6.18.3.

The value of the mac_service_data_unit parameter is constructed from the value of the received mac_service_data_unit modified as follows:

e) If the UCA field in the I-TAG is zero, then the I-PCP, I-DEI, UCA, Res1, Res2, and I-SID fields of the I-TAG are removed and the Backbone Service Instance Tag EtherType value is replaced with the Encapsulated Addresses EtherType value (Table 6-7);

f) Otherwise, the entire I-TAG is removed.

The value of the frame_check_sequence parameter is either unspecified or derived from the received FCS information modified as necessary to take into account changes to the frame.

6.18.2 Multiplexing direction

On receipt of an M_UNITDATA.request or M_UNITDATA.indication primitive from any of the multiplexed ISS SAPs, an M_UNITDATA.request or M_UNITDATA.indication primitive is invoked at the single ISS SAP. The parameter values are determined as follows:

The source_address, priority, drop_eligible, and connection_identifier parameters contain the same value as in the received primitive.

The destination_address parameter is determined as follows:

a) If the destination_address in the received primitive is a group address and the UCA bit is set, then the destination_address parameter contains the Backbone Service Instance Group address constructed from the I-SID corresponding to the multiplexed ISS SAP at which the primitive was received;

b) Otherwise the destination_address parameter contains the same value as in the received primitive.

The value of the mac_service_data_unit parameter is equal to the value of the received mac_service_data_unit modified as follows:

c) If the initial two octets of the mac_service_data_unit match the Encapsulated Addresses EtherType value, then these octets are replaced with the Backbone Service Instance Tag EtherType value, and the I-PCP, I-DEI, UCA, Res1, Res2, and I-SID fields of an I-TAG are inserted following this EtherType value. The UCA, Res1 and Res2 fields all contain a value of zero. The I-SID field contains the value of the I-SID corresponding to the multiplexed ISS SAP at which the primitive was received. The values of the I-PCP and I-DEI fields are encoded from the drop_eligible and priority parameters as specified in 6.18.3.

d) If the initial two octets of the mac_service_data_unit do not match the Encapsulated Addresses EtherType value, then a complete I-TAG is prepended to the mac_service_data_unit. The UCA field contains a value of one. The Res1 and Res2 fields contain a value of zero. The C-DA and C-SA fields contain the destination_address and source_address from the received primitive, respectively. The I-SID field contains the value of the I-SID corresponding to the multiplexed ISS SAP at which the primitive was received. The values of the I-PCP and I-DEI fields are encoded from the drop_eligible and priority parameters as specified in 6.18.3.

The value of the frame_check_sequence parameter is either unspecified or derived from the received FCS information modified as necessary to take into account changes to the frame.

6.18.3 Priority Code Point encoding

6.18.4 Status parameters

The MAC_Operational status parameter (IEEE Std 802.1AC) presented to the uppermost single ISS SAP in Figure 6-7 is TRUE if and only if

a) The uppermost single ISS SAP's MAC_Enabled parameter is TRUE; and

b) At least one of its multiplexed SAPs' MAC_Operational status parameters is TRUE.

The MAC_Operational status parameter of each of the multiplexed SAPs in Figure 6-7 is computed separately, and is TRUE if and only if

c) The lowermost single ISS SAP's MAC_Operational parameter is TRUE; and

d) That multiplexed SAP's MAC_Enabled parameter is TRUE.

6.19 TESI Multiplex Entity

The TESI Multiplex Entity allows shims defined for PBB-TE to be instantiated per TESI at a SAP that supports multiple TESIs. Figure 6-9 illustrates two TESI Multiplex Entities, placed back-to-back. A set of back-to-back TESI Multiplex Entities may be used at the multiplexed (E)ISS SAPs that are associated with ESP-VIDs on a CBP to provide per TESI SAPs that support CFM shims for PBB-TE MAs as shown in Figure 26-8.

!image

Figure 6-9—Two back-to-back Up and Down TESI Multiplex Entities

A TESI Multiplex Entity has one (E)ISS SAP that supports multiple TESIs, and a number of multiplexed (E)ISS SAPs each supporting a single TESI. Each multiplexed SAP has destination_address, source_address, and vlan_identifier combinations assigned by the TESI Multiplex Entity. Every destination_address, source_address, and vlan_identifier combination can be assigned to a multiplexed SAP, and no destination_address, source_address, and vlan_identifier combination is assigned to more than one multiplexed SAP.

Upon receiving a Request or Indication from its single (E)ISS SAP, the TESI Multiplex Entity uses the destination_address, source_address, and vlan_identifier to select the corresponding one of its multiplexed SAPs to present the Request or Indication. The Request or Indication presented at the multiplexed SAPs has the same parameters as the original Request or Indication at the Single SAP. Similarly, any Request or Indication received from a multiplexed SAP is transparently presented to the single (E)ISS SAP.

The MAC_Operational status parameter (6.8.2) presented to the uppermost single (E)ISS SAP in Figure 6-9 is TRUE if and only if

a) The uppermost single (E)ISS SAP's MAC_Enabled parameter is TRUE; and

b) At least one of its multiplexed SAPs' MAC_Operational status parameters is TRUE.

The MAC_Operational status parameter of each of the multiplexed SAPs in Figure 6-9 is computed separately, and is TRUE if and only if

c) The lowermost single (E)ISS SAP's MAC_Operational parameter is TRUE; and

d) That multiplexed SAP's MAC_Enabled parameter is TRUE.

The MAC_Operational parameter of the passive SAP on a PBB-TE MEP is set to FALSE when the PBB-TE MEP declares an errorCCMdefect (20.21.3) or an xconCCMdefect (20.23.3), setting the MAC_Operational parameter of the associated multiplexed SAP on the TESI Multiplex Entity to FALSE. The MAC_Operational parameter of the passive SAP on a PBB-TE MEP is set back to TRUE when both defects are cleared, setting back to TRUE the MAC_Operational parameter of the associated multiplexed SAP.

6.20 Support of the ISS with signaled priority

The functions specified in this subclause comprise a shim (3.201, IEEE Std 802.1AC) that uses an ISS SAP supported by a MAC entity (IEEE Std 802.1AC) to provide explicitly signaled priority information to an ISS SAP that supports a VLAN-unaware MAC Relay (Figure 6-10). Signaled priority information is derived from a VLAN tag header (9.3), if such header is present in the mac_service_data_unit. Any given instance of the ISS shall be supported by recognizing one but not both of the following VLAN Tag EtherTypes:

a) C-VLAN tag (C-TAG); or

b) S-VLAN tag (S-TAG).

The VLAN Tag EtherType is selected as specified in 9.5.

!image

Figure 6-10—Supporting the ISS with signaled priority

6.20.1 Data indications

On receipt of an M_UNITDATA.indication primitive from the lower ISS SAP (Figure 6-10), an M_UNITDATA.indication primitive is invoked at the upper ISS SAP, with parameter values determined as follows:

The destination_address, source_address, connection_identifier, mac_service_data_unit, and frame_check_sequence parameters carry values equal to the corresponding parameters in the received data indication.

The value of the drop_eligible and priority parameters are determined as follows:

a) If the initial octets of the mac_service_data_unit contain a valid VLAN tag header (9.3) of the type used to support the EISS (9.5), the value of the drop_eligible parameter and the received priority value are decoded from the tag header as described in 6.9.3. Otherwise,

b) The received priority value and the drop_eligible parameter value are the values in the received data indication.

c) The value of the priority parameter is then regenerated from the received priority, as specified in 6.9.4.

6.20.2 Data requests

On receipt of an M_UNITDATA.request primitive from the upper ISS SAP (Figure 6-10), an M_UNITDATA.request primitive with identical parameter values is invoked at the lower ISS SAP.

6.21 Infrastructure Segment Multiplex Entity

The Infrastructure Segment Multiplex Entity allows shims defined for Segment Endpoint Ports (SEPs) and Segment Intermediate Ports (SIPs) to be instantiated per Infrastructure Segment at a SAP that supports multiple Infrastructure Segments. Figure 6-11 illustrates two Infrastructure Segment Multiplex Entities, placed back-to-back. A set of back-to-back Infrastructure Segment Multiplex Entities may be used at the multiplexed (E)ISS SAPs that are associated with SMP-VIDs on a PNP to provide per Infrastructure Segment SAPs that support CFM shims for Infrastructure Segment MAs as shown in Figure 26-10.

!image

Figure 6-11—Two back-to-back Up and Down Infrastructure Segment Multiplex Entities

An Infrastructure Segment Multiplex Entity has one (E)ISS SAP that supports multiple Infrastructure Segment instances, and a number of multiplexed (E)ISS SAPs each supporting a single Infrastructure Segment instance. Each multiplexed SAP has destination_address, source_address, and vlan_identifier combinations assigned by the Infrastructure Segment Multiplex Entity. Every destination_address, source_address, and vlan_identifier combination can be assigned to a multiplexed SAP, and no destination_address, source_address, and vlan_identifier combination is assigned to more than one multiplexed SAP.

Upon receiving a Request or Indication from its single (E)ISS SAP, the Infrastructure Segment Multiplex Entity uses the destination_address, source_address, and vlan_identifier to select the corresponding one of its multiplexed SAPs to present the Request or Indication. The Request or Indication presented at the multiplexed SAPs has the same parameters as the original Request or Indication at the Single SAP. Similarly, any Request or Indication received from a multiplexed SAP is transparently presented to the single (E)ISS SAP.

The MAC_Operational status parameter (IEEE Std 802.1AC) presented to the uppermost single (E)ISS SAP in Figure 6-9 is TRUE if and only if

a) The uppermost single (E) ISS SAP's MAC Enabled parameter is TRUE; and

b) At least one of its multiplexed SAPs' MAC_Operational status parameters is TRUE.

The MAC_Operational status parameter of each of the multiplexed SAPs in Figure 6-9 is computed separately, and is TRUE if and only if

c) The lowermost single (E)ISS SAP's MAC Operational parameter is TRUE; and

d) That multiplexed SAP's MAC_Enabled parameter is TRUE.

The MAC_Operational parameter of the passive SAP on an Infrastructure Segment MEP is set to FALSE when the Infrastructure Segment MEP declares an errorCCMdefect (20.21.3) or an xconCCMdefect (20.23.3), setting the MAC_Operational parameter of the associated multiplexed SAP on the Infrastructure Segment Multiplex Entity to FALSE. The MAC_Operational parameter of the passive SAP on an Infrastructure Segment MEP is set back to TRUE when both defects are cleared, setting back to TRUE the MAC_Operational parameter of the associated multiplexed SAP.

7 Principles of Virtual Bridged Network operation

This clause establishes the principles and a model of Virtual Bridged Network operation. It defines the context necessary for

a) The operation of individual VLAN Bridges (Clause 8);

b) Their participation in the Spanning Tree Algorithm and Protocol (STP) (Clause 8 of IEEE Std 802.1D, 1998 Edition [B9]), Rapid Spanning Tree Algorithm and Protocol (RSTP) (Clause 13), Multiple Spanning Tree Algorithm and Protocol (MSTP) (Clause 13), and Shortest Path Bridging (SPB) protocols (Clause 27);

c) The management of individual Bridges (Clause 12); and

d) The management of VLAN Topology (Clause 11)

to support, preserve, and maintain the quality of the MAC Service as discussed in Clause 6.

7.1 Network overview

The operation of a Virtual Bridged Network, the Bridges, and the LANs that compose that network comprises

a) A physical topology comprising LANs, Bridges, and Bridge Ports. Each Bridge Port attaches a LAN to a Bridge and is capable of providing bidirectional connectivity for MAC user data frames. Each LAN is connected to every other LAN by a Bridge and zero or more other LANs and Bridges.

b) Calculation of one or more active topologies, each a loop-free subset of the physical topology.

c) Rules for the classification of MAC user data frames that allow each Bridge to allocate, directly or indirectly, each frame to one and only one active topology.

d) Management control of the connectivity provided for differently classified data frames by the selected active topology.

e) Implicit or explicit configuration of end station location information, identifying LANs with attached end stations that need to receive user data frames with a given destination address.

f) Communication of end station location information to allow Bridges to restrict user data frames to LANs in the path provided to their destination(s) by the chosen active topology.

These elements and their interrelationships are illustrated in Figure 7-1.

NOTE 1—The physical and active topologies can be represented as bi-partite graphs. Bridges and LANs are nodes in these graphs (including LANs that are point-to-point links) and the Bridge Ports are edges.

NOTE 2—This standard applies the notion of a physical topology to media access control methods, like wireless, where there is no tangible physical connection between a Bridge and an attached LAN. A Bridge Port models this association just as for wired connectivity.

NOTE 3—Each of the active topologies [see item b)] does not necessarily span the entire network, but does span all those Bridges and LANs between which data frame connectivity is desired for frames allocated to that active topology.

NOTE 4—The destination addressing information associated with a MAC user data frame includes the VLAN classification of the frame [see item d)].

NOTE 5—Implicit configuration [see item d)], or recognition, of end station location includes observation of the source address of the user data frame transmitted by that station. The user data frame communicates that location information [see item e)] along the portion of the chosen active topology leading to the frame's destination(s).

!image

Figure 7-1—VLAN Bridging overview

7.2 Use of VLANs

VLANs and their VIDs provide a convenient and consistent network-wide reference for VLAN Bridges to

a) Identify rules for the classification of user data frames into VLANs;

b) Effectively extend the source and destination MAC addresses, by treating frames and addressing information for different VLANs independently;

c) Identify and select from different active topologies;

d) Identify configuration parameters that partition a physical network.

Taken together these capabilities allow VLAN Bridges to emulate a number of separately manageable, or virtual, Bridged Networks. A LAN that has been selected by network management to receive frames assigned to a given VLAN is said to form part of, belong to, or be a member of the VLAN. Similarly, end stations that are attached to those LANs and that can receive frames assigned to the VLAN are said to be attached to that VLAN.

NOTE—Separate control over the transmission and over the reception of frames to and from LANs and end stations is possible. To avoid ambiguity, VLAN membership is defined by reception.

Inclusion of the VID in VLAN-tagged frames guards against connectivity loops arising from differing classifications by different Bridges, and permits enhanced classification rules to be used by some Bridges, while others simply forward the previously classified frames.

The VLAN tag allows frames to carry priority information, even if the frame has not been classified as belonging to a particular VLAN.

7.3 Active topology

Bridges cooperate to calculate one or more loop-free and fully connected active topologies, i.e., spanning trees. The algorithms and protocols—RSTP (13.4), MSTP (13.5), SPB (Clause 27)—that support that calculation provide rapid recovery from network component failure (6.5.1) by using alternate physical connectivity, without requiring management intervention.

The Bridge's forwarding processes constrain the potential path for each user data frame to a single spanning tree. A Bridge that uses RSTP or STP allocates all frames to a single CST. An MST or SPT Region (13.8, 27.4.1) comprises the transitive closure of Bridges that use MSTP or SPB and that agree on the allocation of frames with a given VID to a given subtree within the region. That subtree can be an MSTI, a SPT, or the IST that is the logical continuation of the CST through the region. Interoperability between MST and SPT Bridges and SST Bridges, and between differently configured MST/SPT Bridges, is achieved by allocating all frames to the CST at region boundaries. Thus the spanning tree for a given frame can comprise subtrees of the CST together with an MSTI or SPT within each region. Frames with different VIDs can be assigned to the same or to different trees and subtrees within a region.

NOTE—In a stable network, the MSTP and SPB algorithms verify that each MST/SPT Region is fully connected internally. However, if the CST Root lies outside the region, the region can be partitioned temporarily as necessary to prevent external connectivity between Bridge Ports at the region boundary from creating a loop. A given region of the network can be an MST Region, an SPT Region, or both, but the protocol mechanisms that verify connectivity internal to the region require that regions do not overlap or subset other regions.

7.4 VLAN topology

Typically each of the VIDs for frames assigned to the CST, and to the IST or an MSTI within an MST Region, supports a different VLAN, and each VLAN is supported by only one VID and only one subtree within the region. However, frames for VLANs supported by SPB are assigned to the SPT rooted at the Bridge where they enter an SPT Region, and SPBV requires that each source Bridge for a given VLAN uses a unique SPVID. To provide interoperability with other regions and end systems that support a VLAN with a single VID, the VIDs for SPBV VLANs are translated at the SPT Region boundary (6.9, 27.12). SPBM uses a single VID for all the SPTs for a given VLAN.

NOTE 1—Support of a network comprising a single SPT Region with directly attached VLAN-unaware or priority tagging end stations does not require VID translation. This includes, for example, a PBN or PBBN where the edge of the network corresponds with the boundary of the SPT Region.

Within a given region, the SPTs that support any given shortest path VLAN provide full and symmetric connectivity (6.3). To allow frames in different VLANs to make use of equal cost shortest paths, multiple SPT Sets can be used, each providing full symmetric connectivity between all Bridges in the region.

Each VLAN may occupy the full extent of the active topology of its associated spanning tree(s) or a continuously connected subset of that active topology. The connected subset must be continuously connected; otherwise, the VLAN is split. The maximum extent of the connected subset may be bounded by management by explicitly excluding certain Bridge Ports from a VLAN's connectivity.

At any time the current extent of a VLAN can be further reduced from the maximum to include only those LANs that provide communication between attached devices, by the use of protocol that allows end stations to request and release services that use the VLAN. Such a protocol is specified in Clause 11. The dynamic determination of VLAN extent provides flexibility and bandwidth conservation, at the cost of network management complexity.

NOTE 2—Dynamic determination of VLAN extent is generally preferable to static configuration for bandwidth conservation, as the latter is error prone and can defeat potential alternate connectivity—requiring active management intervention to recover from network component failure.

NOTE 3—To accommodate end stations that do not participate in the MVRP specified in Clause 11, management controls associated with each Bridge Port allow the Port to identify the attached LAN as connecting end stations that require services using specified VLANs.

NOTE 4—Where a given VLAN is supported by multiple VIDs, as for SPB, management controls identify the VLAN by a Base VID (that used when frames are allocated to the CST). Use of this single VID reduces the configuration burden, particularly when Bridges are added to the SPT Region and further SPVIDs are allocated.

7.5 Locating end stations

Functioning as a distributed system, Bridges within the current extent of a VLAN can, through explicit and or implicit cooperation, locate those LANs where an attached end station or end stations are intended to receive frames addressed to a specified individual address or group address. Bridges can thus reduce traffic by confining frames to the LANs where their transmission is necessary.

NOTE 1—Individual Bridges do not determine the precise location of end stations but merely determine which of their Bridge Ports need to forward frames toward the destination(s). For the system of Bridges this is sufficient to restrict frames to the paths necessary to reach the destination LANs.

The Multiple MAC Registration Protocol (MMRP), specified in Clause 10, allows end stations to advertise their presence and their desire to join (or leave) a multicast group, or to register an individual MAC address, in the context of a VLAN. The protocol communicates this information to other Bridges, using the VLAN and its active topology.

NOTE 2—To accommodate end stations that do not participate in MMRP, management controls associated with each Bridge Port allow the port to identify the attached LAN as connecting end stations that are intended to receive specified group addresses. The continuous operation of MMRP and the propagation of location information through Bridges using the current active topology for the VLAN support multicast traffic reduction, while ensuring rapid restoration of multicast connectivity without management intervention if alternate connectivity is selected following network component failure.

Each end station implicitly advertises its attachment to an individual LAN and its individual MAC address whenever it transmits a frame. Bridges learn from the source address as they forward the frame along the active topology to its destination or destinations – or throughout the Bridged Network or VLAN if the location of the destination or destinations is unknown. The learned information is stored in the FDB (8.8) and used to filter frames on the basis of their destination addresses.

Address information learned from a frame with a given VID can be used to filter frames with other VIDs. For example, information learned from a frame with any of the VIDs that support SPB for a given VLAN (i.e., VIDs associated with the same Base VID) is used to filter frames with any of the VIDs for that VLAN. In some network configurations, it is also necessary to use address information learned in any one of a set of VLANs to filter frames with VIDs that identify any VLAN in the set (Shared VLAN Learning (SVL), Clause 3). In other configurations it is necessary or desirable not to share learned information between certain VLANs (Independent VLAN Learning (IVL), Clause 3) while in some cases it is immaterial whether address information is shared between VLANs. Annex F discusses the network configuration requirements, and some of the related interoperability issues.

Clause 15 and Clause 16 describe how the mapping of C-VLANs into S-VLANs is accomplished within PBNs and PBBNs. These networks provide additional mapping facilities to support hierarchies of VLANs allowing a provider a separate FDB from customers. The conformance definitions of 5.3 have been extended to support S-VLANs. Clause 25 and Clause 26 describe how the mapping of S-VLANs into backbone service instances is accomplished within PBBNs.

7.6 Ingress, forwarding, and egress rules

The relay function provided by each Bridge controls:

a) Classification of each received frame as belonging to one and only one VLAN, and discard or acceptance of the frame for further processing on the basis of that classification and the received frame format, which can be one of three possible types:

1) Untagged, and not explicitly identifying the frame as being associated with a particular VID;

2) Priority-tagged, i.e., including a tag header conveying explicit priority information but not identifying the frames as being associated with a specific VID;

3) VLAN-tagged, i.e., explicitly associating the frames with a particular VID. This aspect of relay implements the ingress rules.

b) Implementation of the decisions governing where each frame is to be forwarded as determined by the current extent of the VLAN topology (7.4), station location information (7.5), and the additional management controls specified in Clause 8. This aspect of relay implements the forwarding rules.

c) Queuing of frames for transmission through the selected Bridge Ports, management of the queued frames, selection of frames for transmission, and determination of the appropriate frame format type, VLAN-tagged or untagged. This aspect of relay implements the egress rules.

The structuring of the relay functionality into the implementation of ingress, forwarding, and egress rules constitutes a generic approach to the provision of VLAN functionality. All VLAN Bridges can correctly forward received frames that are already VLAN-tagged. These are classified as belonging to the VLAN identified by the VID in the tag header. All VLAN Bridges can also classify untagged and priority-tagged frames received on any given port as belonging to a specified VLAN. In addition to this default Port-based ingress classification, this standard specifies an optional Port-and-Protocol-based classification.

The classification of untagged and priority-tagged frames, and the addition or removal of tag headers, is performed in support of the EISS (6.9).

Frames that carry control information to determine the active topology and current extent of each VLAN, i.e., spanning tree or SPB and MVRP PDUs, and frames from other link constrained protocols, such as EAPOL and LLDP, are not forwarded. Permanently configured static entries in the FDB (8.2, 8.3, and 8.12) ensure that such frames are discarded by the Forwarding Process (8.6).

NOTE—MRPDUs destined for any MRP application are forwarded or filtered depending on whether the application concerned is supported by the Bridge, as specified in 8.1.2.

The forwarding rules specified for VLAN-tagged frames facilitate the interoperation of VLAN Bridges conformant to this standard with end stations that directly support attachment of MAC Service users to VLANs by transmitting VLAN-tagged frames, and with Bridges that are capable of additional proprietary ingress classification methods.

Frames transmitted on a given LAN by a VLAN Bridge for a given VLAN shall be either

d) All untagged; or

e) All VLAN-tagged with the same VID; or

f) All VLAN-tagged, each with an SPVID allocated to the Base VID for that VLAN.

8 Principles of Bridge operation

This clause

a) Explains the principal elements of the operation of Bridges, and the operation of Bridge components within systems, and lists the supporting functions.

b) Establishes a Bridge architecture that governs the provision of these functions.

c) Provides a model of Bridge operation in terms of processes and entities that support the functions.

d) Details the addressing requirements in a bridged network.

e) Specifies the addressing of entities in a Bridge.

8.1 Bridge operation

The principal elements of Bridge operation are

a) Relay and filtering of frames (8.1.1).

b) Maintenance of the information required to make frame filtering and relaying decisions (8.1.2).

c) Management of the above (Clause 12).

8.1.1 Relay

A Bridge relays individual MAC user data frames between the separate MACs of the individual LANs connected to its Ports. The functions that support relaying of frames and maintain the QoS are

a) Frame reception (8.5).

b) Discard on received frame in error (6.5.2).

c) Discard of frames that do not carry user data (IEEE Std 802.1AC).

d) Priority and drop eligibility decoding from a VLAN tag, if present, and regeneration of priority, if required (6.9).

e) Assignment of a VID to each received frame (6.9).

f) Ensure that each frame is confined to an active topology (8.6.1).

g) Frame discard to support management control over the active topology of each VLAN (6.9, 8.6.2, 8.6.4).

h) Frame discard following the application of filtering information (8.6.3).

i) Metering of frames, potentially marking as drop eligible or discarding frames exceeding bandwidth limits (8.6.5).

j) Forwarding of received frames to other Bridge Ports (8.6.6).

k) Selection of traffic class and queuing of frames by traffic class (8.6.6).

1) Frame discard to ensure that a maximum Bridge transit delay is not exceeded (6.5.6, 8.6.7).

m) Preferential discard of drop eligible frames to preserve QoS for other frames (8.6.7).

n) Selection of queued frames for transmission (8.6.8).

o) Mapping of SDUs and FCS recalculation, if required (6.5.7).

p) Frame discard on transmittable SDU size exceeded (6.5.8).

q) Selection of outbound access priority (6.5.9).

r) Frame transmission (8.5).

A VLAN-unaware MAC Relay Entity is supported by the ISS, and not the EISS, and correspondingly the functions that support relaying of frames in a MAC Bridge cannot make use of any parameters explicit to EISS, like the VIDs. This means in particular that for a MAC Bridge, item e) in the list above is not supported, items d) and g) would be supported in the form of

s) Regeneration of priority, if required (6.9.4);

t) Frame discard to support management control over the physical topology of the network;

and, every other item on the list is supported but without making any use of, or qualification upon, VIDs.

Figure 8-1 gives an example of the physical topology of a Bridged Network.

!image

Figure 8-1—A Bridged Network

8.1.2 Filtering and relaying information

A Bridge maintains filtering and relaying information for the following purposes:

a) Duplicate frame prevention: to maintain a loop-free active topology for every frame;

b) Traffic segregation: to separate communication by different sets of network users;

c) Traffic reduction: to confine frames to the path(s) between their source and destination(s);

d) Traffic expediting: to classify frames in order to expedite time-critical traffic;

e) Frame format conversion: to tag or untag as appropriate for the destination LAN and stations.

8.1.3 Duplicate frame prevention

A Bridge filters frames, i.e., does not relay frames received by a Bridge Port to other Bridge Port on that Bridge, in order to prevent the duplication of frames (6.5.4). The functions that support the use and maintenance of information for this purpose are

a) Configuration and calculation of one or more spanning tree active topologies.

b) In MST Bridges, explicit configuration to assign VIDs to MSTIs (8.9).

c) In SPT Bridges: explicit or default selection of shortest path, CIST, or MSTI support for specified VLANs; and automatic assignment of VIDs to SPTs for shortest path VLANs.

8.1.4 Traffic segregation

A VLAN Bridge can filter frames to confine them to LANs that belong to the VLAN to which they are assigned and, thus, define the VLAN's maximum extent (7.4). The functions that support the use and maintenance of information for this purpose are

a) Configuration of a PVID for each Port, to associate a VID with untagged and priority-tagged received frames (6.9.1), and parameters for Protocol VLAN Classification (6.12) if implemented;

b) Configuration of Static VLAN Registration Entries (8.8.2);

c) Configuration of the Enable Ingress Filtering parameter to enable or disable application of Static VLAN Registration Entries to received frames.

A VLAN Bridge can filter frames to partially partition a Virtual Bridged Network. Frames assigned to any given VID and addressed to specific end stations or groups of end stations can be excluded from relay to certain Bridge Ports. The functions that support the use and maintenance of information for this purpose are

d) Permanent configuration of Reserved Addresses (Table 8-1, Table 8-2, and Table 8-3);

e) Configuration of Static Filtering Entries (8.8.1) and MAC Address Registration Entries (8.8.4).

NOTE—The use of VLANs is generally less error prone and is preferred to filtering using destination addresses if a Bridged Network is to be partitioned for reasons of scale, efficiency, management, or security. Destination address filtering is the only mechanism available to MAC Bridges.

8.1.5 Traffic reduction

A Bridge can filter frames so that LANs not attaching to or forming part of the path between the source and the potential destination(s) of any given communication do not have to support the transmission of related frames, potentially improving the quality of the MAC Service for other communications. The functions that support the use and maintenance of information for this purpose are

a) Automatic learning of dynamic filtering information for unicast destination addresses through observation of source addresses of frames;

b) Ageing out or flushing of dynamic filtering information that has been learned to support the movement of end stations and changes in active topology;

c) Automatic configuration of MAC Address Registration Entries by means of MMRP exchanges;

d) Explicit configuration of the management controls associated with the operation of MMRP by means of MAC Address Registration Entries.

A VLAN Bridge can also filter frames to confine them to LANs either that have end stations attached to their assigned VLAN or that connect those LANs and, thus, define the current practical extent of the VLAN (7.5).

e) Automatic inclusion and removal of Bridge Ports in the VLAN, through configuration of Dynamic VLAN Registration Entries by means of MVRP (8.8.5 and 11.2) or MIRP (Clause 39);

f) Explicit configuration of management controls associated with the operation of MVRP and MIRP by means of Static VLAN Registration Entries (8.8.2 and 11.2);

Items e) and f) are only supported by VLAN Bridges, while all other items in the list above are supported by every Bridge.

8.1.6 Traffic expediting

A Bridge classifies frames into traffic classes in order to expedite transmission of frames generated by critical or time-sensitive services. The function that supports the use and maintenance of information for this purpose is

a) Explicit configuration of traffic class information associated with the Ports of the Bridge.

8.1.7 Conversion of frame formats

A VLAN Bridge adds and removes tag headers (9.3) from frames and performs the associated frame translations that may be required. The function that supports the use and maintenance of information for this purpose is

a) Explicit configuration of tagging requirements on transmission for each Port (8.8.2, 6.9.2).

NOTE—As all incoming frames, including priority-tagged frames, are classified as belonging to a VLAN, the transmitting Port transmits VLAN-tagged frames or untagged frames. Hence, a station sending a priority-tagged frame via a Bridge will receive a response that is either VLAN-tagged or untagged, as described in 8.5.

8.2 Bridge architecture

A Bridge comprises at least one Bridge component. A Bridge component comprises

a) A MAC Relay Entity that interconnects the Bridge's Ports;

b) At least two Ports;

c) Higher layer entities, including at least a Spanning Tree Protocol Entity.

The VLAN Bridge architecture is illustrated in Figure 8-2. The MAC Relay Entity handles the media access method-independent functions of relaying frames among Bridge Ports, filtering frames, and learning filtering information. It uses the EISS (6.8, 6.9) provided by each Bridge Port.

!image

Figure 8-2—VLAN Bridge architecture

The MAC Bridge architecture is illustrated in Figure 8-3. The main difference with the VLAN Bridge architecture is that it does not use the EISS and the VLAN-unaware MAC relay entity is supported by the ISS.

!image

Figure 8-3—MAC Bridge architecture

Each Bridge Port also functions as an end station and shall provide the MAC Service to an LLC Entity that operates LLC Type 1 procedures to support protocol identification, multiplexing, and demultiplexing, for PDU transmission and reception by the Spanning Tree Protocol Entity and other higher layer entities. Other types of LLC procedures can also be supported for use by other protocols. The Bridge Port provides additional MSAPs if those are explicitly required by the specifications of the attached higher layer entities. Each instance of the MAC Service is provided to a distinct LLC Entity that supports protocol identification, multiplexing, and demultiplexing, for PDU transmission and reception by one or more higher layer entities.

NOTE—For simplicity of specification, this standard refers to a single LLC Entity that can provide both the procedures specified by ISO/IEC 8802-2 and EtherType protocol discrimination in the cases where the media access method for the attached LAN supports the latter.

If the Bridge Port can be directly attached to an IEEE 802 LAN, an instance of the MAC for that LAN type is permanently associated with the Port, handles the media access method-specific functions (MAC protocol and procedures), and provides an instance of the ISS as specified in IEEE Std 802.1AC to support frame transmission and reception by the other processes and entities that compose the Port.

Figure 8-2 illustrates a VLAN Bridge, and Figure 8-3 illustrates a MAC Bridge, with two Ports, each directly connected to a LAN.

8.3 Model of operation

The model of operation is simply a basis for describing the functionality of the Bridge. It is in no way intended to constrain real implementations of a Bridge; these may adopt any internal model of operation compatible with the externally visible behavior that this standard specifies. Conformance of equipment to this standard is purely in respect of observable protocol.

The processes and entities that model the operation of a Bridge Port include

a) A Bridge Port Transmit and Receive Process (8.5) that

1) Receives and transmits frames from and to the attached LAN (8.5, 6.8, 6.9, IEEE Std 802.1AC);

2) Can filter received frames if the VLAN tag is absent, or present, or conveys a null VID;

3) Classifies received frames into VLANs, assigning each a VID value;

4) Determines the format, VLAN-tagged or untagged, of transmitted frames;

5) Delivers and accepts frames to and from the MAC Relay Entity and LLC Entities;

b) The LLC Entity or Entities that support Higher Layer Entities such as

1) Spanning Tree Protocol;

2) Multiple Registration Protocol (MRP);

3) Bridge Management;

4) Linktrace response.

c) Zero or more CFM entities, each of which can be one of the following:

1) An MA Endpoint (MEP);

2) An MA Intermediate Point (MIP); or

3) A Linktrace Output Multiplexer (LOM).

As Bridge Ports on MAC Bridges provide only the ISS, items a2), a3), and a4) in the list above are not supported by MAC Bridges.

d) The Forwarding Process (8.6) that

1) Enforces loop-free active topologies for all frames (8.1.3, 8.4, 8.6.1);

2) Filters frames using their VID and destination MAC addresses (8.1.4, 8.6.2, 8.6.3, 8.6.4);

3) Optionally, classifies and meters received frames that are to be relayed to other Bridge Ports (8.6.5);

4) Forwards received frames that are to be relayed to other Bridge Ports (8.6.6, 8.6.7, 8.6.8);

e) The Learning Process (8.7) that observes the source addresses of frames received on each Port, and updates the FDB (8.1.5, 8.4);

f) The FDB (8.8) that holds filtering information and supports queries by the Forwarding Process about whether frames with given values of VID and destination MAC address field can be forwarded to a given Port.

NOTE 1—The processes and entities that model the operation of the VLAN-unaware MAC Relays on MAC Bridges are the same as the ones described above but excluding any use or qualification based on VID values.

Figure 8-4 illustrates a single instance of frame relay between the Ports of a Bridge with two Ports.

NOTE 2—In Figure 8-4, Figure 8-5, Figure 8-6, and Figure 8-7, the EISS is used by the VLAN-aware MAC Relay entities and the ISS is used by the VLAN-unaware MAC Relay entities.

!image

Figure 8-4—Relaying MAC frames

Figure 8-5 illustrates the inclusion of information carried by a single frame, received on one of the Ports of a Bridge with two Ports, in the FDB.

!image

Figure 8-5—Observation of network traffic

Figure 8-6 illustrates the operation of the Spanning Tree Protocol Entity.

!image

Figure 8-6—Operation of Spanning Tree Protocol Entity

Figure 8-7 illustrates the operation of the MRP Entity (8.11).

!image

Figure 8-7—Operation of MRP

Higher Layer Entities that require only one point of attachment for the Bridge as a whole may attach to an LLC Entity that uses an instance of the MAC Service provided by a Management Port. A Management Port does not use an instance of the ISS to attach to a network but uses the Bridge Port Transmit and Receive Process and the MAC Relay Entity to provide connectivity to other Bridge Ports and the attached LANs.

NOTE 3—Management port functionality may also be provided by an end station connected to an IEEE 802 LAN that is wholly contained within the system that incorporates the Bridge. The absence of external connectivity to the LAN means that the management port is always forwarding.

Figure 8-8 illustrates the reception and transmission by an entity attached to a Management Port.

!image

Figure 8-8—Management Port transmission and reception

Figure 8-8 illustrates the operation of the IPS Control entity. The IPS Control entity functions as an intermediary between the Bridge Management entity and the FDB for operations related to TESIs associated with an IPG. Infrastructure Segment MEPs associated with an IPG communicate the operational state of the associated Infrastructure Segment to the IPS control entity (26.11.3).

!image

Figure 8-8—Infrastructure Segment MEP placement in a PNP

8.4 Active topologies, learning, and forwarding

An active topology is the connectivity provided, for frames with a specified set of VID, destination address, and source address values, by interconnecting the LANs and Bridges in a bridged network with forwarding Bridge Ports.

The distributed spanning tree algorithms and protocols, i.e., RSTP (Clause 13), MSTP (Clause 13), and ISIS-SPB (Clause 27), construct one or more active topologies, each simply and fully connected for frames being associated with any given VLAN and transmitted from any end station to any other. The forwarding and learning performed by each Bridge Port for each spanning tree is dynamically managed by RSTP, MSTP, or ISIS-SPB to prevent temporary loops and reduce excessive traffic in the network while minimizing denial of service following any change in the physical topology of the network.

PBB-TE enables construction of active topologies by the external agent that is responsible for setting up Ethernet Switched Paths (ESPs).

Any port that is not enabled, i.e., has MAC_Operational (IEEE Std 802.1AC) False or has been excluded from the active topology by management setting of the Administrative Bridge Port State to Disabled, has both forwarding and learning disabled for all spanning trees and ESPs.

If the Bridge Port is enabled, PBB-TE disables learning and enables forwarding for all frames allocated to each ESP-VID. An external agent manages the FDB to control the forwarding of frames with particular values of ESP-VID and destination MAC address.

The term Port State summarizes per-tree combinations of forwarding and learning, and any additional per-tree variables used by a given spanning tree protocol to enforce the active topologies it has calculated, and is used by RSTP and MSTP as follows. Any port that has learning and forwarding disabled is assigned the Port

State Discarding. A Port that has learning enabled but forwarding disabled has the Port State Learning, and a Port that both learns and forwards frames has the Port State Forwarding. However, the RSTP and MSTP state machines (Clause 13) do not control the Port State directly but use independent forwarding and learning variables for each tree.

ISIS-SPB controls both forwarding and learning variables for each SPT and Bridge Port directly when used to support Shortest Path Bridging VID (SPBV, Clause 27) just like RSTP and MSTP. ISIS-SPB disables learning and sets forwarding to TRUE when supporting Shortest Path Bridging MAC (SPBM, Clause 27).

RSTP constructs a single spanning tree, the CST, and maintains a single Port State for each Bridge Port. SST Bridges allocate all frames to that single spanning tree irrespective of their VLAN classification or source and destination MAC addresses.

MSTP constructs multiple spanning trees, the CIST and additional MSTIs, and maintains a Port State for each spanning tree for each Port. An MST Bridge allocates all frames classified as belonging to a given VLAN to the CIST or to one of the MSTIs using the MST Configuration Table. An MSTID of 0 identifies the CIST. A reserved MSTID value (TE-MSTID) is used to identify VIDs for use by PBB-TE with ESPs. Further MSTID values are used to identify the use of SPBV or SPBM. A single VID is used to identify frames assigned to any given VLAN that is supported by the CIST or an MSTI. That VID is used by the Forwarding Process (8.6) to identify the spanning tree for the relayed frame, and thus identifies the applicable Port State.

ISIS-SPB constructs symmetric (Clause 3) SPTs rooted at each Bridge within an SPT Region, and maintains independent forwarding and learning variables for each SPT for each Bridge Port.

Each frame classified as belonging to a VLAN supported by SPBV, is allocated to an SPT rooted at the Bridge that first relays the frame into the Region. If a C-VLAN, S-VLAN, or B-VLAN is supported by SPBV (Clause 27) the frame is assigned a Shortest Path VLAN Identifier (SPVID) that is used by the Forwarding Process (8.6) to identify both the VLAN and the SPT, and thus identifies the applicable learning and forwarding values.

If a B-VLAN is supported by SPBM, (Clause 27) the frame is assigned a B-VID value that identifies the frame as subject to SPBM and identifies the B-VLAN and the SPT Set (Clause 3). The SPT is identified (from among those in that set) by the source address of the frame (B-SA), which identifies the SPT root. When ISIS-SPB sets forwarding True for that SPT, a Dynamic Filtering Entry for that B-VID, source address tuple is included in the FDB so that it passes the active topology enforcement check (8.6.1). If a B-VLAN is supported by SPBM, learning is disabled for all frames for that B-VID.

Figure 8-6 illustrates the operation of the Spanning Tree Protocol Entity, which operates the spanning tree algorithm and its related protocols, and its modification of Port state information as part of determining the active topology of the network.

Figure 8-4 illustrates the Forwarding Process's use of the Port State: first, for a Port receiving a frame, to determine whether the received frame is to be relayed through any other Ports; and second, for another Port in order to determine whether the relayed frame is to be forwarded through that particular Port.

Figure 8-5 illustrates the use of the Port state information for a Port receiving a frame, in order to determine whether the station location information is to be incorporated in the FDB.

8.5 Bridge Port Transmit and Receive

The Bridge Port Transmit and Receive process supports the attachment of the Bridge Port to a network. It comprises the following functions:

a) In a VLAN Bridge component, mapping between the EISS (6.8) provided to the MAC Relay Entity, and the ISS (IEEE Std 802.1AC), adding, recognizing, interpreting, and removing VLAN tags as specified in 6.9 and illustrated in Figure 8-9;

b) In a MAC Bridge component, an optional shim (IEEE Std 802.1AC) that uses and provides the ISS (IEEE Std 802.1AC), recognizing and interpreting VLAN tags as specified in 6.20 and illustrated in Figure 8-10.

c) Connectivity, as specified in 8.5.1 (for non-TPMR Bridges) or 8.5.2 (for TPMRs), between the following ISS access points:

1) That provided by the MAC Entity for the LAN attached to the Port, as specified in IEEE Std 802.1AC;

2) That supporting the MAC Relay Entity; and

3) One or more that support Higher Layer Entities attached to the Port (8.5.3).

A single Port for a Bridge, known as the Management Port, may support Higher Layer Entities without providing a point of attachment to a LAN (see Figure 8-8).

8.5.1 Bridge Port connectivity

Each M_UNITDATA.indication provided by the ISS access point for an attached LAN [(1) in Figure 8-9] shall result in a corresponding M_UNITDATA.indication with identical parameters at each of the access points supporting the MAC Relay and Higher Layer Entities [(2), (3a) and (3b)]. Each M_UNITDATA.request from the ISS access point supporting the MAC Relay Entity shall result in a corresponding M_UNITDATA.indication with identical parameters at each of the access points for the Higher Layer Entities [(3a) and (3b)], and a corresponding M_UNITDATA.request with identical parameters at the access point for the LAN [(1)]. Each M_UNITDATA.request from an ISS access point supporting a Higher Layer Entity shall result in a corresponding M_UNITDATA.indication with identical parameters at the access points for the MAC Relay Entity, and at other access points for Higher Layer Entities, and a corresponding M_UNITDATA.request with identical parameters at the access point for the LAN.

!image

Figure 8-9—Bridge Port Transmit and Receive

NOTE—Figure 8-9 shows the relative position of the Bridge Port Transmit and Receive process and the VLAN tagging function (6.9) for a Customer Bridge or Provider Bridge that does not support CFM. For the relative positioning of these functions in a Bridge supporting CFM, see Figure 22-4. For the relative positioning of these functions in a BEB, see Figure 26-2.

The MAC_Enabled, MAC_Operational, and operPointToPointMAC status parameters for the ISS access point for the MAC Relay Entity and Higher Layer Entities [(2), (3a), and (3b) in Figure 8-9] shall take the same value as that for the LAN (1) if that is present, and shall be True otherwise (i.e., if the Port is a Management Port).

The consequence of the above connectivity is that frames relayed to a Bridge Port are both submitted to that Port's MAC Service users and transmitted on the attached LAN (see 8.13.9).

8.5.2 TPMR Port connectivity

Each M_UNITDATA.indication provided by the ISS access point for an attached LAN [(1) in Figure 8-10] shall result in a corresponding M_UNITDATA.indication with identical parameters at each of the access points supporting the MAC Relay and Higher Layer Entities[(2), (3a), and (3b)].

!image

Figure 8-10—TPMR Port Transmit and Receive

Each M_UNITDATA.request from the ISS access point supporting the MAC Relay Entity (2) or a Higher Layer Entity [(3a) or (3b)] shall result in a corresponding M_UNITDATA.request with identical parameters at the access point for the LAN (1).

NOTE—These connectivity rules allow a higher layer entity to “listen” on both TPMR Ports to be able to determine the LAN on which a particular frame was received, and ensure that any frames sent by a higher layer entity are propagated only on the LAN associated with the Port on which the frame is transmitted. This differs from the propagation rules for other Bridges, where frames transmitted by a higher layer entity are also submitted to the forwarding process, and frames transmitted by the Forwarding Process on a given Port are received by any higher layer entity associated with that Port.

8.5.3 Support of Higher Layer Entities

The MAC Service is provided to a Higher Layer Entity using one of ISS access points provided for that purpose by the Bridge Port Connectivity function (8.5.1) or the TPMR Port Connectivity function (8.5.2).

Each ISS M_UNITDATA.indication with a destination MAC address that is either the individual address of an MSAP provided by the Bridge Port or a group address used by the attached LLC Entity shall cause an MA_UNITDATA.indication at that MSAP with destination address, source address, MSDU, and priority parameters identical to those in the M_UNITDATA.indication. No other indications or frames give rise to indications to the MAC Service user.

Each MA_UNITDATA.request at the MSAP shall result in an M_UNITDATA.request at the ISS access point with identical destination address, source address, MSDU, and priority parameters.

NOTE 1—Appropriate selection of the PVID for a Management Port facilitates attachment of an Internet Protocol (IP) stack supporting an SNMP Management Agent to any selected VID relayed by the Bridge. This function is not supported in Bridges that do not support the EISS, such as TPMRs.

NOTE 2—Higher Layer Entities attached to a Bridge Port can use the VLAN tag of received frames to achieve VLAN-awareness.

8.6 The Forwarding Process

Each frame submitted to the MAC Relay Entity shall be forwarded subject to the constituent functions of the Forwarding Process (Figure 8-11). Each function is described in terms of the action taken for a given frame received on a given Port (termed “the reception Port”). The frame can be forwarded for transmission on some Ports (termed “transmission Ports”) and discarded without being transmitted at the other Ports.

!image

Figure 8-11—Forwarding Process functions

NOTE 1—IEEE Std 802.1Q, 2003 Edition, included frame formatting and FCS recalculation functions within the Forwarding Process. This standard now places those functions below the EISS interface, to allow the specification of additional methods for Bridge Port support of the EISS.

NOTE 2—IEEE Std 802.1D-2004 [B10], included priority mapping functions within the Forwarding Process. This standard now places this function below the ISS interface.

NOTE 3—The Forwarding Process models the MAC relay function and does not take into consideration what may occur once frames are passed to the Bridge Port for transmission. Conformant implementations of some media access methods can vary the transmission order in apparent violation of the transmission selection rules when observing frames on the medium. It may therefore not be possible to test conformance to this standard for some implementations simply by relating observed LAN traffic to the functionality of the forwarding process; tests also have to allow for the (conformant) behavior of the MAC.

Figure 8-4 illustrates the operation of the Forwarding Process in a single instance of frame relay between the Ports of a Bridge with two Ports.

8.6.1 Active topology enforcement

To prevent data loops and unwanted learning of source MAC addresses, the Forwarding Process determines the values (TRUE or FALSE) of the learning and forwarding controls (8.4) appropriate to each received frame and Bridge Port. If learning is TRUE for the reception Port and ingress filtering (8.6.2) would not cause the received frame to be discarded, the source address and VID are submitted to the Learning Process.

NOTE 1—VIDs are not applicable to MAC Bridges and only the source address is submitted to the Learning Process.

If forwarding is TRUE for the reception Port, and either the EVBMode parameter value (40.4) for the Port is not “EVB Bridge” or the value of the operReflectiveRelayControl parameter for the Port is FALSE, each Bridge Port, other than the reception Port, with forwarding TRUE is identified as a potential transmission Port. If forwarding is TRUE for the receiving Port and the EVBMode parameter value (40.4) for the Port is “EVB Bridge” and the operReflectiveRelayControl parameter value for the Port is TRUE, each Bridge Port, including the reception Port, with forwarding TRUE is identified as a potential transmission Port.

In an edge relay (ER), the forwarding process may set learning FALSE for all frames.

An SST Bridge supports a single active topology, the CST. For each Bridge Port, RSTP determines a single value for forwarding and a single value for learning (8.4) for all frames.

Bridges with MST, PBB-TE, or SPB capabilities use the VID of the received frame to determine forwarding and learning for that frame for each Bridge Port that is enabled, i.e., has MAC_Operational True and an Administrative Bridge Port State of Enabled, as follows:

If the Bridge supports PBB-TE, and the VID is an ESP-VID, forwarding is TRUE and learning is FALSE. Control over the active topology of each ESP is provided by configuration of Static Filtering Entries in the FDB (8.8.1, 25.10.1).

If the Bridge uses MSTP to configure the CIST, and the VID identifies a VLAN assigned to the CIST, forwarding and learning are as determined by MSTP (Clause 13) for the CIST.

If the Bridge uses MSTP to configure MSTIs, and the VID identifies a VLAN assigned to an MSTI calculated by MSTP, forwarding and learning are as determined by MSTP for that MSTI.

If the Bridge uses ISIS-SPB to configure the CIST, and the VID identifies a VLAN assigned to the CIST, forwarding and learning take the value of forwarding determined by ISIS-SPB (Clause 28) for the CIST.

If the Bridge uses ISIS-SPB, and the VID is used by SPBV as an SPVID, both forwarding and learning take the value of forwarding determined by ISIS-SPB for the SPT identified by that SPVID.

If the Bridge uses ISIS-SPB and the VID identifies a VLAN supported by SPBM, then for that VID

— Learning is False for all Bridge Ports;

Forwarding is True for the reception Port if and only if a Dynamic Filtering Entry for the frame's source address exists and specifies Forward for that Port; and

— Forwarding is True for all other Bridge Ports.

NOTE 2—Effective control over the egress component of an SPT for VLANs supported by SPBM is provided by ISIS-SPB configuration of (a) a Dynamic Filtering Entry for the VLAN's VID and Root MAC address (for unicast frames); and (b) MAC Address Registration Entries for the VID- and SPT-specific group MAC addresses (for multicast frames); and (c) a MAC Address Registration Entry for the VID to filter “All Unregistered Group Addresses” at all Ports.

All Bridges other than SST Bridges implement the MST Configuration Table (8.9.1). The use of VIDs to determine learning and forwarding, as required by this clause, shall be consistent with that table as follows. VIDs allocated by the MST Configuration Table (8.9.1) of value

— CIST-MSTID (0x000) are CIST VIDs.

— SPBM-MSTID (0xFFC) are Base VIDs supported by SPBM.

— SPBV-MSTID (0xFFD) are Base VIDs supported by SPBV.

— TE-MSTID (0xFFE) are ESP-VIDs supported by PBB-TE.

— SPVID-MSTID (0xFFFF) are VIDs reserved for use by ISIS-SPB as SPVIDs.

— All VIDs allocated to other values of MSTID are assigned to the MSTI identified by that MSTID.

NOTE 3—While the MST Configuration Table is capable of detailing the configuration of each SPVID, it captures the allocation of Base VIDs only. Individual allocation of SPVIDs are captured in the ISIS-SPB database, the SPB ECT Static Entry (12.25.4), and in the port VID translation tables. By specifying only the type of VID and its allocation to SPB, backwards compatibility with STP, RSTP, and MSTP is maintained.

8.6.1.1 Requirements for the use of reflective relay

VEPA ERs (8.6.3.1) used in EVB (Clause 40) require reflective relay (40.4, 8.6.1) to be enabled on an attached EVB Bridge SBP in order to ensure that all VSIs connected to the VEPA ER are able to receive frames transmitted on one of the other VSIs. The following requirements ensure that a device operates correctly when using reflective relay:

a) The operation of the device shall be such that it prevents the establishment of loops, i.e., the device shall not both request and provide reflective relay on the same port.

b) The device shall ensure that any frame that it transmits on a given port, and that is reflected back to the device through the attached Bridge Port, is filtered by the device in order to prevent it being delivered to the originating port.

c) Any device requesting reflective relay is responsible for performing frame replication as necessary for delivery to multiple ports.

NOTE—Information that can be used to assist in meeting these requirements is the source MAC address and the FID derived from the VID.

8.6.2 Ingress filtering

Each Port may support an Enable Ingress Filtering parameter. A frame received on a Port that is not in the member set (8.8.10) associated with the frame's VID shall be discarded if this parameter is set. The default value for this parameter is reset, i.e., Disable Ingress Filtering, for all Ports. Any Port that supports setting this parameter shall also support resetting it. The parameter may be configured by the management operations defined in Clause 12.

This function is not applicable to VLAN-unaware MAC Relays.

8.6.3 Frame filtering

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 FDB 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 FDB 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. Item b), specifying a VID value, is not applicable to VLAN-unaware MAC Relays. Flow hash is applicable only on Bridges supporting flow filtering (44.2).

Each of the reserved MAC addresses specified in Table 8-1 shall be permanently configured in the FDB in C-VLAN components and ERs. Each of the reserved MAC addresses specified in Table 8-2 shall be permanently configured in the FDB in S-VLAN components. Each of the reserved MAC addresses specified in Table 8-3 shall be permanently configured in the FDB in TPMR components. The FDB entries for reserved MAC addresses shall specify filtering for all Bridge Ports and all VIDs. Management shall not provide the capability to modify or remove entries for reserved MAC addresses.

The addresses in Table 8-1, Table 8-2, and Table 8-3 determine the scope of propagation of PDUs within a Bridged Network, as follows:

f) The Nearest Bridge group address is an address that no conformant TPMR component, S-VLAN component, C-VLAN component, or MAC Bridge can forward. PDUs transmitted using this destination address, or any of the other addresses that appear in all three tables, can therefore travel no further than those stations that can be reached via a single individual LAN from the originating station. Hence the Nearest Bridge group address is also known as the Individual LAN Scope group address.

g) The Nearest non-TPMR Bridge group address is an address that no conformant S-VLAN component, C-VLAN component, or MAC Bridge can forward; however, this address is relayed by a TPMR component. PDUs using this destination address, or any of the other addresses that appear in both Table 8-1 and Table 8-2 but not in Table 8-3, will be relayed by any TPMRs but will propagate no further than the nearest S-VLAN component, C-VLAN component, or MAC Bridge.

h) The Nearest Customer Bridge group address is an address that no conformant C-VLAN component or MAC Bridge can forward; however, it is relayed by TPMR components and S-VLAN components. PDUs using this destination address, or any of the other addresses that appear in Table 8-1 but not in either Table 8-2 or Table 8-3, will be relayed by TPMR components and S-VLAN components but will propagate no further than the nearest C-VLAN component or MAC Bridge.

Table 8-1—C-VLAN and MAC Bridge component Reserved addresses

<table><tr><td>Assignment</td><td>Value</td></tr><tr><td>Bridge Group Address, Nearest Customer Bridge group addressa</td><td>01-80-C2-00-00-00</td></tr><tr><td>IEEE MAC-specific Control Protocols group address</td><td>01-80-C2-00-00-01</td></tr><tr><td>IEEE 802.3 Slow_Protocols_Multicast address</td><td>01-80-C2-00-00-02</td></tr><tr><td>Nearest non-TPMR Bridge group address</td><td>01-80-C2-00-00-03</td></tr><tr><td>IEEE MAC-specific Control Protocols group address</td><td>01-80-C2-00-00-04</td></tr><tr><td>Reserved for future standardization</td><td>01-80-C2-00-00-05</td></tr><tr><td>Reserved for future standardization</td><td>01-80-C2-00-00-06</td></tr><tr><td>Metro Ethernet Forum ELMI protocol group addressb</td><td>01-80-C2-00-00-07</td></tr><tr><td>Provider Bridge Group Address</td><td>01-80-C2-00-00-08</td></tr><tr><td>Reserved for future standardization</td><td>01-80-C2-00-00-09</td></tr><tr><td>Reserved for future standardization</td><td>01-80-C2-00-00-0A</td></tr><tr><td>Reserved for future standardization</td><td>01-80-C2-00-00-0B</td></tr><tr><td>Reserved for future standardization</td><td>01-80-C2-00-00-0C</td></tr><tr><td>Provider Bridge MVRP Address</td><td>01-80-C2-00-00-0D</td></tr><tr><td>Individual LAN Scope group address<eq>^c</eq>, Nearest Bridge group address</td><td>01-80-C2-00-00-0E</td></tr><tr><td>Reserved for future standardization</td><td>01-80-C2-00-00-0F</td></tr></table>

$^{a}$ As stated in 13.41, in a Provider Edge Bridge, a C-VLAN component supporting a single service instance (i.e., with a single PEP) may forward (not filter) frames with the Nearest Customer Bridge Address as the destination address.

$^{b}$ This address is not exclusively reserved for this purpose; other uses are reserved for future standardization.

$^{c}$ It is intended that no IEEE 802.1 relay device will be defined that will forward frames that carry this destination address.

Table 8-2—S-VLAN component Reserved addresses

<table><tr><td>Assignment</td><td>Value</td></tr><tr><td>IEEE MAC-specific Control Protocols group address</td><td>01-80-C2-00-00-01</td></tr><tr><td>IEEE 802.3 Slow_Protocols_Multicast address</td><td>01-80-C2-00-00-02</td></tr><tr><td>Nearest non-TPMR Bridge group address</td><td>01-80-C2-00-00-03</td></tr><tr><td>IEEE MAC-specific Control Protocols group address</td><td>01-80-C2-00-00-04</td></tr><tr><td>Reserved for future standardization</td><td>01-80-C2-00-00-05</td></tr><tr><td>Reserved for future standardization</td><td>01-80-C2-00-00-06</td></tr><tr><td>Metro Ethernet Forum ELMI protocol group <eq>address^a</eq></td><td>01-80-C2-00-00-07</td></tr><tr><td>Provider Bridge Group Address</td><td>01-80-C2-00-00-08</td></tr><tr><td>Reserved for future standardization</td><td>01-80-C2-00-00-09</td></tr><tr><td>Reserved for future standardization</td><td>01-80-C2-00-00-0A</td></tr><tr><td>Individual LAN Scope group <eq>address^b</eq>, Nearest Bridge group address</td><td>01-80-C2-00-00-0E</td></tr></table>

$^{a}$ This address is not exclusively reserved for this purpose; other uses are reserved for future standardization.

$^{b}$ It is intended that no IEEE 802.1 relay device will be defined that will forward frames that carry this destination address.

Table 8-3—TPMR component Reserved addresses

$^{a}$ It is intended that no IEEE 802.1 relay device will be defined that will forward frames that carry this destination address.

NOTE 1—The reserved MAC addresses specified in Table 8-1, Table 8-2, and Table 8-3 determine the span of connectivity for the protocol frames using the address; they do not identify the protocol. The protocols are identified by the EtherType field following the address fields.

NOTE 2—An instance of IEEE 802.1AX Link Aggregation Control Protocol (LACP) intended to operate between non-TPMR Bridges, even through a TPMR, can use the Nearest non-TPMR Bridge group address. See K.2 for discussion of the use of TPMRs in a link using LACP.

8.6.3.1 Virtual edge port aggregator (VEPA) filtering

A VEPA ER filters frames as follows.

If the receiving port is a DRP, then the URP shall be selected as the only transmission Port.

If the receiving port is a URP, then in addition to the filtering specified in 8.6.3, if there is a filtering entry that specifies forwarding for the source MAC address and VLAN of the frame for any DRP, then that DRP shall be removed from the list of potential transmission Ports.

8.6.4 Egress filtering

This function is not applicable to VLAN-unaware MAC Relays.

Any Port that is not in the member set (8.8.10) for the frame's VID is removed from the set of potential egress Ports.

8.6.5 Flow classification and metering

The Forwarding Process may apply flow classification and metering to frames that are received on a Bridge Port and have one or more potential transmission ports.

Flow classification identifies a subset of traffic (frames) that may be subject to the same treatment in terms of metering and forwarding. Flow classification rules may be based on

a) Destination MAC address

b) Source MAC address

c) VID

d) Priority

Item c), specifying a VID value, is not applicable to VLAN-unaware MAC Relays.

Frames classified using the same set of classification rules are subject to the same flow meter. The flow meter can change the drop_eligible parameter associated with each frame and can discard frames on the basis of the following parameters for each received frame and previously received frames, and the time elapsed since those frames were received:

e) The received value of the drop_eligible parameter

f) The mac_service_data_unit size

The flow meter shall not base its decision on the parameters of frames received on other Bridge Ports, or on any other parameters of those Ports. The metering algorithm described in the Metro Ethernet Forum (MEF) Technical Specification 10.3 (MEF 10.3) [B45] should be used.

NOTE 1—Changing the value of the drop_eligible parameter may change the contents of the frame, depending on how the frame is tagged when transmitted, which may then require updating the frame_check_sequence. Mechanisms for conveying information from ingress to egress that the frame_check_sequence may require updating are implementation dependent.

NOTE 2—The flow meter described here can encompass a number of meters, each with a simpler specification. However, given the breadth of implementation choice permitted, further structuring to specify, for example, that frames can bypass a meter or are subject only to one of a number of meters provides no additional information.

NOTE 3—Although flow metering is applied after egress (Figure 8-11), the meter(s) operate per reception Port (see first sentence of 8.6.5), not per potential transmission Port(s).

8.6.6 Queuing frames

The Forwarding Process shall queue each received frame to each of the potential transmission Ports (8.6.1, 8.6.3, 8.6.4).

NOTE 1—The Forwarding Process is modeled as receiving a frame as the parameters of a data indication and transmitting through supplying the parameters of a data request. Queuing a frame awaiting transmission amounts to placing the parameters of a data request on an outbound queue.

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 applicable only on Bridges supporting flow filtering (44.2).

VID is not applicable to VLAN-unaware MAC Relays and the above combinations will exclude any reference to VID when applied to MAC Bridges.

The Forwarding Process provides one or more queues for a given Bridge Port, each corresponding to a distinct traffic class. Each frame is mapped to a traffic class using the Traffic Class Table for the Port and the frame's priority. Traffic class tables may be managed. Table 8-4 shows the recommended mapping for the number of classes implemented, in implementations that do not support the credit-based shaper transmission selection algorithm (8.6.8.2). The requirements for priority to traffic class mappings in implementations that support the credit-based shaper transmission selection algorithm are defined in 34.5. Up to eight traffic classes may be supported, allowing separate queues for each priority.

NOTE 2—Different numbers of traffic classes may be implemented for different Ports. Ports with media access methods that support a single transmission priority, such as Ethernet, can support more than one traffic class.

NOTE 3—A queue in this context is not necessarily a single FIFO data structure. A queue is a record of all frames of a given traffic class awaiting transmission on a given Bridge Port. The structure of this record is not specified. The transmission selection algorithm (8.6.8) determines which traffic class, among those classes with frames available for transmission, provides the next frame for transmission. The method of determining which frame within a traffic class is the next available frame is not specified beyond conforming to the frame ordering requirements of this subclause. This allows a variety of queue structures such as a single FIFO, or a set of FIFOs with one for each pairing of ingress and egress ports (i.e., Virtual Output Queuing), or a set of FIFOs with one for each VLAN or priority, or hierarchical structures.

In a congestion aware Bridge (Clause 30), the act of queuing a frame for transmission on a Bridge Port can result in the Forwarding Process generating a CNM. The CNM is injected back into the Forwarding Process (8.6.1) as if it had been received on that Bridge Port.

Table 8-4—Recommended priority to traffic class mappings

<table><tr><td rowspan="2" colspan="2"></td><td colspan="8">Number of available traffic classes</td></tr><tr><td>1</td><td>2</td><td>3</td><td>4</td><td>5</td><td>6</td><td>7</td><td>8</td></tr><tr><td rowspan="8">Priority</td><td>0 (Default)</td><td>0</td><td>0</td><td>0</td><td>0</td><td>0</td><td>1</td><td>1</td><td>1</td></tr><tr><td>1</td><td>0</td><td>0</td><td>0</td><td>0</td><td>0</td><td>0</td><td>0</td><td>0</td></tr><tr><td>2</td><td>0</td><td>0</td><td>0</td><td>1</td><td>1</td><td>2</td><td>2</td><td>2</td></tr><tr><td>3</td><td>0</td><td>0</td><td>0</td><td>1</td><td>1</td><td>2</td><td>3</td><td>3</td></tr><tr><td>4</td><td>0</td><td>1</td><td>1</td><td>2</td><td>2</td><td>3</td><td>4</td><td>4</td></tr><tr><td>5</td><td>0</td><td>1</td><td>1</td><td>2</td><td>2</td><td>3</td><td>4</td><td>5</td></tr><tr><td>6</td><td>0</td><td>1</td><td>2</td><td>3</td><td>3</td><td>4</td><td>5</td><td>6</td></tr><tr><td>7</td><td>0</td><td>1</td><td>2</td><td>3</td><td>4</td><td>5</td><td>6</td><td>7</td></tr></table>

NOTE—The rationale for these mappings is discussed in Annex I.

8.6.7 Queue management

A frame queued for transmission on a Port shall be removed from that queue

a) Following a transmit data request. No further attempt shall be made to transmit the frame on that Port even if the transmission is known to have failed.

b) If that is necessary to ensure that the maximum Bridge transit delay (6.5.6) will not be exceeded at the time at which the frame would subsequently be transmitted.

c) If the transmission Port is no longer forwarding for that frame (8.4, 8.6.1). Frames entering the queue subsequent to the transition out of the Forwarding state (e.g., CFM frames from Down MPs, as described in 22.1, Figure 22-4, and Figure 22-7) are not discarded.

NOTE 1—CFM frames may be excepted, and not removed from the queue, on a transition out of the Forwarding state (see 22.1.3).

The frame can be removed from the queue, and not subsequently transmitted

d) If the time for which buffering is guaranteed has been exceeded for that frame

e) By a queue management algorithm that attempts to improve the QoS provided by deterministically or probabilistically managing the queue depth based on the current and past queue depths.

Removal of a frame from a queue for any particular Port does not affect queuing of that frame for transmission on any other Port.

NOTE 2—Applicable queue management algorithms include RED (random early detection), and WRED (weighted random early detection) (IETF RFC 2309 [B22]). If the Bridge supports drop precedence, i.e., is capable of decoding or encoding the drop_eligible parameter from or to the PCP field of VLAN tags (6.9.3), the algorithm should exhibit a higher probability of dropping frames with drop_eligible True.

The probability of removing a frame with drop_eligible set shall not be less than that of removing a frame with drop_eligible False, all other conditions being equal. If a queue management algorithm is implemented, it should preferentially discard frames with drop_eligible True. If a Bridge supports encoding or decoding of drop_eligible from the PCP field of a VLAN tag (6.9.3) on any of its Ports, then it shall implement a boolean parameter Require Drop Encoding on each of its Ports with default value FALSE. If Require Drop Encoding is True and the Bridge Port cannot encode particular priorities with drop_eligible, then frames queued with those priorities and drop_eligible True shall be discarded and not transmitted.

8.6.8 Transmission selection

For each Port, frames are selected for transmission on the basis of the traffic classes that the Port supports and the operation of the transmission selection algorithms supported by the corresponding queues on that Port. For a given Port and supported value of traffic class, frames are selected from the corresponding queue for transmission if and only if

a) The operation of the transmission selection algorithm supported by that queue determines that there is a frame available for transmission; and

b) For each queue corresponding to a numerically higher value of traffic class supported by the Port, the operation of the transmission selection algorithm supported by that queue determines that there is no frame available for transmission.

In a port of a Bridge or station that supports PFC, a frame of priority n is not available for transmission if that priority is paused (i.e., if Priority_Paused[n] is TRUE (see 36.1.3.2)) on that port. When Transmission Selection is running above Link Aggregation, a frame of priority n is not available for transmission if that priority is paused on the physical port to which the frame is to be distributed.

NOTE 1—Two or more priorities can be combined in a single queue. In this case if one or more of the priorities in the queue are paused, it is possible for frames in that queue not belonging to the paused priority to not be scheduled for transmission.

NOTE 2—Mixing PFC and non-PFC priorities in the same queue results in non-PFC traffic being paused causing congestion spreading, and therefore is not recommended.

The strict priority transmission selection algorithm defined in 8.6.8.1 shall be supported by all Bridges as the default algorithm for selecting frames for transmission. The credit-based shaper transmission selection algorithm defined in 8.6.8.2, and the ETS algorithm defined in 8.6.8.3 may be supported in addition to the strict priority algorithm. Further transmission selection algorithms, selectable by management means, may be supported as an implementation option so long as the requirements of 8.6.6 are met.

The Transmission Selection Algorithm Table for a given Port assigns, for each traffic class that the Port supports, the transmission selection algorithm that is to be used to select frames for transmission from the corresponding queue. Transmission Selection Algorithm Tables may be managed, and allow the identification of vendor-specific transmission selection algorithms. The transmission selection algorithms are identified in the Transmission Selection Algorithm Table by means of integer identifiers, as defined in Table 8-5.

In implementations that do not support the credit-based shaper transmission selection algorithm, the recommended default configuration for the Transmission Selection Algorithm Tables is to assign the strict priority transmission selection algorithm to all supported traffic classes. In implementations that support the credit-based shaper transmission selection algorithm, the recommended default configuration for the Transmission Selection Algorithm Tables is defined in 34.5.

8.6.8.1 Strict priority algorithm

For a given queue that supports strict priority transmission selection, the algorithm determines that there is a frame available for transmission if the queue contains one or more frames. The order in which frames are selected for transmission from the queue shall maintain the ordering requirement specified in 8.6.6.

Table 8-5—Transmission selection algorithm identifiers

<table><tr><td>Transmission selection algorithm</td><td>Identifier</td></tr><tr><td>Strict priority (8.6.8.1)</td><td>0</td></tr><tr><td>Credit-based shaper (8.6.8.2)</td><td>1</td></tr><tr><td>Enhanced Transmission Selection (ETS) (8.6.8.3)</td><td>2</td></tr><tr><td>Reserved for future standardization</td><td>3–254</td></tr><tr><td>Vendor-specific Transmission Selection algorithm value for use with DCBX (D.2.9.8)</td><td>255</td></tr><tr><td>Vendor-specific</td><td>A four-octet integer, where the most significant 3 octets hold an OUI or CID value, and the least significant octet holds an integer value in the range 0–255 assigned by the owner of the OUI or CID.</td></tr></table>

8.6.8.2 Credit-based shaper algorithm

For a given queue that supports credit-based shaper transmission selection, the algorithm determines that a frame is available for transmission if the following conditions are all true:

a) The queue contains one or more frames.

b) The transmitAllowed signal for the queue is TRUE.

The order in which frames are selected for transmission from the queue shall maintain the ordering requirement specified in 8.6.6.

The following external parameters are associated with each queue that supports the operation of the credit-based shaper algorithm:

c) portTransmitRate. The transmission rate, in bits per second, that the underlying MAC Service that supports transmission through the Port provides. The value of this parameter is determined by the operation of the MAC.

d) idleSlope. The rate of change of credit, in bits per second, when the value of credit is increasing (i.e., while transmit is FALSE). The value of idleSlope can never exceed portTransmitRate. The value of idleSlope for a given queue is determined by the value of the operIdleSlope(N) parameter for that queue, as defined in 34.3.

The following internal parameters are associated with each queue that supports the credit-based shaper algorithm:

e) transmit. Takes the value TRUE for the duration of a frame transmission from the queue; FALSE when any frame transmission from the queue has completed.

f) credit. The transmission credit, in bits, that is currently available to the queue. If, at any time, there are no frames in the queue, and the transmit parameter is FALSE, and credit is positive, then credit is set to zero.

g) sendSlope. The rate of change of credit, in bits per second, when the value of credit is decreasing (i.e., while transmit is TRUE). The value of sendSlope is defined as follows:

s e n d S l o p e = (i d l e S l o p e - p o r t T r a n s m i t R a t e)

h) transmitAllowed. Takes the value TRUE when the credit parameter is zero or positive; FALSE when the credit parameter is negative.

NOTE 1—The value of credit is naturally constrained by the operating parameters for the algorithm, and also by the operation of any higher priority queues that use this algorithm. The lowest value that credit can reach depends on sendSlope and the largest frame that will be transmitted from the queue. This largest frame size is a consequence of the type of traffic that is being transmitted using the queue, rather than a limit imposed by the algorithm or by management. The highest value that can be accumulated in credit depends on idleSlope and the length of time that the algorithm may have to wait when the queue is not empty and there is other traffic being transmitted through the Port; for any given queue, that length of time is bounded, as discussed in Annex L, which also illustrates how the algorithm operates under varying conditions, and how its operation affects the maximum latency that can be experienced by SR traffic.

NOTE 2—In order for the credit-based shaper algorithm to operate as intended, it is necessary for all traffic classes that support the algorithm to be numerically higher than any traffic classes that support the strict priority algorithm defined in 8.6.8.1. The mapping of priorities onto traffic classes, and the choice of traffic classes that support particular transmission selection algorithms, is defined in 34.5.

Traffic classes using the credit-based shaper algorithm shall not use PFC and shall ignore the setting of the bits related to such classes in the PFC Enable bit vector (see D.2.11.6)

8.6.8.3 ETS algorithm

If ETS is enabled for a traffic class, transmission selection is performed based on the allocation of bandwidth to that traffic class. Bandwidth is distributed among ETS traffic classes that support ETS algorithm such that each traffic class is allocated available bandwidth in proportion to its TCBandwidth (see Clause 37).

For a given queue that supports ETS, the algorithm determines that there is a frame available for transmission if the following conditions are all true:

a) The queue contains one or more frames;

b) The ETS algorithm (37.3) determines that a frame should be transmitted from the queue; and

c) There are no frames available for transmission for any queues running strict priority or credit-based shaper algorithms.

The order in which frames are selected for transmission from the queue shall maintain the ordering requirement specified in 8.6.6.

8.7 The Learning Process

The Learning Process receives the source MAC addresses and VIDs, or only the source MAC addresses in the case of VLAN-unaware MAC Relays, of received frames from the Forwarding Process, subject to active topology enforcement (8.6.1) and the application of ingress filtering (8.6.2). The Learning Process is not invoked (8.6.1) for frames whose VID is an ESP-VID or identifies a VLAN supported by SPBM.

When invoked, the Learning Process shall create or update a Dynamic Filtering Entry (8.8.3) that specifies the reception Port for the frame's source address and, in the case of VLAN Bridge components, the frame's VID, if and only if the source address is an individual address, i.e., is not a group address, the resulting number of entries would not exceed the capacity of the FDB, and the filtering utility criteria for the receiving Bridge Port are met, as specified below.

If the FDB is already filled to capacity, but a new entry would otherwise be made, then an existing entry may be removed to make room for the new entry.

The purpose of filtering utility criteria is to reduce the capacity requirements of the FDB and to reduce the time for which service can be denied (6.5.1) by retaining filtering information learned prior to a change in the physical topology of the network. Filtering utility criteria shall be applied to the learning and retention of information for each FID (8.8.8). In Bridges other than EVB Bridges (5.23), enhanced filtering utility criteria may be implemented for any Bridge Port as specified below (8.7.2); if implemented, both the default (8.7.1) and the enhanced criteria shall be selectable by management. In EVB Bridges, the enhanced filtering utility criteria shall be implemented for all Bridge Ports, and the default filtering utility criteria shall not be implemented.

Figure 8-5 illustrates the operation of the Learning Process in the inclusion of station location information carried by a single frame, received on one of the Ports of a Bridge, in the FDB.

8.7.1 Default filtering utility criteria

The default for a VLAN Bridge is that the member set (8.8.10) for the frame's VID includes at least one Port.

NOTE—If the member set for a given VID is empty, that VID is not currently active, and the Bridge will filter all frames destined for that VID, regardless of their destination address.

The default filtering utility criteria are always met for MAC Bridges.

8.7.2 Enhanced filtering utility criteria

For a VLAN Bridge, the enhanced criteria are satisfied if at least one VID that uses the FID includes the reception Port and at least one other Port with a Port State of Learning or Forwarding in its member set, and:

a) The operPointToPointMAC parameter is FALSE for the reception Port; or

b) Ingress for the VID is permitted through a third Port; or

c) The reception Port has reflective relay enabled (40.4.2).

NOTE—The third port can, but is not required to, be in the member set.

For a MAC Bridge, the enhanced criteria are satisfied if there exists at least one Port different than the reception Port with a Port State of Learning or Forwarding, and:

d) The operPointToPointMAC parameter is FALSE for the reception Port; or

e) There exists third Port with a Port State of Learning or Forward; or

f) The reception Port has reflective relay enabled (40.4.2).

8.7.3 Ageing of Dynamic Filtering Entries

Dynamic Filtering Entries shall be automatically removed after a specified time, the Ageing Time, has elapsed since the entry was created or last updated by the Learning Process.

The ageing out of Dynamic Filtering Entries ensures that end stations that have been moved to a different part of the network will not be permanently prevented from receiving frames. It also takes account of changes in the active topology of the network that can cause end stations to appear to move from the point of view of the Bridge; i.e., the path to those end stations subsequently lies through a different Bridge Port.

The Ageing Time may be set by management (Clause 12). A range of applicable values and a recommended default is specified in Table 8-6; this is suggested to remove the need for explicit configuration in most cases. If the value of Ageing Time can be set by management, the Bridge shall have the capability to use values in the range specified, with a granularity of 1 s.

NOTE—The granularity is specified in order to establish a common basis for the granularity expressed in the management operations defined in Clause 12, not to constrain the granularity of the actual timer supported by a conformant implementation. If the implementation supports a granularity other than 1 s, then it is possible that the value read back by management following a Set operation will not match the actual value expressed in the Set.

Table 8-6—Ageing time parameter value

<table><tr><td>Parameter</td><td>Recommended default value</td><td>Range</td></tr><tr><td>Ageing time</td><td>300.0 s</td><td>10.0–1 000 000.0 s</td></tr></table>

The STP specified in Clause 8 of IEEE Std 802.1D, 1998 Edition [B9], includes a procedure for notifying all Bridges in the network of topology change. It specifies a short value for the Ageing Timer, to be enforced for a period after any topology change (8.3.5 of IEEE Std 802.1D, 1998 Edition [B9]). While the topology is not changing, this procedure allows normal ageing to accommodate extended periods during which addressed end stations do not generate frames themselves, perhaps through being powered down, without sacrificing the ability of the network to continue to provide service after automatic configuration.

8.8 The Filtering Database (FDB)

The FDB supports queries by the Forwarding Process to determine whether received frames, with given values of, destination MAC address, and for VLAN Bridge components, VID, are to be forwarded through a given potential transmission Port (8.6.1, 8.6.3, 8.6.4). It can also be used, by SPBM (8.6.1), to determine whether received frames with given values of source B-MAC address and B-VID, are to be forwarded from a given reception Port. The FDB contains filtering information in the form of filtering entries that are either

a) Static, and explicitly configured by management action; or

b) Dynamic, and automatically entered into the FDB by the normal operation of the Bridge and the protocols it supports.

Two entry types are used to represent static filtering information. The Static Filtering Entry represents static information in the FDB for individual and for group MAC addresses. It allows administrative control of

c) Forwarding of frames with particular destination addresses; and

d) The inclusion in the FDB of dynamic filtering information associated with Extended Filtering Services, and use of this information.

The FDB shall contain entries of the Static Filtering Entry type.

The Static VLAN Registration Entry represents all static information in the FDB for VLANs. It allows administrative control of

e) Forwarding of frames with particular VIDs;

f) The inclusion/removal of tag headers in forwarded frames; and

g) The inclusion in the FDB of dynamic VLAN membership information, and use of this information.

The FDB associated with VLAN Bridge components may contain entries of the Static VLAN Registration Entry type. The Static VLAN Registration Entry type is not applicable to MAC Bridge components.

Static filtering information is added to, modified, and removed from the FDB only under explicit management control except when PBB-TE IPS is deployed, in which case the static filtering information for traffic associated with IPGs configured on the Bridge is added to, modified, and removed from the FDB only under the direction of IPS Control (26.11.3). It shall not be automatically removed by any ageing mechanism. Management of static filtering information may be carried out by use of the remote management capability provided by Bridge Management (8.12) using the operations specified in Clause 12.

Four entry types are used to represent dynamic filtering information:

h) Each Dynamic Filtering Entry specifies the Port through which a frame with a given individual MAC address, and in the case of VLAN Bridge components, VID, has been or can be received. Dynamic Filtering Entries can be created and updated by the Learning Process (8.7) and by ISIS-SPB. Entries that are updated by the Learning Process are subject to ageing and removal by the FDB.

NOTE 1—ISIS-SPB has to create the Dynamic Filtering Entries for VLANs supported by SPBM, since learning is not used. Initial creation of these entries does no harm for VLANs supported by SPBV (when learning is used) as it can reduce flooding of frames to unknown destinations.

i) MAC Address Registration Entries support the registration of MAC addresses. They are created, updated, and removed by MMRP in support of Extended Filtering Services (8.8.4 and Clause 10) and by ISIS-SPB. If the Restricted_MAC_Address_Registration management control (10.12.2.3) is TRUE, then the creation of a MAC Address Registration Entry by MMRP is not permitted unless a Static Filtering Entry exists that permits dynamic registration for the Group concerned.

j) Dynamic VLAN Registration Entries are used to specify the Ports on which VLAN membership has been dynamically registered. They are not applicable to MAC Bridge components. They are created, updated, and removed by MVRP, MIRP, and ISIS-SPB, in support of automatic VLAN membership configuration (Clause 11 and Clause 39). The MVRP controlled Dynamic VLAN Registration Entries are subject to the state of the Restricted_VLAN_Registration management control (11.2.3.2.3). If the value of this control is TRUE, then the creation of a Dynamic VLAN Registration Entry is not permitted unless a Static VLAN Registration Entry exists that permits dynamic registration for the VID concerned.

k) Dynamic Reservation Entries are used to specify the Ports on which stream reservations have been made. They are created, updated, and removed by the operation of SRP defined in Clause 35.

Static Filtering Entries and MAC Address Registration Entries comprise

1) A MAC address specification;

m) A VID;

n) A Port Map, with a control element for each outbound Port to specify filtering for, that MAC address specification, and in the case of VLAN Bridge components, that VID.

Item m), and any reference to VIDs, are not applicable to MAC Bridge components.

Dynamic Filtering Entries comprise

o) A MAC address specification;

p) A locally significant FID (see 8.8.8);

q) A Port Map, with a control element for each outbound Port to specify filtering for, that MAC address specification, and in the case of VLAN Bridge components, for the VID(s) allocated to that FID.

Item p) and any reference to VIDs and FIDs are not applicable to MAC Bridge components.

The Port Map in Static and Dynamic Filtering Entries may contain a connection_identifier (8.8.12) for each outbound Port.

Static and Dynamic VLAN Registration Entries comprise

r) A VID;

s) A Port Map, with a control element for each outbound Port to specify filtering for the VID.

Static and Dynamic VLAN Registration Entries are not applicable to MAC Bridge components.

Dynamic Reservation Entries comprise

t) A MAC address specification;

u) A VID;

v) A Port Map, with a control element for each outbound Port to specify filtering for that MAC address specification, and in the case of VLAN Bridge components, in the VLAN specified by the VID.

Dynamic filtering information may be read by use of the remote management capability provided by Bridge Management (8.12) using the operations specified in Clause 12.

The Filtering Services supported by a Bridge (Basic and Extended Filtering Services) determine the default behavior of the Bridge with respect to the forwarding of frames destined for group MAC addresses. In Bridges that support Extended Filtering Services, the default forwarding behavior for group MAC addresses, for each Port, and for each VID, can be configured both statically and dynamically by means of Static Filtering Entries and/or MAC Address Registration Entries that can carry the following MAC address specifications:

w) All Group Addresses, for which no more specific Static Filtering Entry exists;

x) All Unregistered Group Addresses (i.e., all group MAC addresses for which no MAC Address Registration Entry exists), for which no more specific Static Filtering Entry exists.

NOTE 2—The All Group Addresses specification in item w), when used in a Static Filtering Entry with an appropriate control specification, provides the ability to configure a Bridge that supports Extended Filtering Services to behave as a Bridge that supports only Basic Filtering Services on some or all of its Ports. This might be done for the following reasons:

— The Ports concerned serve “legacy” devices that wish to receive multicast traffic, but are unable to register Group membership;

— The Ports concerned serve devices that need to receive all multicast traffic, such as routers or diagnostic devices.

The FDB shall support the creation, updating, and removal of Dynamic Filtering Entries by the Learning Process (8.7). In Bridges that support Extended Filtering Services, the FDB shall support the creation, updating, and removal of MAC Address Registration Entries by MMRP (Clause 10). In Bridges that support SPBM, Dynamic Filtering Entries are populated by ISIS-SPB (Clause 28). In Bridges that support SPBV the Dynamic Filtering Entries are created and updated by the Learning Process (8.7) and the use of ISIS-SPB for this operation is optional (28.12.9).

SPB (27.10) allocates SPVIDs dynamically to support shortest path bridging of frames assigned to one or more VLANs, each identified by a Base VID (Clause 3). A Static Filtering Entry should not be created for an SPVID, irrespective of whether that SPVID is currently used, and SPVIDs should not be used in registration protocols that create MAC Address Registration Entries or Dynamic VLAN Registration Entries. In an SPT Bridge, configuration or registration of an FDB entry with the Base VID of a VLAN supported by SPBV shall cause the Bridge to filter frames as if that entry was also present for every one of the SPVIDs for that Base VID.

In Bridges that support SRP, the FDB shall support the creation, updating, and removal of Dynamic Reservation Entries by SRP (Clause 35).

Figure 8-4 illustrates use of the FDB by the Forwarding Process in a single instance of frame relay between the Ports of a Bridge with two Ports.

Figure 8-5 illustrates the creation or update of a dynamic entry in the FDB by the Learning Process. The entries in the FDB, associated with VLAN Bridge components, allow MAC address information to be learned independently for each VID or set of VIDs, by relating a MAC address to the VID or set of VIDs on which that address was learned.

NOTE 3—The ability to create VLAN-dependent FDB entries allows a VLAN Bridge to support multiple end stations with the same individual MAC address residing on different VLANs. It also supports end stations with multiple interfaces, each using the same individual MAC address, as long as not more than one end station or interface that uses a given MAC address resides in a given VLAN.

Figure 8-6 illustrates the operation of the Spanning Tree Protocol Entity (8.10), which operates STP, and its notification of the FDB of changes in active topology signaled by that protocol.

There are no standardized constraints on the size of the FDB in an implementation for which conformance to this standard is claimed. The PICS proforma in Annex A requires the following to be specified for a given implementation:

y) The total number of entries (Static Filtering Entries, Dynamic Filtering Entries, MAC Address Registration Entries, Static VLAN Registration Entries, Dynamic VLAN Registration Entries, and Dynamic Reservation Entries) that the implementation of the FDB can support, and

z) Of that total number, the total number of VLAN Registration Entries (static and dynamic) that the FDB can support.

8.8.1 Static Filtering Entries

A Static Filtering Entry specifies

a) A MAC address specification, comprising

1) An individual MAC address; or

2) A group MAC address; or

3) All Individual Addresses, for which no more specific Filtering Entry exists; or

4) All Group Addresses, for which no more specific Static Filtering Entry exists; or

5) All Unregistered Group Addresses, for which no more specific Static Filtering Entry exists.

b) A VID specification, comprising

1) The VID of a specific VLAN to which the static filtering information applies; or

2) The wildcard VID (Table 9-2), indicating that the static filtering information applies to all VIDs for which no specific Static Filtering Entry exists.

c) A Port Map, containing a control element for each outbound Port, specifying that a frame with a destination MAC address, and in the case of VLAN Bridge components, VID that meets this specification is to be

1) Forwarded, independently of any dynamic filtering information held by the FDB; or

2) Filtered, independently of any dynamic filtering information; or

3) Forwarded or filtered on the basis of dynamic filtering information, or on the basis of the default Group filtering behavior for the outbound Port (8.8.6) if no dynamic filtering information is present specifically for the MAC address.

The Port Map may contain a connection_identifier (8.8.12) for each outbound Port.

MAC Bridges shall have the capability to support the first two values for the MAC address specification, and all three values for each control element for all Static Filtering Entries [i.e., shall have the capability to support item a1), item a2), item c1), item c2), and item c3)]. All VLAN Bridges shall have the capability to support the first two values for the MAC address specification, both values of the VID specification, and all three values for each control element for all Static Filtering Entries [i.e., shall have the capability to support item a1), item a2), item b1), item b2), item c1), item c2), and item c3)]. All Bridges supporting PBB-TE or SPT Bridges shall, in addition, support items a3) and a4) for ESP-VIDs (8.9) or VIDs identifying VLANs supported by SPBM, respectively, and shall always have in their FDBs Static Filtering Entries specifying items a3) and a4), and a Port Map specifying filtering for each outbound port, for every ESP-VID or SPBM VID, respectively.

A Bridge that supports Extended Filtering Services shall have the capability to support items a1), a2), a4), and a5) for the MAC address specification and all three control element values for all Static Filtering Entries.

For a given MAC address specification, a separate Static Filtering Entry with a distinct Port Map may be created for each VID from which frames are received by the Forwarding Process.

In addition to controlling the forwarding of frames, Static Filtering Entries provide the Registrar Administrative Control values for MMRP (Clause 10). Static configuration of forwarding of a specific destination MAC address to an outbound port indicates Registration Fixed on that port, which indicates a desire to receive the specific frames even in the absence of dynamic information. Static configuration of filtering of frames that might otherwise be sent to an outbound port indicates Registration Forbidden. The absence of a Static Filtering Entry for a MAC address, or the configuration of forwarding or filtering on the basis of dynamic filtering information, indicates Normal Registration.

8.8.2 Static VLAN Registration Entries

A Static VLAN Registration Entry specifies

a) The VID to which the static filtering information applies;

b) A Port Map, consisting of a control element for each outbound Port, specifying

1) The Registrar Administrative Control values for MVRP (Clause 11) and MIRP (Clause 39) for the VID. In addition to providing control over the operation of MVRP and MIRP, these values can also directly affect the forwarding behavior of the Bridge, as described in 8.8.10. The values that can be represented are

i) Registration Fixed (New ignored); or

ii) Registration Fixed (New propagated); or

iii) Registration Forbidden; or

i) Normal Registration.

2) Whether frames are to be VLAN-tagged or untagged when transmitted. The entries in the Port Map that specify untagged transmission compose the untagged set for the VID. The untagged set is empty if no Static VLAN Registration Entry exists for the VID.

Static VLAN Registration Entries are not applicable to MAC Bridge components.

A separate Static VLAN Registration Entry with a distinct Port Map may be created for each VID. All Bridges shall be capable of supporting all values for each control element for all Static VLAN Registration Entries; however, the ability to support more than one untagged VID on egress on any given Port is optional (see 5.4).

NOTE 1—In other words, it is possible to configure any VID as untagged on egress, but it is not necessarily possible to configure more than one VID as untagged on egress. It is an implementation option about whether only a single untagged VID per Port on egress is supported or whether multiple untagged VIDs per Port on egress are supported. When a single untagged VID per Port is supported, that VID is not necessarily the same as the PVID.

The initial state of the Permanent Database contains a Static VLAN Registration Entry for the VID corresponding to the Default PVID (Table 9-2). The Port Map in this entry specifies Registration Fixed and forwarding untagged for all Ports of the Bridge. This entry may be modified or removed from the Permanent Database by means of the management operations defined in Clause 12 if the implementation supports these operations.

NOTE 2—This initial state causes the default tagging state for the PVID to be untagged, and for all other VIDs to be tagged, unless otherwise configured; however, the management configuration mechanisms allow any VID (including the PVID) to be specified as VLAN-tagged or untagged on any Port.

NOTE 3—For VLANs supported by SPBV the Filtering specified by a static VLAN registration entry for the Base VID is applied for all SPVIDs associated with that Base VID.

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 (SVL) (3.204) takes place. Any pair of FIDs identifies two sets of VIDs between which Independent VLAN Learning (IVL) (3.94) 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.

Item b), and any reference to FIDs and VIDs in the list above, are not applicable to MAC Bridge components.

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. SPBV updates Dynamic Filtering Entries by the normal Learning Process, but they may 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 FDB for a given combination of MAC address and FID. Dynamic Filtering Entries cannot be created or updated by management.

NOTE 2—Dynamic Filtering Entries may be read by management (Clause 12). In the case of VLAN Bridge components, 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.

8.8.4 MAC Address Registration Entries

A MAC Address Registration Entry specifies

a) A MAC address specification, comprising

1) An individual MAC address; or

2) A group MAC address; or

3) All Group Addresses, for which no more specific Static Filtering Entry exists; or

4) All Unregistered Group Addresses, for which no more specific Static Filtering Entry exists.

b) The VID for which the dynamic filtering information was registered;

c) A Port Map, consisting of a control element for each outbound Port, which specifies forwarding (Registered) or filtering (Not registered) of frames destined to the MAC address and, in the case of VLAN Bridge components, the VID.

Item b) and any reference to VIDs, in the list above, are not applicable to MAC Bridge components.

MAC Address Registration Entries are created, modified, and deleted by the operation of MMRP (Clause 10) or by ISIS-SPB. No more than one MAC Address Registration Entry shall be created in the FDB for a given combination of MAC address specification and VID.

NOTE—It is possible to have a Static Filtering Entry that has values of Forward or Filter on some or all Ports that mask the dynamic values held in a corresponding MAC Address Registration Entry. The values in the MAC Address Registration Entry will continue to be updated by MMRP; hence, subsequent modification of that entry to allow the use of dynamic filtering information on one or more Ports immediately activates the true MMRP registration state that was hitherto masked by the static information.

The creation of MAC Address Registration Entries by MMRP is subject to the Restricted_MAC_Address_Registration management control (10.12.2.3). If the value of this control is TRUE, a dynamic entry for a given MAC address may only be created if a Static Filtering Entry already exists for that MAC address, in which the Registrar Administrative Control value is Normal Registration.

8.8.5 Dynamic VLAN Registration Entries

A Dynamic VLAN Registration Entry specifies

a) The VID to which the dynamic filtering information applies;

b) A Port Map with a control element for each outbound Port specifying whether the VID is registered on that Port.

Dynamic VLAN Registration Entries are not applicable to MAC Bridge components.

A separate Dynamic VLAN Registration Entry with a distinct Port Map may be created for each VID from which frames are received by the Forwarding Process.

The creation of Dynamic VLAN Registration Entries is subject to the Restricted_VLAN_Registration management control (11.2.3.2.3). If the value of this control is TRUE, a dynamic entry for a given VID may only be created if a Static VLAN Registration Entry already exists for that VID, in which the Registrar Administrative Control value is Normal Registration.

8.8.6 Default Group filtering behavior

Forwarding and filtering of group-addressed frames may be managed by specifying defaults for each VID and outbound Port, or just outbound Ports in the case of MAC Bridges. The behavior of each of these defaults, as modified by the control elements of more explicit FDB entries applicable to a given frame's MAC address, VID, and outbound Port, is as follows:

NOTE 1—As stated in 8.8.1 for VLAN Bridge components, for a given MAC address, there may be separate Static Filtering Entries with a distinct Port Map for each VID.

a) Forward All Groups. The frame is forwarded, unless an explicit Static Filtering Entry specifies filtering independent of any dynamic filtering information.

b) Forward Unregistered Groups. The frame is forwarded, unless

1) An explicit Static Filtering Entry specifies filtering independent of any dynamic filtering information; or

2) An explicit Static Filtering Entry specifies forwarding or filtering on the basis of dynamic filtering information, and an applicable explicit MAC Address Registration Entry exists specifying filtering; or

3) An applicable explicit Static Filtering Entry does not exist, but an applicable MAC Address Registration Entry specifies filtering.

c) Filter Unregistered Groups. The frame is filtered unless

1) An explicit Static Filtering Entry specifies forwarding independent of any dynamic filtering information; or

3) An applicable explicit Static Filtering Entry does not exist, but an applicable MAC Address Registration Entry specifies forwarding.

In Bridges that support only Basic Filtering Services, the default Group filtering behavior is Forward All Groups for all Ports of the Bridge, for all VIDs.

NOTE 2—Forward All Groups corresponds directly to the behavior specified in IEEE Std 802.1D, 1993 Edition [B8] when forwarding group MAC addressed frames for which no static filtering information exists in the FDB. Forward All Groups makes use of information contained in Static Filtering Entries for specific group MAC addresses, but overrides any information contained in MAC Address Registration Entries. Forward Unregistered Groups is analogous to the forwarding behavior of a Bridge with respect to individual MAC addresses. If there is no static or dynamic information for a specific group MAC address, then the frame is forwarded; otherwise, the frame is forwarded in accordance with the statically configured or dynamically learned information.

In Bridges that support Extended Filtering Services, the default Group filtering behavior for each outbound Port, and in the case of VLAN Bridge components, for each VID, is determined by the following information contained in the FDB:

d) Any Static Filtering Entries that are applicable to that VID in the case of VLAN Bridge components, with a MAC address specification of All Group Addresses or All Unregistered Group Addresses;

e) Any MAC Address Registration Entries that are applicable to that VID in the case of VLAN Bridge components, with a MAC address specification of All Group Addresses or All Unregistered Group Addresses.

The means whereby this information determines the default Group filtering behavior is specified in 8.8.9, Table 8-8, and Table 8-9.

NOTE 3—The result is that the default Group filtering behavior, applicable in the case of VLAN Bridge components for each VID, can be configured for each Port of the Bridge via Static Filtering Entries, determined dynamically via MAC Address Registration Entries created/updated by MMRP (Clause 10), or both. For example, in the absence of any static or dynamic information in the FDB for All Group Addresses or All Unregistered Group Addresses, the default Group filtering behavior will be Filter Unregistered Groups on all Ports, for all VIDs. Subsequently, the creation of a Dynamic MAC Address Registration Entry for All Unregistered Group Addresses indicating “Registered”, for a given VID in the case of VLAN Bridge components, on a given Port would cause that Port to exhibit Forward Unregistered Groups behavior, for that VID in the case of VLAN Bridge components. Similarly, creating a Static Filtering Entry for All Group Addresses indicating “Registration Fixed” on a given Port, in the case of VLAN Bridge components for that VID, would cause that Port to exhibit Forward All Groups behavior.

Hence, by using appropriate combinations of “Registration Fixed,” “Registration Forbidden,” and “Normal Registration” in the Port Maps of Static Filtering Entries for the All Group Addresses and All Unregistered Group Addresses address specifications, it is possible, for a given Port, and in the case of VLAN Bridge components, VID, to

— Fix the default Group filtering behavior to be just one of the three behaviors described above; or

— Restrict the choice of behaviors to a subset of the three, and allow MMRP registrations (or their absence) to determine the final choice; or

— Allow any one of the three behaviors to be adopted, in accordance with any registrations received via MMRP.

8.8.7 Dynamic Reservation Entries

A Dynamic Reservation Entry specifies the following:

a) A group MAC address or an individual MAC address.

b) The VID for which the dynamic reservation information was registered.

c) A Reservation Port Map, consisting of a control element for each outbound Port that specifies forwarding (reservation information exists for this Port) or filtering (reservation information does not exist for this Port) of frames for this Port. The initial value shall be filtering.

Dynamic Reservation Entries are created, modified, and deleted by the operation of SRP. No more than one Dynamic Reservation Entry shall be created in the FDB for a given combination of MAC address and VID.

8.8.8 Allocation of VIDs to FIDs

The allocation of VIDs to FIDs within a VLAN Bridge determines how learned individual MAC address information is used in forwarding and filtering decisions. If two VIDs are allocated to the same FID learned information is shared, i.e., an individual MAC address learned following receipt of a frame affects the forwarding or filtering of a subsequent frame with the same address as its destination address if either of the two VIDs have been assigned to each of the two frames. If two VIDs are allocated to different FIDs learned information is independent, i.e., an individual MAC address for frames that have one of the VIDs assigned does not affect forwarding or filtering of frames with the other VID. IVL can allow two separate stations to use the same MAC address, provided they use different VLANs, and also allows frames transmitted by a single station to be assigned to independent active topologies. SVL allows support of a single VLAN by multiple VIDs, enabling further control over the filtering of frames for that VLAN, and allowing SPB to support the VLAN with a set of symmetric trees while still using learning. Further considerations for the use of IVL and/or SVL are described in Annex F (informative).

A VLAN Bridge shall support either SVL or IVL, and may support both. If IVL is not supported the Bridge shall support a single FID. If IVL is supported, the number of FIDs shall be the same as the maximum number of VLANs supported by the implementation. For the purposes of the management operations, FIDs are numbered from 1 through N, where N is the maximum number of FIDs supported by the implementation. A Bridge that supports both SVL and IVL shall be capable of allocating any VID to any FID, through configuration of the VID to FID allocation table. Following any set of management operations designed to change the allocation of VIDs to FIDs, whether initiated by an administrative request or as a consequence of other aspects of the Bridge’s operation, the value of any FID that is in use should be the same as that of one of the VIDs allocated to that FID. One exception to this rule is the allocation of SPVIDs to FIDs for SPBV (Clause 27). SPVIDs that are allocated are associated with a Base VID’s FID. The learning behavior of SPVIDs assigned to a FID is determined by the learning behavior of the associated Base VID’s FID (27.11).

The VID to FID allocation table may be read and modified by means of the management operations defined in Clause 12. For each VID supported by the implementation, the allocation table indicates one of the following:

a) The VID is currently not allocated to any FID; or

b) A fixed allocation has been defined (via management), allocating this VID to a specific FID; or

c) A dynamic allocation has been defined, allocating this VID to a specific FID.

An SPT Bridge can dynamically allocate VIDs, that have been reserved for use as SPVIDs, to FIDs.

An MST Bridge shall support IVL and may support SVL. An MST Bridge shall be capable of allocating any FID to any MSTID through configuration of the FID to MSTID Allocation Table (12.12.2). An SPT Bridge supports both IVL and SVL.

8.8.9 Querying the FDB

If the VID assigned to a relayed frame identifies a VID or an ESP with a given outbound Bridge Port in its member set (8.8.10), the FDB entries that are applicable to the frame’s destination MAC address and VID determine whether the frame is filtered or forwarded through that Bridge Port. More than one entry can apply to a given frame. This subclause (8.8.9) specifies the effect of combining applicable entries, and of the absence of certain types of entries (not all possible entries are necessarily present). For an overview of the different types of entries, see the introductory text of 8.8.

The FDB entries associated with a VLAN Bridge component, applicable to a frame whose destination MAC address is a specific individual MAC address are the Dynamic Filtering Entry (if present) with that MAC address and the FID to which the frame’s VID is allocated (8.8.8), and all Static Filtering Entries (if any) with that MAC address, or with “All Individual MAC Address,” as their MAC address specification and a VID that is also allocated to that FID, as their VID specification. An entry with a wildcard VID applies only if there is no applicable Static Filtering Entry for a specific VID. Table 8-7 specifies the result of combining this information for an individual MAC address and a given outbound Bridge Port, and can be summarized as follows:

— IF any static entry for a VID allocated to the FID specifies Forward THEN Forward

— ELSE IF any static entry for a VID allocated to the FID specifies Filter THEN Filter

ELSE IF a static entry for the wildcard VID specifies Forward THEN Forward

ELSE IF a static entry for the wildcard VID specifies Filter THEN Filter

— ELSE IF dynamic (learnt filtering information) entry for the FID specifies Filter THEN Filter

ELSE Forward

Table 8-7—Combining Static and Dynamic Filtering Entries for an individual MAC address

<table><tr><td rowspan="3">Filtering Information</td><td colspan="5">Control Elements in any Static Filtering Entry or Entries for this individual MAC address, FID, and outbound Port specify:</td></tr><tr><td rowspan="2">Forward (Any Static Filtering Entry for this Address/FID/Port specifies Forward)</td><td rowspan="2">Filter (No Static Filtering Entry for this Address/FID/Port specifies Forward)</td><td colspan="3">Use Dynamic Filtering Information (No Static Filtering Entry for this Address/FID/Port specifies Forward or Filter), or no Static Filtering Entry present. Dynamic Filtering Entry Control Element for this individual MAC address, FID, and outbound Port specifies:</td></tr><tr><td>Forward</td><td>Filter</td><td>No Dynamic Filtering Entry present</td></tr><tr><td>Result</td><td>Forward</td><td>Filter</td><td>Forward</td><td>Filter</td><td>Forward</td></tr></table>

Table 8-7 is also applicable to MAC Bridge components but in this case there is no specific qualification on FIDs in the FDB entries and the result of combining this information for an individual MAC address and a given outbound Bridge Port can be summarized as follows:

— IF any static entry specifies Forward THEN Forward

— ELSE IF any static entry specifies Filter THEN Filter

— ELSE IF dynamic (learnt filtering information) entry specifies Filter THEN Filter

ELSE Forward

The FDB entries applicable (if present) to a frame whose destination MAC address is a specific group MAC address are the Static Filtering Entries and MAC Address Registration Entries (for the frame’s VID and for the wildcard VID) whose address specification is that group MAC address or “All Group Addresses” or “All Unregistered Group Addresses.” A Static Filtering Entry for a wildcard VID applies only if there is no applicable Static Filtering Entry for a specific VID, MAC Address Registration Entries do not use wildcard VIDs. Table 8-8 specifies the results, Registered or Not Registered for a given outbound Bridge Port, of combining the entries for the “All Group Addresses” and for combining the entries for “All Unregistered Group Addresses.” Table 8-9 combines these results with the entries for the specific group MAC address. The result of Table 8-8 for “All Group Addresses” can be summarized as follows:

IF a static entry for “All Group Addresses” and the frame’s VID specifies Forward (Registration Fixed) THEN “All Group Addresses” is Registered

ELSE IF a static entry for “All Group Addresses” and the frame’s VID specifies Filter (Registration Forbidden) THEN “All Group Addresses” is Not Registered

ELSE IF a dynamic (MAC Address Registration) entry for “All Group Addresses” and the frame’s VID specifies Forward (Registered) THEN “All Group Addresses” is Registered

— ELSE “All Group Addresses” is NOT Registered

NOTE 1—The result for “All Unregistered Group Addresses” is given by substituting that address specification for “All Group Address” throughout the summary.

Table 8-8—Combining Static Filtering Entry and MAC Address Registration Entry for “All Group Addresses” and “All Unregistered Group Addresses”

<table><tr><td rowspan="3">Filtering Information</td><td colspan="5">Static Filtering Entry Control Elementfor this group MAC address, VID, and outbound Port specifies:</td></tr><tr><td rowspan="2">Registration Fixed (Forward)</td><td rowspan="2">Registration Forbidden (Filter)</td><td colspan="3">Use MAC Address Registration Information, or no Static Filtering Entry present.MAC Address Registration Entry Control Element for this group MAC address, VID, and outbound Port specifies:</td></tr><tr><td>Registered (Forward)</td><td>Not Registered (Filter)</td><td>No MAC Address Registration Entry present</td></tr><tr><td>Result</td><td>Registered</td><td>Not Registered</td><td>Registered</td><td>Not Registered</td><td>Not Registered</td></tr></table>

The result of Table 8-9 can be summarized as follows:

IF a static entry for the specific group address and the frame’s VID specifies Forward THEN Forward

ELSE IF a static entry for the specific group address and the frame’s VID specifies Filter THEN Filter

ELSE IF a static entry for the specific group address and the wildcard VID specifies Forward THEN Forward

ELSE IF a static entry for the specific group address and the wildcard VID specifies Filter THEN Filter

— ELSE IF the Table 8-8 result for “All Group Addresses” is Registered THEN Forward

ELSE IF the Table 8-8 result for “All Unregistered Group Addresses” is Registered THEN Forward

ELSE IF a dynamic (MAC Address Registration) entry for the specific group address and the frame’s VID specifies Forward THEN Forward

ELSE Filter

Table 8-9—Forwarding or Filtering for specific group MAC addresses

<table><tr><td rowspan="3" colspan="4"></td><td colspan="5">Static Filtering Entry Control Element for this group MAC address, VID, and outbound Port specifies:</td></tr><tr><td rowspan="2">Registration Fixed (Forward)</td><td rowspan="2">Registration Forbidden (Filter)</td><td colspan="3">Use MAC Address Registration Information, or no Static Filtering Entry present. MAC Address Registration Entry Control Element for this group MAC address, VID, and outbound Port specifies:</td></tr><tr><td>Registered (Forward)</td><td>Not Registered (Filter)</td><td>No MAC Address Registration Entry present</td></tr><tr><td rowspan="3">All Group Addresses control elements for this VID and Port specify (Table 8-8):</td><td rowspan="2">Not Registered</td><td rowspan="2">All Unregistered Group Addresses control elements for this VID and Port specify (Table 8-8):</td><td>Not Registered</td><td>Forward</td><td>Filter</td><td>Forward</td><td>Filter (Filter Unregistered Groups)</td><td>Filter (Filter Unregistered Groups)</td></tr><tr><td>Registered</td><td>Forward</td><td>Filter</td><td>Forward</td><td>Forward (Forward Unregistered Groups)</td><td>Forward (Forward Unregistered Groups)</td></tr><tr><td colspan="3">Registered</td><td>Forward</td><td>Filter</td><td>Forward (Forward All Groups)</td><td>Forward (Forward All Groups)</td><td>Forward (Forward All Groups)</td></tr></table>

Table 8-8 and Table 8-9 are also applicable to MAC Bridge components but in this case there is no specific qualification on VIDs in the FDB entries and the result of combining this information for an individual MAC address and a given outbound Bridge Port can be summarized as follows:

— IF a static entry for the specific group address specifies Forward THEN Forward

ELSE IF a static entry for the specific group address specifies Filter THEN Filter

ELSE IF a static entry for the specific group address specifies Forward THEN Forward

ELSE IF a static entry for the specific group address specifies Filter THEN Filter

ELSE IF the Table 8-8 result for “All Group Addresses” is Registered THEN Forward

— ELSE IF the Table 8-8 result for “All Unregistered Group Addresses” is Registered THEN Forward

ELSE IF a dynamic (MAC Address Registration) entry for the specific group address specifies Forward THEN Forward

ELSE Filter

When forwarding or filtering a frame with a destination group MAC address, a VLAN Bridge may

a) Ignore the allocation of VIDs to FID, and use Table 8-9 directly for the frame’s VID; or

b) Take the same decision for all VIDs allocated to any given FID, forwarding if Table 8-9 specifies Forward for any VID allocated to the same FID as the frame’s VID, and filtering otherwise.

For a given destination MAC address and VID, a Dynamic Reservation Entry (8.8.7) may be present in the FDB, indicating, by means of its port map, which Ports have valid bandwidth reservations. If a Dynamic Reservation Entry exists in the FDB for that MAC address and VID, the port map in the Dynamic Reservation Entry is used to prevent frames being forwarded on Ports where no reservation exists. Table 8- 10 combines the output of Table 8-7 (for an individual MAC address) or Table 8-9 (for a group MAC address) with a Dynamic Reservation Entry to specify forwarding, or filtering, of a frame with that destination MAC address and VID through an outbound Port.

Table 8-10—Forwarding or Filtering with Dynamic Reservation Entries

<table><tr><td rowspan="2" colspan="2"></td><td colspan="2">Dynamic Reservation Entry Control Element for this individual or group MAC address, VID, and outbound Port specifies:</td></tr><tr><td>Forward</td><td>Filter</td></tr><tr><td rowspan="2">Output of Table 8-7 (individual MAC address) or Table 8-9 (group MAC address) for this group or individual MAC address, VID, and outbound Port specifies:</td><td>Forward</td><td>Forward</td><td>Filter</td></tr><tr><td>Filter</td><td>Filter</td><td>Filter</td></tr></table>

NOTE 2—Where a group MAC address is used as the destination address for reserved traffic, the reservation mechanisms used by SRP will prevent reservations being made for multiple streams using the same combination of MAC address and VID. The Dynamic Reservation Entry can then control which Port(s) the stream associated with the MAC address and VID is permitted to be transmitted through. The restriction preventing multiple streams from using the same group MAC address/VID is necessary because those different streams may be destined for different destination Ports; if the restriction was not imposed, it would not be possible to distinguish which frames belong to which streams and therefore through which Ports they should be transmitted.

8.8.10 Determination of the member set for a VID

The VLAN configuration information contained in the FDB of a VLAN Bridge component for a given VID may include a Static VLAN Registration Entry (8.8.2) and/or a Dynamic VLAN Registration Entry (8.8.5). This information defines the member set, the Ports through which members of the VLAN identified by that VID can be reached.

For a given VID, the FDB can contain a Static VLAN Registration Entry, a Dynamic VLAN Registration Entry, both, or neither. Table 8-11 combines Static VLAN Registration Entry and Dynamic VLAN Registration Entry information for a VID and Port to give a result member, or not member, for the Port. The member set for a given VID consists of all Ports for which the result is member.

The Forwarding Process uses the member set to apply ingress (8.6.2) and egress rules (8.6.4) for the VID.

Table 8-11—Determination of whether a Port is in a VID’s member set

<table><tr><td rowspan="3">Filtering Information</td><td colspan="5">Static VLAN Registration Entry Control Element for this VID and Port specifies:</td></tr><tr><td rowspan="2">Registration Fixed</td><td rowspan="2">Registration Forbidden</td><td colspan="3">Normal Registration, or no Static VLAN Registration Entry present. Dynamic VLAN Registration Entry Control Element for this VID and Port specifies:</td></tr><tr><td>Registered</td><td>Not Registered</td><td>No Dynamic VLAN Registration Entry present</td></tr><tr><td>Result</td><td>Member</td><td>Not member</td><td>Member</td><td>Not member</td><td>Not member</td></tr></table>

8.8.11 Permanent Database

The Permanent Database provides fixed storage for a number of Static Filtering Entries and Static VLAN Registration Entries. The FDB shall be initialized with the FDB entries contained in this fixed data store.

Entries may be added to and removed from the Permanent Database under explicit management control, using the management functionality defined in Clause 12. Changes to the contents of Static Filtering Entries or Static VLAN Registration Entries in the Permanent Database do not affect forwarding and filtering decisions taken by the Forwarding Process or the egress rules until such a time as the FDB is reinitialized.

NOTE 1—This aspect of the Permanent Database can be viewed as providing a “boot image” for the FDB, defining the contents of all initial entries, before any dynamic filtering information is added.

NOTE 2—Subclause 10.12.2.3 defines an initial state for the contents of the Permanent Database, required for the purposes of MMRP operation.

8.8.12 Connection_Identifier

A connection_identifier may be associated with the Bridge Port value maintained in a Dynamic Filtering Entry of the FDB for Bridge Ports that generate EM_UNITDATA.indications with a non-null connection_identifier parameter (e.g., a VIP as specified in 6.10). The connection_identifier has no effect on the Bridge operation specified in this clause other than being stored in the FDB and conveyed across the EISS as a parameter in an EM_UNITDATA.request or EM_UNITDATA.indication (6.8.1).

When the result of an FDB query (8.8.9) for a particular frame is that the frame will be forwarded, and the FDB entry determining that result has a connection_identifier, then that connection_identifier is included in the EM_UNITDATA.request. For a given VID and MAC address, a connection_identifier can be included in a Dynamic Filtering Entry of the FDB. The FDB entry that determines a filtering or forwarding result is specified in Table 8-7. If there are no entries for that MAC address and VID in the FDB, then a null value for the connection_identifier is used in the EM_UNITDATA.request.

When an EM_UNITDATA.indication with a non-null connection_identifier is received from an ingress port, and the Learning Process identifies or creates a Dynamic Filtering Entry for that frame’s source address and VID, the connection_identifier is included in the entry created for that port in the FDB.

8.9 MST, SPB, and ESP configuration information

In order to support multiple spanning trees, and SPB, all the Bridges in an MST or SPT Region have to be configured with assignments of VIDs to spanning trees.

The combination of the VID to FID allocations (8.8.8) and the FID to MSTI allocations (8.9.3) defines a mapping of VIDs to spanning trees, MSTIDs, represented by the MST Configuration Table (8.9.1). If an MSTID is included in the MSTI List (12.12.1), frames with VIDs allocated to that MSTID will be supported by an MSTI calculated by MSTP (Clause 13). If the MSTID is not included in the MSTI List, and is not a reserved MSTID, those frames will be supported by the IST.

A Bridge supporting PBB-TE can assign specific VID values to ESPs but can also support any of the spanning tree protocols. This is achieved by allocating the VIDs associated with the PBB-TE ESPs to a special MSTID, the TE-MSTID.

An SPT Bridge can allocate any given VLAN to the CIST, or to the reserved MSTIs, as well as supporting SPB for other VLANs within an SPT Region. The assignment of VLANs and VIDs to MSTIs is subject to similar considerations and constraints as for MST Bridges. In addition to the Base VID used to identify frames for the VLAN when transmitted on the CST outside the region, each VLAN supported by SPBV uses a number of dynamically allocated shortest path VIDs (SPVIDs), one for each SPT Bridge participating in the VLAN within the region.

The network administrator allocates enough SPVIDs for SPBV to avoid unintentionally excluding Bridges from the topology. The details of SPVID allocation, including mitigation of the consequences of not allocating enough SPVIDs, are specified in 27.10.

Administratively, by not translating from Base VID to SPVID, an SPBV VLAN can be forced to the IST. When there is no shortage of SPVIDs and the MST Configuration Identifiers (MCIDs) match but the Base VID algorithms disagree the algorithm defaults to the spanning tree. This behavior allows SPBV to change the Equal Cost Tree (ECT) Algorithms.

Dynamic SPVID allocation is supported by ISIS-SPB and allows the addition of Bridges to existing SPT Regions without disruptive configuration changes, as well as allowing supporting auto configuration of SPB in simple networks where all user data is assigned to a VLAN identified by the default PVID of 1 (Table 9- 2). However, prior to SPVID allocation, all Bridges in an SPT Region have to agree which VLANs are to be shortest path bridged, and which SPT Set (ECT Algorithm) is to be used for each of those VLANs. By default, all VLANs whose Base VID is allocated to MSTID 0xFFD will be supported by SPBV using the SPB default ECT Algorithm. The SPT configuration information can also specify that frames for SPBV and SPBM be supported by another specified SPB ECT Algorithm as specified by configuration (12.25.4, Table 28-1).

NOTE—The use of MSTIDs to support allocation of Base VIDs to SPB allows the per VLAN components of the necessary information to be conveyed in the MST Configuration Digest, thus avoiding any need for a separate digest. However, the digest is not specific about how the VIDs are mapped to specific SPTs, just that they are allocated to SPBV, SPBM, or SPVIDs.

8.9.1 MST Configuration Table

The MST Configuration Table specifies an MSTID for each possible VID.

In an MST Bridge, each MSTID identifies the MSTI to which the VID is allocated and an MSTID of zero identifies the CIST.

The combination of the VID to FID allocations (8.8.8) and the FID to MSTID allocations (8.9.3) define a mapping of VIDs to MSTIDs summarized in the MST Configuration Table (8.9.1).

8.9.2 MST configuration identification

For two or more MST Bridges to be members of the same MST Region (3.142), it is necessary for those Bridges to support the same MST Region configuration and to be interconnected only by means of LANs, with all intervening Bridges being members of the region or being transparent to the BPDUs of the members of the region. Two MST Region configurations are considered to be the same if the correspondence between VIDs and MSTIDs is identical in both configurations and they use the same information to identify the configuration, including the same Configuration Name.

NOTE 1—If two adjacent MST Bridges consider themselves to be in the same MST Region despite having different mappings of VIDs to MSTIDs, then the possibility exists of undetectable loops arising within the MST Region.

In order to ensure that adjacent MST Bridges are able to determine whether they are part of the same MST Region, the MST BPDU supports the communication of an MCID (13.8).

NOTE 2—As the MCID is smaller than the mapping information that it summarizes, there is a small but finite possibility that two MST Bridges will assume that they have the same MST Region Configuration when this is not actually the case. However, given the size of the identifier, this standard assumes that this possibility is sufficiently small that it can safely be ignored. Appropriate use of the Configuration Name and Revision Level portions of the identifier can remove the possibility of an accidental match between MCIDs that are derived from different configurations within a single administrative domain (see 13.8).

8.9.3 FID to MSTI Allocation Table

The FID to MSTI Allocation Table defines, for all FIDs that the Bridge supports, the MSTID to which the FID is allocated.

a) The IST is identified by the reserved MSTID value 0.

b) The use of PBB-TE is identified by the reserved MSTID value TE-MSTID (0xFFE).

c) Each MSTID in the MSTI List identifies an MSTI.

The reserved MSTID values 0 and TE-MSTID, SPBV-MSTID, SPBM-MSTID and 0xFFF are never used in the MSTI List.

d) The following MSTID values identify the method used to support the VLANs identified by the Base VIDs allocated to those MSTIDs:

1) 0xFFC—SPBM-MSTID

2) 0xFFD—SPBV-MSTID

3) 0xFFF—Allocated to FIDs that are not used to filter frames including SPVIDs for SPBV

NOTE—MSTIDs that are present in the MSTI List (12.12) identify spanning tree instances supported by MSTP. MSTIDs identify (indirectly) VLANs that are supported by SPB.

8.9.4 SPT Configuration Identification

For two or more SPT Bridges to be members of the same SPT Region (Clause 3), it is necessary for those Bridges to support the same SPT Region configuration and to be interconnected only by means of LANs, with all intervening Bridges being members of the region or being transparent to the BPDUs and/or SPB Hello PDUs of the members of the region. This requirement is identical to that for MST Regions: a given SPT Region can support selected MSTIs as well as SPTs. MCIDs only specify the VIDs that are configured.

Two SPT Region configurations are considered to be the same if they have the same MST Region configuration or alternate MST Region configuration, they agree on the VLANs that are to be shortest path bridged and they use the same ISIS-SPB. Furthermore by using ISIS-SPB they agree on which SPT Set is to be used for each of these VLANs (Clause 27).

The MST Region information captures the VIDs for SPB but it does not capture the operational state of the VIDs for SPB. This allows allocation of SPVIDs and upgrade of multiple ECT Algorithms without change to the MST Region when sufficient pre-allocation of VIDs has been configured. However, in situations where the network grows beyond the current allocation of VIDs, the options are to temporarily create a region boundary as the new configuration is deployed or allow in-service upgrades by making changes that are compatible with the current MST region configuration.

To support in-service upgrade from one set of VID to MSTID allocations to another, SPT Bridges support a second (auxiliary) MCID (28.9). Two such Bridges consider themselves to be in the same MST Region provided that at least one of their MCIDs matches with one of their neighbors. In this way, a new configuration can be incrementally introduced without time constraints, and put into operation, all the while maintaining operation as a single SPT Region.

8.10 Spanning Tree Protocol Entity

Figure 8-6 illustrates the operation of the Spanning Tree Protocol Entity, including the reception and transmission of frames containing BPDUs, the modification of the state information associated with individual Bridge Ports, and the notification of the FDB of changes in active topology.

A given MST Bridge is not required to support all of the spanning trees that exist within the MST bridged network. That is, the number of spanning trees operated by the Spanning Tree Protocol Entity in a given Bridge may be different from the number operated by that in another Bridge. However, as a direct consequence of the conditions stated in 8.9.2, the number of instances of the spanning tree protocol operated by a given MST Bridge is the same for all Bridges that are members of a given MST Region.

The ISIS-SPB Entity comprises an instance of IS-IS with SPB extensions as specified in Clause 28. The ISIS-SPB Entity is described, for the purposes of management, as distinct from the Spanning Tree Protocol Entity. Nonetheless, the ISIS-SPB and Spanning Tree Protocol Entities that calculate active topologies for the same Bridge Port use the same ISS SAP (ISS-SAP, 8.5, 27.2), and the same individual MAC address. However, ISIS-SPB uses one of the group MAC addresses in Table 8-12 and does not use the group MAC addresses used by the spanning tree protocol specified in Table 8-1. The ISIS-SPB Entity uses the state machines and state machine variables supported by the Spanning Tree Protocol Entity (Clause 27, 13.6) and calculates the Agreement Digest that the Spanning Tree Protocol Entity transmits in SPT BPDUs and/or SPB Hello PDUs.

8.11 MRP entities

The MRP entities operate the algorithms and protocols associated with the MRP Applications supported by the Bridge and consist of the set of MRP Participants for those MRP Applications (Clause 10).

Figure 8-7 illustrates the operation of an MRP entity, including the reception and transmission of frames containing MRPDUs, the use of control information contained in the FDB, and the notification of the FDB of changes in filtering information.

8.12 Bridge Management Entity

In order to facilitate interoperable management of Bridges by remote means (as opposed to management via some kind of management console attached directly to the Bridge), it is recommended that SNMP should be the protocol that is used, in conjunction with the SMIv2 MIB modules specified in Clause 17.

8.13 Addressing

All MAC Entities communicating across a bridged network use 48-bit Extended Unique Identifier (EUI-48) addresses. These can be universally administered addresses or a combination of universally administered and locally administered addresses.

8.13.1 End stations

Frames transmitted between end stations using the MAC Service carry the MAC address of the source and destination peer end stations in the source and destination address fields of the frames, respectively. The address, or other means of identification, of a Bridge is not carried in frames transmitted between peer users for the purpose of frame relay in the network.

In the absence of explicit filters configured via management as Static Filtering Entries, or via MMRP as MAC Address Registration Entries (8.8, Clause 10), frames with a destination address of the broadcast address or any other group address that is not a Reserved Address (8.6.3) are assigned by a VLAN Bridge component a VID and relayed throughout the VLAN identified by that VID.

8.13.2 Bridge Ports

A separate individual MAC address is associated with each instance of the MAC Service provided to an LLC Entity. That MAC address is used as the source address of frames transmitted by the LLC Entity.

Media access method-specific procedures can require the transmission and reception of frames that use an individual MAC address associated with the Bridge Port, but neither originate from nor are delivered to a MAC Service user. Where an individual MAC address is associated with the provision of an instance of the MAC Service by the Port, that address can be used as the source and/or the destination address of such frames, unless the specification of the media access method-specific procedures requires otherwise.

8.13.3 Use of LLC by Spanning Tree Protocol Entities

Spanning Tree Protocol Entities use the DL_UNITDATA.request and DL_UNITDATA.indication primitives (ISO/IEC 8802-2) provided by individual LLC Entities associated with each Bridge Port to transmit and receive BPDUs (Clause 14). The source_address and destination_address parameters of the DL_UNITDATA.request shall both denote the standard LLC address assigned to the Bridge spanning tree protocol (Table 8-12). Each DL_UNITDATA request primitive gives rise to the transmission of an LLC UI command PDU, which conveys the BPDU in its information field.17

Table 8-12—Standard LLC address assignment

<table><tr><td>Assignment</td><td>Value</td></tr><tr><td>Bridge spanning tree protocol</td><td>01000010</td></tr><tr><td>IS-IS PDUs</td><td>11111110</td></tr></table>

Code Representation: The least significant bit (LSB) of the value shown is the right-most. The bits increase in significance from right to left. It should be noted that the code representation used here has been chosen in order to maintain consistency with the representation used elsewhere in this standard.

A Protocol Identifier field, present in all BPDUs (Clause 14), serves to identify different protocols supported within the scope of the LLC address assignment. Further values of this field are reserved for future standardization. A Spanning Tree Protocol Entity that receives a BPDU with an unknown PID shall discard that PDU.

IS-IS PDUs are LLC (encoded with a DSAP and SSAP of 0xFE (section 7.5 of ISO/IEC 10589:2002), then a single byte indicating Control 0x03 (5.2.3 and 5.3.1 of IEEE Std 802.2, 1998 Edition [B11]) immediately followed by a IS-IS PDU starting with an Interdomain Routeing Protocol Discriminator equal to 0x83 (section 5.3 of ISO/IEC 9577:1999).

8.13.4 Reserved MAC addresses

Any frame with a destination address that is a reserved MAC address shall not be forwarded by a Bridge. Reserved MAC addresses for MAC Bridge components and C-VLAN components, for S-VLAN components, and for TPMR components are specified in Table 8-1, Table 8-2, and Table 8-3, respectively. These group MAC addresses are reserved for assignment to standard protocols, according to the criteria for such assignments.18

8.13.5 Group MAC addresses for spanning tree entity

A Spanning Tree Protocol Entity uses an instance of the MAC Service provided by each of the Bridge’s Ports to transmit frames addressed to the Spanning Tree Protocol Entities of all the other Bridges attached to the same LAN as that Port.

8.13.5.1 Group MAC addresses for spanning tree protocols

Spanning tree protocols use a reserved address for peer to peer communication between entities of the same type.

An EUI-48 universally administered group address, known as the Bridge Group Address, has been assigned (Table 8-1) for use by C-VLAN components for this purpose.

It is essential to the operation of the spanning tree protocols that frames with this destination address both reach all peer protocol entities attached to the same LAN and do not reach protocol entities attached to other LANs. The Bridge Group Address is therefore included in the block of MAC Bridge and C-VLAN components reserved MAC addresses and is always filtered by Customer Bridges and C-VLAN components of Provider Edge Bridges (8.6.3).

As a network of Provider Bridges needs to appear to attached Customer Bridges as if it was a single LAN, frames addressed to the Bridge Group Address are forwarded by S-VLAN components. Provider Bridges also use a spanning tree protocol to provide one or more loop-free active topologies, so a distinct EUI-48 universally administered group address, the Provider Bridge Group Address, which can be confined to the LANs that their Bridge Ports attach, has been assigned (Table 8-2). The Provider Bridge Group Address is included in both the C-VLAN component and the S-VLAN component reserved MAC addresses and is always filtered by all Bridges (8.6.3).

The source MAC address field of frames transmitted by Spanning Tree Protocol Entities contains the individual MAC address for the Bridge Port used to transmit the frame.

8.13.5.2 Group MAC addresses for SPB

ISIS-SPB use a group address for ISIS-SPB peer to peer communication. ISIS-SPB is configured to use only one of the addresses listed in Table 8-13. All other addresses in this table will be ignored by IS-IS and will not be filtered by the MAC Relay. The choice of which address is used depends on the environment.

Table 8-13—ISIS-SPB reserved addresses

<table><tr><td>Assignment</td><td>Value</td></tr><tr><td>All Level 1 Intermediate Systems</td><td><eq>01-80-C2-00-00-14^a</eq></td></tr><tr><td>All Level 2 Intermediate Systems</td><td><eq>01-80-C2-00-00-15^a</eq></td></tr><tr><td>All Intermediate Systems</td><td><eq>09-00-2B-00-00-05^a</eq></td></tr><tr><td>All Provider Bridge Intermediate Systems</td><td><eq>01-80-C2-00-00-2E</eq></td></tr><tr><td>All Customer Bridge Intermediate Systems</td><td><eq>01-80-C2-00-00-2F</eq></td></tr></table>

a The first three addresses are existing IS-IS addresses (Table 9 of ISO/IEC 10589:2002).

Table 8-13 lists the various addresses that may be configured for ISIS-SPB. Table 8-14 lists the deployment environments for SPB. The usage of ISIS-SPB is described in Clause 28. These addresses are from a reserved address space. These addresses have the property that

a) Where a given address in the set is used by a Bridge component to support ISIS-SPB, frames destined for that address shall not be forwarded by that Bridge component; i.e., a Static Filtering Entry for that address is maintained for that group MAC address in order to prevent the forwarding of frames destined for that address.

b) Where a given address in the set is not used by a Bridge component to support ISIS-SPB, frames destined for that address received on any Port that is part of a given active topology shall be forwarded by that Bridge component on all other Ports that are part of that active topology.

An SPT Bridge, whether it is running SPBV, or SPBM, or both, uses a single group MAC address. Table 8-14 provides the reference for the possible environments.

In Provider Bridge only environments, for SPBV the address should be the allocated All Provider Bridge Intermediate Systems address.

In Customer Bridge only environments where only SPBV is supported the address should be the All Customer Bridge Intermediate Systems address.

In SPBM or SPBV deployments where only Provider backbone components are configured the use of addresses is flexible as indicated in Table 8-14. To allow peering with other systems capable of using IS-IS for IP, the existing IS-IS addresses may be used.

Table 8-14—ISIS-SPB Recommended Address Usage

<table><tr><td>Network Deployment</td><td>Level 1</td><td>Level 2</td><td>All Levels</td></tr><tr><td>SPT Bridges Peering with other IS-IS capable systems</td><td>01-80-C2-00-00-14</td><td>01-80-C2-00-00-15</td><td>09-00-2B-00-00-05</td></tr><tr><td>SPT Bridges PBBs only</td><td>01-80-C2-00-00-14</td><td>01-80-C2-00-00-15</td><td>09-00-2B-00-00-05 or 01-80-C2-00-00-2E</td></tr><tr><td>SPT Bridges in SPBV mode for S-VLANs Provider Bridge</td><td colspan="3">01-80-C2-00-00-2E</td></tr><tr><td>SPT Bridges in SPBV mode for C-VLANs Customer Bridge</td><td colspan="3">01-80-C2-00-00-2F</td></tr></table>

8.13.6 Group MAC addresses for MRP Applications

An MRP Entity that supports a given MRP Application transmits frames addressed to all other MRP Entities that implement the same MRP Application. The peers of each such entity bound a region of the network that contains no peers, commonly a single LAN in the case where all Bridges attached to the LAN implement the application.

Universally administered EUI-48 group addresses are assigned to MRP applications, from a set of EUI-48 Universal Addresses, known as MRP application addresses, as shown in Table 10-1; these addresses are for use by VLAN components that support the MRP applications concerned. FDB entries for each MRP application address assigned to an application that is supported by a VLAN component should be configured in the FDB so frames for that application are confined to the peer region, while addresses for applications that are not supported should not be included. These group MAC addresses are reserved for assignment to standard protocols, according to the criteria for such assignments (see 8.13.4).

When an MRP Application operates among both Customer and Provider Bridges, a distinct EUI-48 universally administered group address is assigned for use by both C-VLAN components and S-VLAN components. MMRP is such an application, and uses the Customer and Provider Bridge MMRP Address assigned in Table 10-1. When an MRP application operates separately among Customer Bridges or among Provider Bridges, different distinct EUI-48 universally administered group addresses are assigned for use by C-VLAN components and for use by S-VLAN components. MVRP is such an application; C-VLAN components use the Customer Bridge MVRP address assigned in Table 10-1, while S-VLAN components use the Provider Bridge MVRP address assigned in Table 8-1. Note that because the Provider Bridge MVRP address is selected from the set of addresses that appear in Table 8-1 but not Table 8-2, it will always be filtered by C-VLAN components. Although the Provider Bridge MVRP Address is not selected from Table 10-1, an S-VLAN component should treat this as an MRP Application Address and configure an FDB entry to filter frames with this address.

An MRP Entity that supports a given MRP Application uses the individual MAC address for the Bridge Port through which the PDU is transmitted (8.13.2) as the source_address field of MAC frames conveying MRPDUs for that application.

8.13.7 Bridge Management Entities

The recommended protocol for remote Bridge management is SNMP, which typically uses IP as a network layer protocol; however, SNMP can also be supported directly over an IEEE 802 LAN, as specified in IETF RFC 4789. If implemented, the management protocol stack and address used shall be supported by a single LLC Entity attached to a Bridge Port. The Port should be a Management Port for the Bridge, as described in 8.3 and Figure 8-8, but may be a Port attached to a LAN, as described in 8.13.9, Figure 8-14, and Figure 8-15.

NOTE—An EUI-48 universally administered group address, known as the All LANs Bridge Management Group Address with a value of 01-80-C2-00-00-10 was assigned and recorded in the 1990 Edition of this standard. That address should not be used for Bridge management or for any other purpose.

8.13.8 Unique identification of a Bridge

A unique EUI-48 Universally Administered MAC address, termed the Bridge Address, shall be assigned to each Bridge. The Bridge Address may be the individual MAC address of a Bridge Port; in which case, use of the address of the lowest numbered Bridge Port (Port 1) is recommended.

NOTE—RSTP (Clause 13) and MSTP (Clause 13) require that a single unique identifier be associated with each Bridge. That identifier is derived from the Bridge Address as specified in 14.2.5.

8.13.9 Points of attachment and connectivity for Higher Layer Entities

The Higher Layer Entities in a Bridge, such as the Spanning Tree Protocol Entity (8.10), MRP entities (8.11), the ISIS-SPB Entity (Clause 28), and Bridge Management (8.12), are modeled as attaching directly to one or more individual LANs connected by the Bridge’s Ports, in the same way that any distinct end station is attached to the network. While these entities and the relay function of the Bridge use the same individual MAC entities to transmit and receive frames, the addressing and connectivity to and from these entities is the same as if they were attached as separate end stations “outside” the Port or Ports where they are actually attached. Figure 8-12 is functionally equivalent to Figure 8-2 but illustrates this logical separation between the points of attachment used by the Higher Layer Entities and those used by the MAC Relay Entity.

!image

Figure 8-12—Logical points of attachment of the Higher Layer and Relay Entities

Figure 8-13 depicts the information used to control the forwarding of frames from one Bridge Port to another (the Port States and the content of the FDB) as a series of switches (shown in the open, disconnected state) inserted in the path provided by the MAC Relay Entity. For the Bridge to forward a given frame between two Ports, all three switches must be in the closed state. While showing Higher Layer Entities sharing the point of attachment to each LAN used by each Bridge Port to forward frames, this figure further illustrates a point made by Figure 8-12. Controls placed in the forwarding path have no effect on the ability of a Higher Layer Entity to transmit and receive frames to or from a given LAN using a direct attachment to that LAN (e.g., from entity A to LAN A); they only affect the path taken by any indirect transmission or reception (e.g., from entity A to or from LAN B).

!image

Figure 8-13—Effect of control information on the forwarding path

The functions provided by Higher Layer Entities can be categorized as requiring either

a) A single point of attachment to the Bridged Network, providing connectivity to stations attached to the network at any point (subject to administrative control), as does Bridge Management; or

b) A distinct point of attachment to each individual LAN attached by a Bridge Port, providing connectivity only to peer entities connected directly to that LAN, as do the Spanning Tree Protocol Entity and the MRP entity.

In the latter case, it is essential that the function associate each received and transmitted frame with a point of attachment. Frames transmitted or received via one point of attachment are not to be relayed to and from other Ports and attached LANs, so the MAC addresses (8.13.4) used to reach these functions are permanently configured in the FDB.

NOTE 1 —Addresses used to reach functions with distinct points of attachment are generally group MAC addresses.

NOTE 2—A single higher layer entity can incorporate both a function requiring a single point of attachment and a function requiring distinct points of attachment. The two functions are reached using different MAC addresses.

Figure 8-14 illustrates forwarding path connectivity for frames destined for Higher Layer Entities requiring per-Port points of attachment. Configuration of the Permanent Database in all Bridges to prevent relay of frames addressed to these entities means that they receive frames only via their direct points of attachment (i.e., from LAN A to entity A, and from LAN B to entity B), regardless of Port states.

!image

Figure 8-14—Per-Port points of attachment

Figure 8-15 and Figure 8-16 illustrate forwarding path connectivity for frames destined for a Higher Layer Entity requiring a single point of attachment. In both figures, the FDB permits relay of frames, as do the Port states in Figure 8-15 where frames received from LAN B are relayed by the Bridge to the entity and to LAN A.

!image

Figure 8-15—Single point of attachment—relay permitted

!image

Figure 8-16—Single point of attachment—relay not permitted

In Figure 8-16, frames received from LAN A are received by the entity directly, but frames received from LAN B are not relayed by the Bridge and will only be received by the entity if another forwarding path is provided between LANs A and B. If the Discarding Port state shown resulted from spanning tree computation (and not from disabling the Administrative Bridge Port State), such a path will exist via one or more Bridges. If there is no active spanning tree path from B to A, the network has partitioned into two separate Bridged Networks, and the Higher Layer Entity shown is reachable only via LAN A.

Specific Higher Layer Entities can take notice of the Administrative Bridge Port State, as required by their specification. The Spanning Tree Protocol Entity is one such example—BPDUs are never transmitted or received on Ports with an Administrative Bridge Port State of Disabled.

If a Bridge Port’s MAC Entity is not operational, a Higher Layer Entity directly attached at the Port will not be reachable, as Figure 8-17 illustrates. The Spanning Tree Protocol Entity ensures that the Port State is Discarding if the MAC_Operational (IEEE Std 802.1AC) is FALSE even if the Administrative Bridge Port State is Enabled.

Port-based network access control (IEEE Std 802.1X) and MAC Security (IEEE Std 802.1AE-2006 [B6]) can be used to provide a further level of control over the connectivity provided by a Bridge Port to the MAC Relay Entity and the Higher Layer Entities within a Bridge. Port-based network access control creates two distinct SAPs for the LAN: the Controlled Port and the Uncontrolled Port. MAC_Operational is TRUE for the Controlled Port only when criteria for authentication, authorization, and secure connectivity have been satisfied; while MAC_Operational for the Uncontrolled Port is the same as that for direct access to the LAN.

!image

Figure 8-17—Effect of Port State

Both the Spanning Tree Protocol Entity and the MAC Relay Entity attach to the Controlled Port, thus ensuring that the connectivity seen by each of those entities is the same. If MAC_Operational for the Controlled Port is FALSE, the Spanning Tree Protocol Entity will ensure that both forwarding and learning (8.4) will be FALSE for that Port (i.e., the Port State will be Discarding). The Uncontrolled Port supports the operation of protocol entities such as the Port Access Entity (PAE) specified by IEEE Std 802.1X, that participate in the authentication exchanges necessary before Controlled Port connectivity is permitted or that distribute other unsecured information.

Figure 8-18 illustrates the connectivity provided to Higher Layer Entities if the MAC entity is physically capable of transmitting and receiving frames but MAC_Operational is FALSE for the Controlled Port. Higher Layer Entity A and the PAE are connected to an Uncontrolled Port and can transmit and receive frames using the MAC entity associated with the Port for LAN A, which Higher Layer Entity B cannot. None of the three entities can transmit or receive to or from LAN B.

!image

Figure 8-18—Controlled and Uncontrolled Port connectivity

NOTE 3—Reference should be made to IEEE Std 802.1X-2010 or later.

NOTE 4—The administrative and operational state values associated with the MAC, the Port’s authorization state, and the Bridge Port State equate to the ifAdminStatus and ifOperStatus parameters associated with the corresponding interface definitions; see IETF RFC 2863 [B28].

8.13.10 VLAN attachment and connectivity for Higher Layer Entities

In VLAN Bridges, two more switches appear in the forwarding path, corresponding to the actions taken by the Forwarding Process (8.6) in applying the ingress and egress rules (8.6.2 and 8.6.4), as illustrated in Figure 8-19.

!image

Figure 8-19—Ingress/egress control information in the forwarding path

As with Port state information, the configuration of the ingress and egress rules does not affect the reception of frames received on the same LAN as a Higher Layer Entity’s point of attachment. For example, the reception of a frame by Higher Layer Entity A that was transmitted on LAN A is unaffected by the ingress or egress configuration of either Port. However, for Higher Layer Entities that require only a single point of attachment, the ingress and egress configuration affects the forwarding path. For example, frames destined for Higher Layer Entity A that are transmitted on LAN B would be subjected to the ingress rules that apply to Port B and the egress rules that apply to Port A.

The decision about whether frames transmitted by Higher Layer Entities are VLAN-tagged or untagged depends on the Higher Layer Entity concerned and the connectivity that it requires:

a) Spanning Tree Bridge Protocol Data Units (ST BPDUs) transmitted by the Spanning Tree Protocol Entity are not forwarded by Bridges and must be visible to all other Spanning Tree Protocol Entities attached to the same LAN. Such frames shall be transmitted untagged;

NOTE—Any BPDUs or MVRPDUs that carry a tag header are not recognized as well-formed BPDUs or MVRPDUs and are not forwarded by the Bridge.

b) The definition of the MVRP application (11.2.3) calls for all MVRP frames to be transmitted untagged for similar reasons;

c) The definition of the MMRP application (Clause 10) calls for all MMRP frames originating from VLAN devices to be transmitted VLAN-tagged, in order for the VID in the tag to be used to identify the VLAN context in which the registration applies;

d) It may be necessary for PDUs transmitted for Bridge Management (8.12) to be VLAN-tagged in order to achieve the necessary connectivity for management in a Virtual Bridged Network. This is normally achieved by routing a packet containing the PDU to the routed subnet associated with the VLAN. Transmission of the packet through the router interface to that VLAN and subsequent forwarding of the resulting frame by VLAN Bridges ensures that the frame is correctly VLANtagged, as required.

8.13.11 CFM entities

CFM entities reside in shims. The entities in a CFM shim inspect every frame that passes through either of the shim’s two SAPs, and decides whether to pass that frame through to the other SAP, process it, or both. The decision whether pass it through is not dependent on the destination_address, but the decision whether to process the frame is dependent on the destination_address (see Clause 19). A CFM entity shall discard any frame, directed to it by reason of its VID and MD Level, whose destination_address parameter does not correspond to a MAC address recognized by that CFM entity.

Any given CFM entity is configured to recognize one or more individual MAC addresses, and one or more group MAC addresses, in received frames, and to use one or more individual MAC address or one or more group MAC addresses for transmitted frames. The individual MAC address is unique, within a bridged network, to a specific Bridge, though not necessarily to a single Bridge Port (J.6). For VLAN-based and backbone service instances, the group MAC addresses are selected from Table 8-15 and Table 8-16 according to the MD Level and OpCode fields in the CFM PDU header. For these service instances, Loopback Messages (LBMs, 20.2), Loopback Replies (LBRs, 20.2), and Linktrace Replies (LTRs, 20.3) are carried in unicast frames while Continuity Check Messages (CCMs, 20.1) use addresses from Table 8-15, and Linktrace Messages (LTMs, 20.3) use addresses from Table 8-16. In the case of TESI, all CFM messages use the individual MAC addresses or the group MAC addresses that are associated with the monitored service (20.1, 20.2, 20.3).

Table 8-15—CCM group destination MAC addresses

<table><tr><td colspan="2">01-80-C2-00-00-3y</td></tr><tr><td>MD Level of CCM</td><td>Four address bits “y”</td></tr><tr><td>7</td><td>7</td></tr><tr><td>6</td><td>6</td></tr><tr><td>5</td><td>5</td></tr><tr><td>4</td><td>4</td></tr><tr><td>3</td><td>3</td></tr><tr><td>2</td><td>2</td></tr><tr><td>1</td><td>1</td></tr><tr><td>0</td><td>0</td></tr></table>

Table 8-16—LTM group destination MAC addresses

<table><tr><td colspan="2">01-80-C2-00-00-3y</td></tr><tr><td>MD Level of LTM</td><td>Four address bits “y”</td></tr><tr><td>7</td><td>F</td></tr><tr><td>6</td><td>E</td></tr><tr><td>5</td><td>D</td></tr><tr><td>4</td><td>C</td></tr><tr><td>3</td><td>B</td></tr><tr><td>2</td><td>A</td></tr><tr><td>1</td><td>9</td></tr><tr><td>0</td><td>8</td></tr></table>

NOTE—The group destination MAC addresses in Table 8-15 are there primarily to make it possible for Bridges built prior to this standard to process CFM. This restriction on the choice of group destination MAC addresses to be used on a CFM PDU is relaxed for ESP-VIDs. See 22.8.

9 Tagged frame format

This clause specifies the format of the tags added to and removed from user data frames by the tag encoding and decoding functions that support the EISS (6.8, 6.9, 6.10, 6.11) and the Backbone Service Instance Multiplex Entity (6.18). It

a) Reviews the purpose of tagging, and the functionality provided;

b) Specifies generic rules for the representation of tag fields and their encoding in the octets of an MSDU;

c) Specifies a general tag format, comprising a Tag Protocol Identifier (TPID), Tag Control Information (TCI), with additional information as signaled in the TCI, and

d) Specifies the format of the TPID for each IEEE 802 media access control method;

e) Describes the types of tags that can be used, including the following:

1) A C-TAG used at ports on a C-VLAN component,

2) An S-TAG used at ports on an S-VLAN component,

3) An I-TAG used at PIPs on an I-component and CBPs on a B-component;

f) Documents the allocation of EtherType values to identify the types of tag specified in this standard;

g) Specifies the format of the TCI and additional information for each tag type.

Further analysis of the frame formats and the format translations that can occur when frames are tagged or untagged when relayed between different media access control methods can be found in Annex G.

9.1 Purpose of tagging

Tagging a frame with a VLAN tag:

a) Allows a VID to be conveyed, facilitating consistent VLAN classification of the frame throughout the network and enabling segregation of frames assigned to different VIDs;

b) Allows priority (IEEE Std 802.1AC, 6.8) to be conveyed with the frame when using IEEE 802 LAN media access control methods that provide no inherent capability to signal priority;

9.2 Representation and encoding of tag fields

In this subclause, octets are numbered starting from 1 and increasing in the order in which they are encoded in the sequence of octets that constitute an MSDU.

Where bits in consecutive octets are used to encode a binary number in a single field, the lower octet number encodes the more significant bits of the field, and the LSB of the lower octet number and the most significant bit (MSB) of the next octet both form part of the field.

Where the value of a field comprising a sequence of octets is represented as a sequence of two-digit hexadecimal values separated by hyphens (e.g., A1-5B-03), the leftmost hexadecimal value (A1 in this example) appears in the lowest numbered octet of the field and the rightmost hexadecimal value (03 in this example) appears in the highest numbered octet of the field.

The bits in an octet are numbered from 1 to 8, where 1 is the LSB.

When the terms set and reset are used in the text to indicate the values of single-bit fields, set is encoded as a binary 1 and reset as a binary 0 (zero).

When the encoding of a field or a number of fields is represented using a diagram:

a) Octets are shown with the lowest numbered octet nearest the top of the page, the octet numbering increasing from the top to bottom; or

b) Octets are shown with the lowest numbered octet nearest the left of the page, the octet numbering increasing from left to right;

c) Within an octet, bits are shown with bit 8 to the left and bit 1 to the right.

9.3 Tag format

Each tag comprises the following sequential information elements:

a) A Tag Protocol Identifier (TPID) (9.4);

b) Tag Control Information (TCI) that is dependent on the tag type (9.5, 9.6);

c) Additional information, if and as required by the tag type and TCI.

The tag encoding function supports each EISS (6.8) instance by using an instance of the ISS to transmit and receive frames and encodes the above information in the first and subsequent octets of the MSDU that will accompany an ISS M_UNITDATA.request, immediately prior to encoding the sequence of octets that constitute the corresponding EISS M_UNITDATA.request’s MSDU. On reception the tag decoding function is selected by the TPID and decodes the TCI and additional information octets (if present) prior to issuing an EISS M_UNITDATA.indication with an MSDU that comprises the subsequent octets.

9.4 TPID formats

The TPID includes an EtherType value that is used to identify the frame as a tagged frame and to select the correct tag decoding functions. Such an EtherType is known as the Tag EtherType.

Where the ISS instance used to transmit and receive tagged frames is provided by a media access control method that can support EtherType encoding directly (e.g., is an IEEE 802.3 MAC) or is media access method independent (e.g., 6.8), the TPID is EtherType encoded, i.e., is two octets in length and comprises solely the assigned EtherType value.

Where the ISS instance is provided by a media access method that cannot directly support EtherType encoding (e.g., is an IEEE 802.11 MAC), the TPID is encoded according to the rule for a Subnetwork Access Protocol (Clause 9 of IEEE Std 802-2014) that encapsulates Ethernet frames over LLC, and comprises the SNAP header (AA-AA-03) followed by the SNAP PID (00-00-00) followed by the two octets of the assigned EtherType value.

9.5 Tag Protocol identification

The following types of tags are specified:

a) A C-TAG, for general use by C-VLAN Bridges (5.9) and C-VLAN components of Provider Edge Bridges (5.10.1).

b) An S-TAG, reserved for use by S-VLAN Bridges (5.10), the S-VLAN component of Provider Edge Bridges (5.10.1) and BEBs (5.12), and C-VLAN Bridges signaling priority to a PBN or a PBBN (6.13).

c) An I-TAG, reserved for use by BEBs (5.7, 5.8, 5.12).

NOTE—The S-TAG is identical to the B-TAG (see 25.2).

A distinct EtherType has been allocated (Table 9-1) for use in the TPID field (9.4) of each tag type so they can be distinguished from each other, and from other protocols.

Table 9-1—IEEE 802.1Q EtherType allocations

<table><tr><td>Tag Type</td><td>Name</td><td>Value</td></tr><tr><td>Customer VLAN Tag</td><td>IEEE 802.1Q Tag Protocol EtherType (802.1QTagType)</td><td>81-00</td></tr><tr><td>Service VLAN Tag or Backbone VLAN Tag</td><td>IEEE 802.1Q Service Tag EtherType (802.1QSTagType)</td><td>88-a8</td></tr><tr><td>Backbone Service Instance Tag</td><td>IEEE 802.1Q Backbone Service Instance Tag EtherType (802.1QITagType)</td><td>88-e7</td></tr></table>

9.6 VLAN Tag Control Information (TCI)

The VLAN TCI field (Figure 9-1) is two octets in length and encodes the vlan_identifier, drop_eligible, and priority parameters of the corresponding EISS M_UNITDATA.request as unsigned binary numbers.

!image

Figure 9-1—VLAN TCI format

The VID is encoded in a 12-bit field. A VLAN Bridge may not support the full range of VID values but shall support the use of all VID values in the range 0 through a maximum N, less than or equal to 4094 and specified for that implementation. Table 9-2 identifies VID values that have specific meanings or uses.

Table 9-2—Reserved VID values

<table><tr><td>VID value (hexadecimal)</td><td>Meaning/Use</td></tr><tr><td>0</td><td>The null VID. Indicates that the tag header contains only priority information; no VID is present in the frame. This VID value shall not be configured as a PVID or a member of a VID Set, or configured in any FDB entry, or used in any Management operation.</td></tr><tr><td>1</td><td>The default PVID value used for classifying frames on ingress through a Bridge Port. The PVID value of a Port can be changed by management.</td></tr><tr><td>2</td><td>The default SR_PVID value used for SRP (35.2.1.4(i)) Stream related traffic. The SR_PVID value of a Port can be changed by management.</td></tr><tr><td>FFF</td><td>Reserved for implementation use. This VID value shall not be configured as a PVID or a member of a VID Set, or transmitted in a tag header. This VID value may be used to indicate a wildcard match for the VID in management operations or FDB entries.</td></tr></table>

NOTE 1—There is a distinction between the range of VIDs that an implementation can support and the maximum number of active VIDs supported at any one time. An implementation supports only 16 active VIDs, for example, may use VIDs chosen from anywhere in the identifier space, or from a limited range. The latter can result in difficulties where different Bridges in the same network support different maximums. It is recommended that new implementations of this standard support the full range of VIDs, even if the number of active VIDs is limited.

The priority and drop_eligible parameters are conveyed in the 3-bit PCP field and the DEI field as specified in 6.9.3.

NOTE 2—Previous versions of this standard used bit 5 of octet 1 of the TCI in C-TAGs as a Canonical Format Indicator (CFI). Bridges conformant to this version of the standard will not interoperate with Bridges that set the CFI as a result of inserting C-TAGs in frames received from an 802.5 Token Ring LAN. Bridges conformant to this version of the standard will interoperate with Bridges that forward bit 5 of octet 1 as a CFI but do not have 802.5 Token Ring interfaces.

9.7 Backbone Service Instance Tag Control Information (I-TAG TCI)

The I-TAG TCI field (Figure 9-2) is 16 octets in length and encodes the priority, drop_eligible, destination_address, and source_address parameters of the corresponding service request primitive as unsigned binary numbers. I-TAGs are encoded and decoded at PIPs and CBPs of BEBs as specified in 6.10, 6.11, and 6.18.

!image

Figure 9-2—I-TAG TCI format

The I-TAG TCI contains the following fields:

a) I-PCP (Priority Code Point)—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. The PBBN operates on the priority associated with the B-TAG.

b) I-DEI (Drop Eligible Indicator)—This 1-bit field carries the drop_eligible parameter of the service request primitive associated with this frame. The PBBN operates on the drop eligibility associated with the B-TAG.

c) UCA (Use Customer Addresses)—A single-bit flag that, when containing a value of one, signals a Backbone Service Instance Multiplex Entity (6.18) to use the addresses contained in the C-DA and C-SA fields.

d) Res1 (Reserved 1)—This 1-bit field is used for any future format variations. The Res1 field contains a value of zero when the tag is encoded, and is ignored when the tag is decoded.

e) Res2 (Reserved 2)—This 2-bit field is used for any future format variations. The Res2 field contains a value of zero when the tag is encoded. The frame will be discarded if this field contains a nonzero value when the tag is decoded.

f) I-SID (Backbone Service Instance Identifier)—This 24-bit field carries the identifier of the backbone service instance.

g) C-DA (Encapsulated Customer Destination MAC address)—Contains the address in the destination_address parameter of the service request primitive associated with this frame. The address is represented using the Hexadecimal Representation as specified in IEEE Std 802 with the octet containing the I/G bit in the lowest numbered octet of the field.

h) C-SA (Encapsulated Customer Source MAC address)—Contains the address in the source_address parameter of the service request primitive associated with this frame. The address is represented using the Hexadecimal Representation as specified in IEEE Std 802 with the octet containing the I/G bit in the lowest numbered octet of the field.

The I-SID is encoded in a 24-bit field. Table 9-3 identifies I-SID values that have specific meanings or uses.

Table 9-3—Reserved I-SID values

<table><tr><td>I-SID value (hexadecimal)</td><td>Meaning/Use</td></tr><tr><td>0</td><td>Reserved for implementation use. This I-SID value shall not be configured as an identifier for a backbone service instance or transmitted in an I-TAG header. This I-SID value may be used in management and control operations, e.g., to indicate a deleted or null I-SID in ISIS-SPB TLVs (see Clause 28).</td></tr><tr><td>1</td><td>Default value—Unassigned ISID on a VIP.</td></tr><tr><td>2 through FE</td><td>Reserved for use by future amendments to this standard.</td></tr><tr><td>FF</td><td>SPBM default I-SID</td></tr><tr><td>FFFFFF</td><td>Reserved for implementation use. This I-SID value shall not be configured as an identifier for a backbone service instance or transmitted in an I-TAG header. This I-SID value may be used to indicate a wildcard match for the I-SID in management operations.</td></tr></table>

NOTE—There is a distinction between the range of I-SIDs that an implementation can support, and the maximum number of active backbone service instances supported at any one time. An implementation that supports only $2 ^ { 1 6 }$ active backbone service instances, for example, may use I-SIDs chosen from anywhere in the identifier space. Implementations of this standard support the full range of $\mathrm { \cdot _ { I - S i D s , } }$ even if the number of active backbone service instances is limited.

10 Multiple Registration Protocol (MRP) and Multiple MAC Registration Protocol (MMRP)

The Multiple Registration Protocol allows participants in an MRP application to register attributes with other participants in a Bridged Network. The definition of attribute types, their values, and the semantics associated with values when registered, are specific to each MRP application.

This clause

a) Provides an overview of the use of MRP within a bridged network (10.1)

b) Describes the architecture of MRP participants for end stations and Bridge Ports (10.2)

c) Specifies registration propagation between the per-Port Participants in a Bridge (10.3)

d) Details requirements to be met by the MRP design (10.4)

e) Details requirements for interoperability between MRP participants (10.5)

f) Provides an overview of protocol operation (10.6)

g) Provides a detailed specification of the protocol (10.7)

h) Describes the structure of PDUs exchanged between MRP participants (10.8)

Subclauses 10.9 through 10.12 define an MRP application, the Multiple MAC Registration Protocol (MMRP), that registers attributes of two types—MAC addresses and Group service requirements. Values of these attributes control MAC address filtering by MMRP participants.

Clause 11 defines a second MRP application, the Multiple VLAN Registration Protocol (MVRP), that registers VLAN membership information.

Clause 35 defines a third MRP application, the Multiple Stream Registration Protocol (MSRP), that registers data Stream characteristics and reserves Bridge resources as appropriate to provide QoS guarantees.

Clause 39 defines a fourth MRP application, the Multiple I-SID Registration Protocol (MIRP), that serves as an alternative to MVRP for per-VLAN flushing of learned MAC address information in I-components.

10.1 MRP overview

MRP allows a participant in a given MRP application to make or withdraw declarations of attributes, and for those declarations (or withdrawals) to result in the registration (or removal of registrations) of those attributes with the other MRP Participants for that application.

A declaration by an MRP Participant for an end station or Bridge Port is recorded by an Applicant state machine for the declared attribute and Port. Changes in the Applicant state machine’s variables trigger the transmission of MRPDUs to communicate the declaration (or withdrawal).

A registration is recorded by a Registrar state machine for the attribute at each participating end station and Bridge Port that receives the MRPDU. Removal of a given attribute registration occurs only if all the other participants connected to the same LAN withdraw the declaration.

Attributes registered on Bridge Ports that are part of the applicable active topology (8.4, 10.3.1) are declared on all the other Bridge Ports that are also part of that active topology. Hence, a given declaration is propagated to all application participants, and registered in each Bridge on those Ports that are “nearest” to the source or sources of the declaration within the active topology.

Figure 10-1 illustrates the result of a single end station making a declaration, and shows the Bridge Ports that also make declarations to propagate the attribute. The attribute is propagated to all LANs in the Bridged Network, but the directional nature of the propagation results in registration only on Bridge Ports that receive (as opposed to transmit) declarations.

!image

Figure 10-1—Example—Attribute value propagation from one station

NOTE—Unless otherwise stated, the following description assumes operation within the Base Spanning Tree Context (see 10.3.1). While registration can occur on any Bridge Port, regardless of Port State (8.4), propagation follows the spanning tree active topology. All the Bridge Ports shown in Figure 10-1, Figure 10-2, and Figure 10-3 are in the Forwarding Port State.

Figure 10-2 illustrates the result of different end stations declaring the same attribute on different LANs. All end stations register the attribute, and some Bridges register it on more than one Port.

The set of Bridge Ports and end stations that both declare and register a given attribute defines the subset of the active topology that contains all the participants declaring that attribute. A registration can be regarded as a pointer to participants that have declared that attribute, as illustrated in Figure 10-3 (using the same set of declarations and registrations that were illustrated in Figure 10-2).

Situations where it is desirable to form “reachability trees” are generally good candidates for the use of MRP. For example, if the attribute in Figure 10-3 is a group MAC address that is used as a destination address for a video data stream, and it is deemed desirable for that video data to be sent only to the subset of the active topology that contains end stations that have declared that attribute, then an end station that is the source of that video stream could use the presence or absence of a registration as an indication of whether to send the data on the LAN to which it is attached. Any Bridge receiving the data could determine on which Ports the data should be forwarded.

VLAN Bridges that do not support MRP are transparent to MRP exchanges, and forward received MRPDUs on all Ports that are in Forwarding. Similarly, VLAN Bridges that do not implement a given MRP application are transparent to MRP exchanges destined for that application, and forward any such received MRPDUs on all Ports that are in Forwarding.

!image

Figure 10-2—Example—Attribute value propagation from two stations

!image

Figure 10-3—Example—Registrations as pointers to the sources of declarations

MRP operates only on Ports that are MAC_Operational (IEEE Std 802.1AC). If the Port is operating as a network access port (IEEE Std 802.1X), MRP uses the controlled port (8.13.9). On any Port whose MAC_Operational parameter is FALSE, any MRP entity shall not transmit MRPDUs, and shall discard, without processing, any received MRPDUs.

MRP provides a means to mark initial attribute declarations and propagated attribute declarations as “new,” signaling to the recipient of the declaration that the attribute value is being newly declared, or is being redeclared following a change in the underlying topology. The rules applied to the marking and propagation of newly declared values in this way are common to all MRP Applications; however, the action taken on receipt of an attribute declaration marked as “new” is specific to each MRP Application. For example, MMRP (10.9) makes no use of the “new” marking, whereas MVRP (Clause 11) uses the “new” marking to permit FDB entries to be flushed on a per-VID basis following a topology change.

10.2 MRP architecture

An MRP Participant consists of an application component, and an MRP Attribute Declaration (MAD) component. The application component is responsible for the semantics associated with attribute values and their registration, including the use of explicitly signaled new declarations, and uses the following two primitives to request MAD to make or withdraw attribute declarations:

MAD_Join.request (attribute_type, attribute_value, new)

MAD_Leave.request (attribute_type, attribute_value)

where attribute_type specifies the type of the attribute declaration, and attribute_value specifies the instance of that type, and the Boolean new parameter indicates an explicit new declaration. If the value of tcDetected (13.25) for the Port and MAP Context associated with the MRP Participant is nonzero, then the value of the new parameter in the propagated MAD_Join.request is set TRUE.

The MAD component executes MRP (10.6, 10.7), generating MRP messages for transmission and processing messages received from other Participants, and uses the following two primitives to notify its application component of a change in Attribute registration:

MAD_Join.indication (attribute_type, attribute_value, new)

MAD_Leave.indication (attribute_type, attribute_value)

One such Participant, per MRP application, exists for each point of attachment to a LAN where Attributes for that application are to be declared or registered, i.e., one Participant per application in an end station, and one per application per Port in a Bridge. The encoding of Attribute values in MRPDUs and their subsequent decoding is application specific, within the general structure specified in 10.8, and each MRPDU conveys messages generated by the MAD component for a single application.

Within a Bridge, a per application MRP Attribute Propagation (MAP) component (10.3) propagates information between the per-Port Participants, using the same request and indication primitives.

Figure 10-4 illustrates the components of MRP Participants in a two-Port Bridge and an end station.

For each MRP application, the following are defined:

a) A set of Attribute types used by the application.

b) The Attribute values permitted for each Attribute type.

c) The semantics associated with each Attribute type and value.

d) The use made of MAP Contexts by the application.

e) The group MAC address and EtherType for protocol exchanges between application Participants.

f) The structure and encoding of the Attribute types and values in MRPDUs.

g) The requirements for MRP state machine support in end stations and Bridges.

h) The circumstances, if any, in which the application makes use of the “new” declaration capability.

NOTE 1—Not all applications of MRP will make use of the “new” declaration capability.

i) If the application makes use of the “new” declaration capability, the semantics that new registrations carry in that application.

j) The number of attribute values out of the possible range of values for which the application is expected to be capable of maintaining current state information.

NOTE 2—In some applications, such as MVRP, the failure of one Bridge in a network to maintain state for all possible attribute values would have major consequences for the integrity of the network. For such applications, the application definition will mandate the ability to track the state of all possible attribute values.

!image

Figure 10-4—MRP architecture

10.3 MRP Attribute Propagation (MAP)

The MAP function enables propagation of attributes registered on Bridge Ports across the network to other participants. Each MRP application specifies the operation of the MAP function. This subclause specifies the operation of the MAP function for the MMRP application, the MVRP application (11.2.1), and the MSRP application (35.2). In addition, 35.2.4 specifies additional MSRP attribute processing rules that modify the MAP function defined below.

For a given MRP application and MAP Context (10.3.1), and for the set of Ports that are in a Forwarding state as defined by that MAP Context, and for the set of attributes associated with that MAP Context:

a) Any MAD_Join.indication, or any MAD_Join.request issued by the MRP application, received by MAP from a given Port in the set is propagated as a MAD_Join.request to the instance(s) of MAD associated with each other Port in the set. If the value of tcDetected (13.25) for the given Port and MAP Context is nonzero, then the value of the new parameter in the propagated MAD_Join.request is set TRUE, regardless of the value of this parameter in the indication or request that is being propagated.

b) Any MAD_Leave.indication, or any MAD_Leave.request issued by the MRP application, received by MAP from a given Port in the set is propagated as a MAD_Leave.request to the instance(s) of

MAD associated with each other Port in the set (Port P, say) if and only if no registration now exists for that Attribute on any other Port in the set excluding P.

These rules propagate attribute registrations through any given Port if any other Port has seen a registration for that attribute, and propagate deregistrations if all other Ports are now deregistered.

As the set of Ports that are in a Forwarding state for a given MAP Context can change dynamically, for example as a result of spanning tree reconfiguration, MAP operates as follows after such a change:

c) If a Port is added to the set, and that Port has registered an attribute (i.e., a MAD_Join.indication or MAD_Join.request has occurred more recently than any MAD_Leave.indication or MAD_Leave.request for the attribute), then MAD_Join.requests are propagated to the MAD instances for each of the other Ports in the set.

d) If a Port is added to the set, but that Port has not declared an attribute that other Ports in the set have registered, then MAD_Join.requests are propagated by those other Ports to the MAD instance for that Port.

e) If a Port is removed from the set, and that Port has registered an attribute and no other Port has, then MAD_Leave.requests are propagated to the MAD instances for each of the other Ports in the set.

NOTE—If a Port is removed from the set, and that Port has declared one or more attributes, then this Port transmits a Leave message (see 10.6) for every attribute that it has declared.

f) If a Port is removed from the set, and that Port has registered an attribute that another Port has also registered, then a MAD_Leave.request is propagated to the MAD instance for that other Port.

10.3.1 MAP Context

For a given Port of an MRP-aware Bridge and MRP application supported by that Bridge, an instance of an MRP Participant can exist for each MRP Attribute Propagation Context (MAP Context) understood by the Bridge. A MAP Context identifies the set of Bridge Ports that form the applicable active topology (8.4).

Examples of MAP Contexts are as follows:

a) The active topology formed by the operation of RSTP (Clause 13). This MAP Context provides the same connectivity as the spanning tree in each Bridge and is known as the Base Spanning Tree Context.

b) The active topology formed by the subset of Bridge Ports, and the underlying spanning tree, that support a given VID. This MAP Context is known as a VLAN Context.

NOTE—This standard uses the Base Spanning Tree Context and VLAN Contexts to define the operation of MMRP and MVRP; however, other MAP Contexts may be used for other applications, or for extending MMRP functionality.

MRP exchanges can occur on all of the Ports of a Bridge; however propagation across a Bridged Network of attribute registrations for a given application uses only those Bridge Ports that are part of the active topology identified by the MAP Context. Each MRP application specification identifies the contexts it can operate within, specifies rules for selecting forwarding Ports, and assigns MAP Context identifiers for use in conjunction with the operation of MRP and its administrative controls (10.7.2, 10.7.3).

A MAP Context identifier of 0 always identifies the Base Spanning Tree Context. The MRP application specifies how the MAP Context of each MRPDU is identified if any other context is used.

10.3.1.1 MAD and Port role changes

A spanning tree provides a loop-free active topology connecting all the Bridges and all the LANs in a network. Hence, any Bridge Port that is in a forwarding state connects two otherwise disconnected parts of the topology. Each Alternate Port on a Bridge A (say) connects to a LAN that has a Port of another Bridge with a better priority vector than A can supply; hence, each of A's Alternate Ports is a potential connection to part of the network that is not connected to any of A’s Designated Ports, all LANs and Bridges in any such part having an equal or worse priority vector than A. Therefore, an Alternate Port on A potentially connects to the part of the network connected to by A's Root Port. Since any part of the network is fully connected, in the absence of registration controls, A's Alternate Port will have registered the same attributes as its Root Port.

For implementations running over RSTP or MSTP, this gives rise to the risk of information loops when Port roles change; because of the store and forward nature of attribute propagation and the potentially rapid transitions of Port roles (compared to the relatively slow transitions that occurred with STP), these can arise even when there are no data loops.

To prevent such information loops from occurring, the information held by MAD’s Registrars for a Port (i.e., information registered on a Port as a result of protocol activity on the LAN to which that Port is connected) is discarded whenever the Port transitions from an Alternate port or Root Port role to become a Designated Port. No such discard is needed for changes in the other direction, i.e., changes from Designated Port to Root Port or Alternate Port.

10.4 Requirements to be met by MRP

MRP establishes, maintains, withdraws, and disseminates attribute declarations and registrations among the MRP Participants attached to a single LAN. The protocol meets the following requirements for Applicant and Registrar behavior, error recovery, performance, scalability, compatibility with non-MRP aware devices, and the load imposed on Bridges, end stations, and the network:

a) Participants can issue declarations for MRP application attributes (10.2, 10.3, 10.7.3, and 10.7.7).

b) Participants can withdraw declarations for attributes (10.2, 10.3, 10.7.3, and 10.7.7).

c) Each Bridge propagates declarations to MRP Participants (10.3).

d) MRP Participants can track the current state of declaration and registration of attributes on each Port of the participant device (10.7.7 and 10.7.8).

e) MRP Participants can remove state information relating to attributes that are no longer active within part or all of the network, e.g., as a result of the failure of a participant (10.7.8 and 10.7.9).

f) The latency involved in issuing, propagating, or revoking attribute declarations, is small (i.e., comparable to the frame propagation delay) and increases linearly as a function of the diameter of the network (10.7.7, 10.7.8, and 10.7.9).

g) MRP is resilient in the face of the failure of MRP Participants.

h) MRP is resilient in the face of single packet loss.

i) MRP will operate correctly in networks where

1) All Bridges support both Basic and Extended Filtering Services; or where

2) Some Bridges support only Basic Filtering Services and some both Basic and Extended Filtering Services (10.5, 10.7.7, 10.7.8, and 10.7.9).

j) The communications bandwidth consumed on any particular LAN by Applicants and Registrars in exchanging MRPDUs will be a small percentage of the total available bandwidth, and independent of the total traffic supported by the network. The bandwidth consumed will be a function of the number of attributes registered.

10.5 Requirements for interoperability between MRP Participants

To ensure the interoperability of MRP, the following are required:

a) All MRP applications use a group MAC address as the destination address of MRPDUs, selected in accordance with the stated requirements of the MRP application concerned for the type of Bridge component in which the application is implemented. The addresses used may be taken from the set of addresses specified in Table 10-1, or taken from the set of reserved addresses specified in Table 8-1, Table 8-2, and Table 8-3, or other group MAC addresses, chosen according to the particular properties required by the application concerned.

NOTE 1—The addresses in Table 8-1, Table 8-2, Table 8-3, and Table 10-1 differ from other group MAC addresses in terms of the scope of transmission within a network, as a consequence of the forwarding/filtering decisions that are taken relative to them by different types of Bridge component.

b) Table 10-1 specifies a set of group MAC addresses, some that have been assigned for use by existing applications defined in this standard, and the others reserved for future standards use. Addresses in this set have the property that

1) Where a given address in the set is used by a Bridge component to support an MRP application, frames destined for that address shall not be forwarded by that Bridge component; i.e., a Static Filtering Entry for that address is maintained for that group MAC address in order to prevent the forwarding of frames destined for that address.

2) Where a given address in the set is not used by a Bridge component to support any MRP application, frames destined for that address received on any Port that is part of a given active topology shall be forwarded by that Bridge component on all other Ports that are part of that active topology.

c) The transmission and reception of MRPDUs between MRP Participants, formatted as defined for the application using the generic PDU format defined in 10.8, shall use LLC procedures. Each MRP application uses a unique EtherType value in order to identify the application protocol. Table 10-2 specifies the EtherType values assigned to existing applications.

NOTE 2—For the purposes of this standard, the expression “use LLC procedures” includes making use of the service provided by link layer protocol entities that support protocol discrimination by means of an EtherType value.

d) MRPDUs, i.e., frames with the destination MAC addresses selected as specified in item a) and the EtherType values specified in item c), that are destined for applications supported by a Bridge component, and that are not well formed (i.e., are not structured and encoded as defined in 10.8 and with attribute types and values encoded as defined by the MRP application), shall be discarded on receipt.

Table 10-1—MRP application addresses

<table><tr><td><eq>Assignment^a</eq></td><td>Value</td></tr><tr><td>Customer and Provider Bridge MMRP address</td><td>01-80-C2-00-00-20</td></tr><tr><td>Customer Bridge MVRP address</td><td>01-80-C2-00-00-21</td></tr><tr><td>Reserved</td><td>01-80-C2-00-00-22</td></tr><tr><td>Reserved</td><td>01-80-C2-00-00-23</td></tr><tr><td>Reserved</td><td>01-80-C2-00-00-24</td></tr><tr><td>Reserved</td><td>01-80-C2-00-00-25</td></tr><tr><td>Reserved</td><td>01-80-C2-00-00-26</td></tr><tr><td>Reserved</td><td>01-80-C2-00-00-27</td></tr><tr><td>Reserved</td><td>01-80-C2-00-00-28</td></tr><tr><td>Reserved</td><td>01-80-C2-00-00-29</td></tr><tr><td>Reserved</td><td>01-80-C2-00-00-2A</td></tr><tr><td>Reserved</td><td>01-80-C2-00-00-2B</td></tr><tr><td>Reserved</td><td>01-80-C2-00-00-2C</td></tr><tr><td>Reserved</td><td>01-80-C2-00-00-2D</td></tr><tr><td>All Provider Bridge Intermediate Systems</td><td>01-80-C2-00-00-2E</td></tr><tr><td>All Customer Bridge Intermediate Systems</td><td>01-80-C2-00-00-2F</td></tr></table>

a MIRP is an MRP application, but is not assigned an address from this table (39.2.1.5, 39.2.1.6).

Table 10-2—MRP EtherType values

<table><tr><td>Assignment</td><td>Value</td></tr><tr><td>MMRP EtherType</td><td>88-F6</td></tr><tr><td>MVRP EtherType</td><td>88-F5</td></tr><tr><td>MSRP EtherType</td><td>22-EA</td></tr><tr><td>MIRP EtherType</td><td>89-29</td></tr></table>

10.6 Protocol operation

This subclause provides an informal introduction. The definitive specification of MRP is contained in 10.7 and 10.8.

MRP is a simple, fully distributed, many-to-many protocol, that supports efficient, reliable, and rapid declaration and registration of attributes by multiple participants on shared and virtual shared media. MRP also incorporates optimizations to speed attribute declarations and withdrawals on point-to-point media. Correctness of MRP operation is independent of the relative values of protocol timers, and the protocol design is based primarily on the exchange of idempotent protocol state rather than commands.

A full MRP Participant maintains Registrar and Applicant state machines for each Attribute of interest, and a LeaveAll state machine and PeriodicTransmission state machine for the participant as a whole.

The job of the Registrar is to record declarations of the attribute made by other Participants on the LAN. It does not send any protocol messages, as the Applicant looks after the interests of all would-be Participants.

The job of the Applicant is twofold:

a) To ensure that this Participant’s declaration is correctly registered by other Participants’ Registrars.

b) To prompt other Participants to reregister after one withdraws a declaration.

NOTE 1—Applicant-Only implementations are concerned only with item a).

The basic design of MRP is oriented to LAN environments, where there is generally a low probability of frame loss, and ensures that timely registration of attributes is unaffected unless at least two out of a set of immediately related frames are lost. The LeaveAll state machine periodically ensures that Participants reregister attributes, thus guarding against an extended failure to register or deregister. In potentially lossy environments such as service instances supported by PBNs, where frame losses are temporally correlated, the PeriodicTransmission machine ensures successful registration without immediately contributing to congestive loss.

If one Applicant has both declared and registered an Attribute, other Applicants do not need to reiterate the declaration. MRP messages convey both Applicant and Registrar state to allow suppression of such repeated declarations. The Applicant state machine distinguishes between Active Participants (that have sent a message or messages to make a declaration), Passive Participants (that require registration, but have not had to declare the attribute so far to register it, and will not have to explicitly deregister), and Observers (that do not require registration at present, but track the attribute’s registration in case they do and become Passive Participants). The following four distinct messages communicate the transmitting participant’s state for an Attribute:

Empty—Not declared, and not registered.

In—Not declared, but registered.

JoinEmpty—Declared, but not registered.

JoinIn—Declared and registered.

One message communicates a withdrawal of a prior declaration, so that Registrars do not have to track individual Applicants:

Leave—Previously registered, but now withdrawn.

A further message conveys a declaration from a new Participant, or a Participant newly added to the active topology reached through a Bridge Port. This information is propagated by the MAP component, and so includes additional registrations elsewhere in the bridged network:

New—Newly declared, and possibly not previously registered.

The LeaveAll state machine uses the following single message that applies to all Attributes.

— LeaveAll—All registrations will shortly be deregistered; Participants need to reregister.

The Registrar for each Attribute actually implements the following three states for the Attribute:

IN—Registered.

LV—Previously registered, but now being timed out.

MT—Not registered.

A single timer, the leavetimer, is associated with each Registrar and operates in the LV state. In that state, MRP messages for the Attribute report it as unregistered (using Empty or Join Empty) but the MAD Leave indication is delayed until the leavetimer expires and the state transitions to MT.

NOTE 2—The accuracy required for the leavetimer is sufficiently coarse to permit the use of a single operating system timer per Participant with 2 bits of state for each Registrar.

The Applicant for each Attribute implements states that record whether it wishes to make a new declaration, to maintain or withdraw an existing declaration, or has no declaration to make. It also records whether it has actively made a declaration, or has been passive, taking advantage of or simply observing the declarations of others. It counts the New, JoinIn, and JoinEmpty messages it has sent, and JoinIn messages sent by others, to ensure that at least two such messages have been sent since it last received a LeaveAll or Leave message, and at least one since it last received a JoinEmpty or Empty message. This ensures that each of the other Participant’s Registrars for the Attribute either have received (assuming no packet loss) two Join or New messages or have reported the Attribute as registered. The Applicant state machine (Table 10-3) uses the following states:

VO—Very anxious Observer. The applicant is not declaring the attribute, and has not received a JoinIn message since the state machine was initialized, or since last receiving a Leave or LeaveAll.

VP—Very anxious Passive. The applicant is declaring the attribute, but has neither sent a Join nor received a JoinIn since the state machine was initialized, or since last receiving a LeaveAll or Leave.

VN—Very anxious New. The applicant is declaring the attribute, but has not sent a message since receiving a MAD Join request for a new declaration.

AN—Anxious New. The applicant is declaring the attribute, and has sent a single New message since receiving the MAD Join request for the new declaration.

AA—Anxious Active. The applicant is declaring the attribute, and has sent a Join message, since the last Leave or LeaveAll, but either has not received another JoinIn or In, or has received a subsequent message specifying an Empty registrar state.

QA—Quiet Active. The applicant is declaring the attribute and has sent at least one of the required Join or New messages since the last Leave or LeaveAll, has seen or sent the other, and has received no subsequent messages specifying an Empty registrar state.

LA—Leaving Active. The applicant has sent a Join or New message since last receipt of a Leave or LeaveAll, but has subsequently received a MAD Leave request and has not yet sent a Leave message.

AO—Anxious Observer. The applicant is not declaring the attribute, but has received a JoinIn since last receiving a Leave or LeaveAll.

QO—Quiet Observer. The applicant is not declaring the attribute, but has received two JoinIns since last receiving a Leave or LeaveAll, and at least one since last receiving a message specifying an Empty registrar state.

AP—Anxious Passive. The applicant is declaring the attribute, and has not sent a Join or a New since last receiving a Leave or a LeaveAll but has received messages as for the Anxious Observer state.

QP—Quiet Passive. The applicant is declaring the attribute, and has not sent a Join or a New since last receiving a Leave or a LeaveAll but has received messages as for the Quiet Observer state.

LO—Leaving Observer. The applicant is not declaring the attribute, and has received a Leave or LeaveAll message.

If an Applicant receives a Leave or LeaveAll message it will send a JoinEmpty or Empty message, and that message will prompt any other Applicants that are declaring the attribute to send a JoinIn. An Applicant that sends a LeaveAll message will also ensure that an Empty message is sent to prompt other Applicants to repeat their declaration. Thus, if any Participant’s Registrar deregisters an Attribute, at least two messages will be lost before another Participant’s Applicant fails to make a required redeclaration.

To facilitate and encourage the transmission of timely protocol information and the encoding of messages for multiple Attributes within the same MRPDU, rather than the use and subsequent queuing of multiple PDUs prior to transmission, PDU transmission is specified in terms of requests for a transmission opportunity, and the Applicant and LeaveAll state machines specify the necessary addition of messages to an MRPDU when that opportunity occurs. Whenever a state machine transitions to a state that requires transmission of a message, a transmit opportunity is requested if one is not already pending. The message actually transmitted (if any) is that appropriate to the state of the machine when the opportunity is presented.

NOTE 3—Specifying transmit opportunity requests and their subsequent use is also intended to aid correct implementation in systems where a transmission is not possible immediately, e.g., shortly after whole or part of the system is initialized when other claims on system resources take precedence or interfaces are not yet available.

To support the efficient encoding of many messages in a single MRPDU, the number of message types has been kept to the minimum consistent with protocol goals and requirements, and the state machines specify both whether it is necessary to send a message and a message type that can always be sent—thus removing the need for a further “no message” encoding. The MRPDU structure and compact encoding (10.8) allows all potential attributes for certain MRP applications, e.g., MVRP (Clause 11), to be encoded in a single IEEE 802.3 frame and this further promotes protocol efficiency through ready detection of missing registrations. Protocol efficiency and correct registration are further supported by encoding a LeaveAll message (if required) at the beginning of the MRPDU, and by using an Applicant state machine that minimizes state changes for those Attributes whose redeclaration can be encoded in the same PDU—if the LeaveAll is received by another Participant so also will be the redeclaration, and sequential processing of the encoded messages by the recipient will ensure that the registration is uninterrupted. Applicant states for Attributes that cannot be redeclared in the same PDU allow for receipt of the LeaveAll but loss of the redeclaration.

LeaveAll messages are transmitted to ensure that any failure to withdraw a declaration does not result in an unwanted permanent registration—perhaps the system or process responsible for the registration has been removed from the LAN or has ceased to operate. Attributes registered by the Participant transmitting the LeaveAll as well as those receiving it are therefore timed out. The LeaveAll state machine (10.7.9) for the Participant operates a single timer, the leaveAllTimer, that causes a transmit opportunity to be requested when it expires, and transmission of a LeaveAll at the next opportunity. Reception of a LeaveAll message from another Participant causes the timer to be restarted without generating a message, thus suppressing multiple LeaveAll messages from Participants connected to the same LAN.

NOTE 4—In the face of changing inputs, arbitrary loss, delay, reordering, and unsignaled interruption in participation, no protocol will meet its objectives. What can be said is that the objectives will be met after a known period of operation within specified limits, and what failures are most likely otherwise. MRP favors ensuring that registrations are made, at the expense of tolerating prolonged registrations. Thus, the LeaveAll mechanism, when it has an effect, most often implements “garbage collection.” At the same time it will also ensure that failed registrations are (re-)established.

When MRP Participants are connected by a shared or virtual shared medium, protocol performance is improved and the effect on other protocols using the LAN minimized if the Participants transmit at different times, avoiding a multicast storm and allowing some to optimize their transmissions based on messages received. A request for a transmit opportunity starts a randomized join timer, with a maximum value chosen to ensure successful reregistration(s) within a Leave time period (10.7.4), and the transmit opportunity is offered when the timer expires. If more messages are to be sent than can fit in a single PDU, a further transmit opportunity is requested.

When two MRP Participants are connected by a point-to-point medium or service instance delaying MRPDU transmission provides no benefit. In bridged networks it is desirable to transmit without delay, minimizing the denial of service that might occur while registration changes propagate after reconfiguration, and maximizing the benefit from using protocols such as RSTP and MSTP. When operPointToPointMAC (IEEE Std 802.1AC) is TRUE, transmit opportunities are scheduled immediately on request, subject to rate limiting (10.7.4).

Use of point-to-point service connecting at most two Participants allows further protocol optimization, e.g., receipt of an In message does acknowledge registration. However, not all LAN media support reliable determination of point-to-point status, particularly if nonstandard bridge-like devices are present. When operating in point-to-point mode, MRP avoids behavior that could cause failure, potentially continuous rapid exchanges of messages, or flapping registrations if there are more than two Participants. This standard permits simple point-to-point subset implementations of MRP, but these will successfully operate on shared media—albeit at reduced efficiency.

NOTE 5—IEEE Std 802.1AE-2006 [B6] (MAC Security) can ensure that there are at most two communicating Participants.

In certain contexts, often encountered in PBNs or PBBNs, it is necessary to control the VLAN entries in the FDB using Static VLAN Registration Entries, and retain only the ability to signal the need to flush learned MAC Address Entries via MRP. A New-Only Participant supports this need by implementing only a part of the Applicant and Registrar state machines, but not implementing the LeaveAll state machine, and by transmitting and receiving only New messages. It is also possible to simplify an MRP Participant that only wishes to make declarations; for example, for an end station that uses MMRP (10.9) to declare a need to receive group addressed frames, but is not a source of such frames, and therefore does not need to support source pruning by registering declarations from other Participants. Such an Applicant-Only Participant does not implement the Registrar or LeaveAll state machines, never sends LeaveAll, Empty, or JoinEmpty messages (which would elicit unnecessary Joins from its peer Participants), and does not implement the administrative controls defined in 10.7.2 and 10.7.3. The following five types of MRP implementation conform to this standard:

Full Participant

Full Participant, point-to-point subset

— New-Only Participant

Applicant-Only Participant

— Applicant-Only point-to-point subset, also referred to as the Simple-Applicant Participant

While Simple-Applicant and Full Participant point-to-point subset implementations can operate on shared media, their initial Join and Leave messages are not suppressed. Significant additional, and unnecessary, traffic can result from attaching several such implementations to the same shared medium. Devices that do not perform registration should use an Applicant-Only Participant rather than a Simple-Applicant Participant.

NOTE 6—At the time of the development of this standard the LAN MACs most commonly used were point-to-point but the use of virtual shared media was increasing.

10.7 Protocol specification

The operation of MRP as executed by the MRP Attribute Declaration (MAD, 10.2) component of an MRP Participant is represented by the following state machines:

a) A per-Attribute Applicant state machine (10.7.7)

b) A per-Attribute Registrar state machine (10.7.8)

c) A LeaveAll state machine for the Participant as a whole (10.7.9)

d) A PeriodicTransmission state machine for the Participant as a whole (10.7.10)

These state machines are specified as compact state tables, and make use of the following:

e) Notational conventions and abbreviations for protocol events, actions, and timer operations (10.7.1)

f) Registrar Administrative Controls (10.7.2)

g) Applicant Administrative Controls (10.7.3)

h) Protocol timers (10.7.4)

i) Protocol event definitions (10.7.5)

j) Protocol action definitions (10.7.6)

A Full Participant implements the complete Applicant state machine (Table 10-3) and the Registrar state machine (Table 10-4) for each Attribute declared, registered, or tracked, together with a single instance of the LeaveAll state machine (Table 10-5) and the PeriodicTransmission state machine (Table 10-6).

The point-to-point subset of the Full Participant implements the same state machines, but omits certain Applicant state machine states and actions as specified by Table 10-3.

A New-Only Participant implements the Applicant state machine, with the omission of certain states and actions, as specified in Table 10-3, and the Registrar state machine (Table 10-4), for each Attribute declared, registered, or tracked, but does not implement the LeaveAll state machine (Table 10-5) or the PeriodicTransmission state machine (Table 10-6). Applications that permit both Full Participants and New-Only Participants define managed objects (12.9) to make the selection on a per-Port basis.

An Applicant-Only Participant implements the Applicant state machine, with the omission of certain states and actions as specified by Table 10-3, for each Attribute declared, registered, or tracked, together with a single instance of the PeriodicTransmission state machine (Table 10-6).

The point-to-point subset of the Applicant-Only Participant (the Simple-Applicant Participant) implements the same state machines, but omits certain Applicant state machine states and actions as specified by Table 10-3.

NOTE—Conceptually, per-Attribute state is maintained for all possible values of all Attribute types that are defined for a given application; however, in real implementations of MRP, it is likely that the range of possible Attribute values in some applications will preclude this, and the implementation will limit the state to those Attribute values in which the Participant has an immediate interest, either as a Member or as a likely future Member.

Timer values, their relationships, and default values are described in 10.7.11 and Table 10-7, protocol management statistics accumulated by each MAD component in 10.7.12, and interoperability considerations for potentially misordering networks in 10.7.13.

The encoding of MRP messages in MRPUs is specified in 10.8, which also specifies the parsing and checks applied to received PDUs.

10.7.1 Notational conventions and abbreviations

The following conventions are used in the abbreviations used in this subclause:

rXXX receive PDU XXX

sXXX send PDU XXX

txXXX transmit opportunity

XXX! state machine event

!XXX “Not XXX”; i.e., logical NOT applied to the condition XXX

The following abbreviations are used in the state machine descriptions. For their meaning, see 10.7.5 and 10.7.6.

Protocol events:

Begin! Initialize state machine (10.7.5.1)

New! A new declaration (10.7.5.4)

Join! Declaration without signaling new registration (10.7.5.5)

Lv! Withdraw a declaration (10.7.5.6)

tx! Transmission opportunity without a LeaveAll (10.7.5.7)

txLA! Transmission opportunity with a LeaveAll (10.7.5.8)

txLAF! Transmission opportunity with a LeaveAll, and with no room (Full) (10.7.5.9)

rNew! receive New message (10.7.5.14)

rJoinIn! receive JoinIn message (10.7.5.15)

rIn! receive In message (10.7.5.18)

rJoinMt! receive JoinEmpty message (10.7.5.16)

rMt! receive Empty message (10.7.5.19)

rLv! receive Leave message (10.7.5.17)

rLA! receive a LeaveAll message (10.7.5.20)

Flush! Port role changes from Root Port or Alternate Port to Designated Port (10.7.5.2)

Re-Declare! Port role changes from Designated to Root Port orAlternate Port (10.7.5.3)

periodic! A periodic transmission event occurs (10.7.5.10)

leavetimer! leavetimer has expired (10.7.5.21)

leavealltimer! leavealltimer has expired (10.7.5.22)

periodictimer! periodictimer has expired (10.7.5.23)

Protocol actions:

<table><tr><td>New</td><td>send a New indication to MAP and the MRP application (10.7.6.12)</td></tr><tr><td>Join</td><td>send a Join indication to MAP and the MRP application (10.7.6.13)</td></tr><tr><td>Lv</td><td>send a Lv indication to MAP and the MRP application (10.7.6.14)</td></tr><tr><td>sN</td><td>send a New message (10.7.6.2)</td></tr><tr><td>sJ</td><td>send a JoinIn or JoinMT message (10.7.6.3)</td></tr><tr><td>sL</td><td>send a Lv message (10.7.6.4)</td></tr><tr><td>s</td><td>send an In or an Empty message (10.7.6.5)</td></tr><tr><td>[s]</td><td>send an In or an Empty message, if required for optimization of the encoding (10.7.6.5)</td></tr><tr><td>[sL]</td><td>send a Lv message, if required for optimization of the encoding (10.7.6.4)</td></tr><tr><td>[sJ]</td><td>send a Join message, if required for optimization of the encoding (10.7.6.3)</td></tr><tr><td>sLA</td><td>send a Leave All message (10.7.6.6)</td></tr><tr><td>periodic</td><td>Periodic transmission event (10.7.6.7).</td></tr><tr><td>leavetimer</td><td>Leave period timer (10.7.4.2)</td></tr><tr><td>leavealltimer</td><td>Leave All period timer (10.7.4.3)</td></tr><tr><td>periodictimer</td><td>Periodic Transmission timer (10.7.4.4)</td></tr><tr><td>-x-</td><td>Inapplicable event/state combination. No action or state transition occurs in this case.</td></tr></table>

Timers are used in the state machine descriptions in order to cause actions to be taken after defined time periods have elapsed. The following terminology is used in the state machine descriptions to define timer states and the actions that can be performed upon them:

a) A timer is said to be running if the most recent action to be performed upon it was a start.

b) A running timer is said to have expired when the time period associated with the timer has elapsed since the most recent start action took place.

c) A timer is said to be stopped if it has expired or if the most recent action to be performed upon it was a stop action.

d) A start action sets a stopped timer to the running state, and associates a time period with the timer. This time period supersedes any periods that might have been associated with the timer by previous start events.

e) A stop action sets a timer to the stopped state.

The following abbreviations are used for the state names in the state tables and state diagrams:

Registrar states (see 10.6):

<table><tr><td>IN</td><td>In</td></tr><tr><td>LV</td><td>Leaving</td></tr><tr><td>MT</td><td>Empty</td></tr></table>

Applicant and Simple-Applicant states (see 10.6):

<table><tr><td>VO</td><td>Very anxious Observer</td></tr><tr><td>VP</td><td>Very anxious Passive</td></tr><tr><td>VN</td><td>Very anxious New</td></tr><tr><td>AN</td><td>Anxious New</td></tr><tr><td>AA</td><td>Anxious Active</td></tr><tr><td>QA</td><td>Quiet Active</td></tr><tr><td>LA</td><td>Leaving Active</td></tr><tr><td>AO</td><td>Anxious Observer</td></tr><tr><td>QO</td><td>Quiet Observer</td></tr><tr><td>AP</td><td>Anxious Passive</td></tr><tr><td>QP</td><td>Quiet Passive</td></tr><tr><td>LO</td><td>Leaving Observer</td></tr></table>

10.7.2 Registrar Administrative Controls

Associated with each instance of the Registrar state machines are Registrar Administrative Control parameters. These parameters allow administrative control to be exercised over the registration state of each Attribute value, and hence, via the propagation mechanism provided by MAP, allow control to be exercised over the propagation of declarations.

a) Normal Registration. The Registrar responds to incoming MRP messages as specified by Table 10- 4.

b) Registration Fixed (New ignored). The Registrar ignores all MRP messages, and remains IN (registered).

c) Registration Fixed (New propagated). The Registrar ignores all MRP messages except New, and remains IN (registered).

d) Registration Forbidden. The Registrar ignores all MRP messages, and remains MT (unregistered).

The default value of this parameter is Normal Registration.

If the value of this parameter is Registration Fixed (New ignored) or Registration Fixed (New propagated), In and JoinIn messages are sent. If the value of this parameter is Registration Forbidden, Empty or JoinEmpty messages are sent. If the value of this parameter is Registration Fixed (New propagated), only New messages are accepted.

NOTE—The Registrar Administrative Controls are realized by means of the contents of the Port Map parameters of static entries in the FDB for all MRP applications In the case of MMRP, the static entries concerned are Static Filtering Entries (8.8.1); in the case of MVRP and MIRP, the static entries concerned are Static VLAN Registration Entries (8.8.2). The contents of the Port Map parameters in static entries can be modified by means of the management operations defined in Clause 12. In the absence of such control information for a given attribute, the default value “Normal Registration” is assumed

10.7.3 Applicant Administrative Controls

An overall control parameter for each Applicant state machine, the Applicant Administrative Control, determines whether the Applicant state machine participates in MRP exchanges.

a) Normal Participant. The state machine participates normally in MRP exchanges.

b) New-Only Participant. The state machine sends only New MRP messages.

c) Non-Participant. The state machine does not send any MRP messages.

The default value of this parameter is Normal Participant.

NOTE 1—The Applicant Administrative Control parameters can be modified for any MRP application by means of the management operations defined in Clause 12. In the absence of such information for a given attribute, the default value “Normal Participant” is assumed.

NOTE 2—The Applicant Administrative Control parameters can be set per attribute type (see 12.9.2).

10.7.4 Protocol timers

10.7.4.1 jointimer

The Join Period Timer, jointimer, controls the interval between transmit opportunities that are applied to the Applicant state machine. An instance of this timer is required on a per-Port, per-MRP Participant basis. The value of JoinTime used to initialize this timer is determined in accordance with 10.7.11.

10.7.4.2 leavetimer

The Leave Period Timer, leavetimer, controls the period of time that the Registrar state machine will wait in the LV state before transiting to the MT state. An instance of the timer is required for each state machine that is in the LV state. The Leave Period Timer is set to the value LeaveTime when it is started; LeaveTime is defined in Table 10-7.

10.7.4.3 leavealltimer

The Leave All Period Timer, leavealltimer, controls the frequency with which the LeaveAll state machine generates LeaveAll PDUs. The timer is required on a per-Port, per-MRP Participant basis. The Leave All Period Timer is set to a random value, T, in the range LeaveAllTime $< \mathrm { T } < 1 . 5 ^ { * } \mathrm { I }$ eaveAllTime when it is started. LeaveAllTime is defined in Table 10-7.

10.7.4.4 periodictimer

The Periodic Transmission timer, periodictimer, controls the frequency with which the PeriodicTransmission state machine generates periodic! events. The timer is required on a per-Port basis. The Periodic Transmission timer is set to one second when it is started.

10.7.5 Protocol event definitions

Unless stated otherwise in these event definitions, MRPDU reception in a Bridge can occur through all Ports of a Bridge, and events generated as a result of such reception affect only those state machines that are associated with the Port through which the PDU was received.

10.7.5.1 Begin!

The state machine is initialized or reinitialized.

10.7.5.2 Flush!

A Flush! event signals to the Registrar state machine that there is a need to rapidly deregister information on the Port associated with the state machine as a result of a topology change that has occurred in the network topology that supports the propagation of MRP information. If the network topology is maintained by means of the spanning tree protocol state machines, then, for the set of Registrar state machines associated with a given Port and spanning tree instance, this event is generated when the Port Role changes from either Root Port or Alternate Port to Designated Port.

When a Flush! event occurs for a given Port and spanning tree instance, a leavealltimer! event (10.7.5.22) is also signaled to the LeaveAll state machine for that Port and spanning tree instance.

10.7.5.3 Re-declare!

A Re-declare! event signals to the Applicant and Registrar state machines that there is a need to rapidly redeclare registered information on the Port associated with the state machines as a result of a topology change that has occurred in the network topology that supports the propagation of MRP information. If the network topology is maintained by means of the spanning tree protocol state machines, then, for the set of Applicant and Registrar state machines associated with a given Port and spanning tree instance, this event is generated when the Port Role changes from Designated Port to either Root Port or Alternate Port.

10.7.5.4 New!

A new declaration is made. The event is deemed to have occurred if the MAD Service User issues a MAD_Join.request service primitive for the Attribute instance associated with that state machine, indicating a new declaration.

10.7.5.5 Join!

A declaration is made. The event is deemed to have occurred if the MAD Service User issues a MAD_Join.request service primitive for the Attribute instance associated with that state machine.

10.7.5.6 Lv!

A declaration is withdrawn. The event is deemed to have occurred if the MAD Service User issues a MAD_Leave.request service primitive for the Attribute instance associated with that state machine.

10.7.5.7 tx!

A transmission opportunity occurs, without a LeaveAll being signaled by the LeaveAll state machine.

NOTE—The tx! event is modified by the behavior of the LeaveAll state machine. If the LeaveAll state machine has signaled LeaveAll, then tx! is modified to txLA! (see 10.7.5.8).

10.7.5.8 txLA!

A transmission opportunity occurs, with a LeaveAll being signaled by the LeaveAll state machine.

10.7.5.9 txLAF!

A transmission opportunity occurs, with a LeaveAll being signaled by the LeaveAll state machine, and with no room available in the PDU.

10.7.5.10 periodic!

This event indicates to the Applicant state machine that the timer used to stimulate periodic transmission has expired.

10.7.5.11 periodicEnabled!

This event indicates to the Periodic Transmission state machine that it has been enabled by management action (12.9.3).

10.7.5.12 periodicDisabled!

This event indicates to the Periodic Transmission state machine that it has been disabled by management action (12.9.3).

10.7.5.13 Message reception events

For an instance of the Applicant state machine or the Registrar state machine, a message reception event is deemed to have occurred if an MRPDU (10.8) is received, and the following conditions are true:

a) The PDU was addressed to an MRP application (the MRP application address, Table 10-1, or MIRP address, 39.2.1.6) and had an Ethertype (Table 10-2) in accordance with that of the MRP application associated with the state machine.

b) The PDU contains a Message (10.8.1) in which the Attribute Type is the type associated with the state machine.

c) The Message contains a VectorAttribute (10.8.1.2) where the range defined by the FirstValue and NumberOfValues includes the attribute value associated with the state machine.

The specific type of message reception event is determined by the event value (10.8.2.5) associated with the state machine. The possible message reception event types are specified in 10.7.5.14 through 10.7.5.20.

10.7.5.14 rNew!

For an instance of the Applicant or Registrar state machine, a message reception event (10.7.5.13) occurs, and the event value (10.8.2.5) associated with the state machine specifies the New message.

10.7.5.15 rJoinIn!

For an instance of the Applicant or Registrar state machine, a message reception event (10.7.5.13) occurs, and the event value (10.8.2.5) associated with the state machine specifies the JoinIn message.

10.7.5.16 rJoinMt!

10.7.5.17 rLv!

For an instance of the Applicant or Registrar state machine, a message reception event (10.7.5.13) occurs, and the event value (10.8.2.5) associated with the state machine specifies the Lv message.

10.7.5.18 rIn!

For an instance of the Applicant or Registrar state machine, a message reception event (10.7.5.13) occurs, and the event value (10.8.2.5) associated with the state machine specifies the In message.

10.7.5.19 rMt!

For an instance of the Applicant or Registrar state machine, a message reception event (10.7.5.13) occurs, and the event value (10.8.2.5) associated with the state machine specifies the Mt message.

10.7.5.20 rLA!

For an instance of the Applicant state machine, the Registrar state machine, or the LeaveAll state machine, the rLA! event is deemed to have occurred if either

a) The LeaveAll state machine associated with that instance of the Applicant or Registrar state machine performs the sLA action (10.7.6.6); or

b) An MRPDU (10.8) is received, and the following conditions are true:

1) The PDU’s destination MAC address and EtherType are in accordance with the definition of the MRP application associated with the state machine.

2) The PDU contains a Message (10.8.1) in which the Attribute Type is the type associated with the state machine.

3) The Message contains a LeaveAllEvent (10.8.2.6) that carries the value LeaveAll.

NOTE—The LeaveAll state machine operates on a per-application (not per-Attribute Type) basis, but the LeaveAll message operates on a per-Attribute Type basis. Hence, when the LeaveAll state machine issues a LeaveAll, it must generate a LeaveAll Attribute for each Attribute Type supported by the application concerned.

10.7.5.21 leavetimer!

For an instance of the Registrar state machine, the leavetimer! event is deemed to have occurred when the leavetimer associated with that state machine expires.

10.7.5.22 leavealltimer!

For an instance of the LeaveAll state machine, the leavealltimer! event is deemed to have occurred either when the leavealltimer associated with that state machine expires or when a Flush! event (10.7.5.2) occurs for the Port and spanning tree instance associated with that state machine.

10.7.5.23 periodictimer!

For an instance of the PeriodicTransmission state machine, the periodictimer! event is deemed to have occurred when the periodictimer associated with that state machine expires.

10.7.6 Protocol Action definitions

10.7.6.1 MRPDU transmission actions

Unless stated otherwise in these action definitions, MRPDU transmission as a result of the operation of a state machine in a Bridge occurs only through the Port associated with that state machine. MRPDUs shall be transmitted using the destination MAC address and EtherType value defined by the MRP application associated with the state machine.

When the action specifies the transmission of attribute state information, an MRPDU, formatted as defined in 10.8.1, is transmitted so that

a) The PDU contains a Message (10.8.1.2) that carries an Attribute Type (10.8.2.2) that corresponds to the type of attribute associated with the state machine concerned.

b) The Message contains a VectorAttribute (10.8.2.10) in which the FirstValue (10.8.2.7) and NumberOfValues (10.8.2.8) defines a range of attribute values that includes the attribute value associated with the state machine.

c) The Vector (10.8.2.10) encodes an AttributeEvent value in the vector position corresponding to the attribute value for this state machine. The choice of AttributeEvent value is determined by the specific transmission action, as defined below.

In the case of LeaveAll transmission actions, the LeaveAll event value specified by the transmission action is encoded in the NumberOfValues field of the VectorAttribute.

10.7.6.2 sN

The AttributeEvent value New is encoded in the Vector as specified in 10.7.6.1.

10.7.6.3 sJ, [sJ]

If the Registrar state is IN, then the AttributeEvent value JoinIn is encoded in the Vector as specified in 10.7.6.1.

If the Registrar state is MT or LV, then the AttributeEvent value JoinMt is encoded in the Vector as specified in 10.7.6.1.

NOTE—The [sJ] variant indicates that the action is only necessary in cases where transmitting the value, rather than terminating a vector and starting a new one, makes for more optimal encoding; i.e., transmitting the value is not necessary for correct protocol operation.

10.7.6.4 sL

The AttributeEvent value Lv is encoded in the Vector as specified in 10.7.6.1.

10.7.6.5 s, [s]

If the Registrar state is IN, then the AttributeEvent value In is encoded in the Vector as specified in 10.7.6.1.

If the Registrar state is MT or LV, then the AttributeEvent value Mt is encoded in the Vector as specified in 10.7.6.1.

NOTE—In the [s] variant, this value is transmitted only if its inclusion makes for more optimal encoding; i.e., transmitting the value is not necessary for correct protocol operation.

10.7.6.6 sLA

The LeaveAll event value specified by the transmission action is encoded in the NumberOfValues field of the VectorAttribute as specified in 10.7.6.1.

The sLA action also gives rise to a rLA! event (10.7.5.20) against all instances of the Applicant state machine, or the Registrar state machine, associated with the MRP participant.

10.7.6.7 periodic

Causes a periodic! event (10.7.5.10) against all Applicant state machines associated with the participant.

10.7.6.8 Start leavetimer

Causes leavetimer to be started, in accordance with the definition of the timer in 10.7.4.2.

10.7.6.9 Stop leavetimer

Causes leavetimer to be stopped.

10.7.6.10 Start leavealltimer

Causes leavealltimer to be started, in accordance with the definition of the timer in 10.7.4.3.

10.7.6.11 Start periodictimer

Causes periodictimer to be started, in accordance with the definition of the timer in 10.7.4.4.

10.7.6.12 New

This action causes a MAD_Join.indication primitive to be issued to the MAD Service User, indicating the Attribute instance corresponding to the state machine concerned, with the new parameter set TRUE.

10.7.6.13 Join

10.7.6.14 Lv

This action causes a MAD_Leave.indication primitive to be issued to the MAD Service User, indicating the Attribute instance corresponding to the state machine concerned.

10.7.7 Applicant state machine

A full MRP Participant maintains a single instance of the Applicant state machine (Table 10-3) for each Attribute value for which the Participant needs to maintain state information.

Table 10-3—Applicant state table

<table><tr><td rowspan="2" colspan="2"></td><td colspan="12">STATE</td></tr><tr><td><eq>VO^{11,12}</eq></td><td><eq>VP^6</eq></td><td><eq>VN^{6,12}</eq></td><td><eq>AN^{6,12}</eq></td><td><eq>AA^6</eq></td><td><eq>QA^{12}</eq></td><td><eq>LA^6</eq></td><td><eq>AO^{3,11}</eq></td><td><eq>QO^{3,11}</eq></td><td><eq>AP^{3,6}</eq></td><td><eq>QP^3</eq></td><td><eq>LO^6</eq></td></tr><tr><td rowspan="13">EVENT</td><td>Begin!<eq>^{12}</eq></td><td>—</td><td>VO</td><td>VO</td><td>VO</td><td>VO</td><td>VO</td><td>VO</td><td>VO</td><td>VO</td><td>VO</td><td>VO</td><td>VO</td></tr><tr><td>New!<eq>^{12}</eq></td><td>VN</td><td>VN</td><td>—</td><td>—</td><td>VN</td><td>VN</td><td>VN</td><td>VN</td><td>VN</td><td>VN</td><td>VN</td><td>VN</td></tr><tr><td>Join!</td><td>VP</td><td>—</td><td>—</td><td>—</td><td>—</td><td>—</td><td>AA</td><td>AP</td><td>QP</td><td>—</td><td>—</td><td>VP</td></tr><tr><td>Lv!</td><td>—</td><td>VO</td><td>LA</td><td>LA</td><td>LA</td><td>LA</td><td>—</td><td>—</td><td>—</td><td>AO</td><td>QO</td><td>—</td></tr><tr><td>rNew!</td><td>—</td><td>—</td><td>—</td><td>—</td><td>—</td><td>—</td><td>—</td><td>—</td><td>—</td><td>—</td><td>—</td><td>—</td></tr><tr><td>rJoinIn!</td><td><eq>AO^4</eq></td><td><eq>AP^4</eq></td><td>—</td><td>—</td><td>QA</td><td>—</td><td>—</td><td>QO</td><td>—</td><td>QP</td><td>—</td><td>—</td></tr><tr><td>rIn!</td><td>—</td><td>—</td><td>—</td><td>—</td><td><eq>QA^5</eq></td><td>—</td><td>—</td><td>—</td><td>—</td><td>—</td><td>—</td><td>—</td></tr><tr><td>rJoinMt! || rMt!</td><td>—</td><td>—</td><td>—</td><td>—</td><td>—</td><td>AA</td><td>—</td><td>—</td><td>AO</td><td>—</td><td>AP</td><td>VO</td></tr><tr><td>rLv! || rLA! || Re-declare!</td><td><eq>LO^1</eq></td><td>—</td><td>—</td><td>VN</td><td><eq>VP^9</eq></td><td><eq>VP^9</eq></td><td><eq>—^{10}</eq></td><td><eq>LO^1</eq></td><td><eq>LO^1</eq></td><td>VP</td><td>VP</td><td>—</td></tr><tr><td>periodic!</td><td>—</td><td>—</td><td>—</td><td>—</td><td>—</td><td>AA</td><td>—</td><td>—</td><td>—</td><td>—</td><td>AP</td><td>—</td></tr><tr><td>tx!<eq>^{7,12}</eq></td><td>[s]—</td><td>sJ AA</td><td>sN AN</td><td><eq>sN QA^8</eq></td><td>sJ QA</td><td>[sJ]—</td><td>sL VO</td><td>[s]—</td><td>[s]—</td><td>sJ QA</td><td>[s]—</td><td>s VO</td></tr><tr><td>txLA!<eq>^{2}</eq></td><td>[s]LO</td><td>s AA</td><td>sN AN</td><td>sN QA</td><td>sJ QA</td><td>sJ—</td><td>[s]LO</td><td>[s]LO</td><td>[s]LO</td><td>sJ QA</td><td>sJ QA</td><td>[s]—</td></tr><tr><td>txLAF!<eq>^{2}</eq></td><td>LO</td><td>VP</td><td>VN</td><td>VN</td><td>VP</td><td>VP</td><td>LO</td><td>LO</td><td>LO</td><td>VP</td><td>VP</td><td>—</td></tr></table>

Notes to the table:

1 Applicant-Only participants exclude the LO state, and transition to VO.

2 These events do not occur for Applicant-Only participants.

3 Point-to-point subset participants exclude the AO, QO, AP, and QP states.

4 Ignored (no transition) if point-to-point subset or if operPointToPointMAC is TRUE.

5 Ignored (no transition) if operPointToPointMAC is FALSE. See MRP Design Notes below.

6 Request opportunity to transmit on entry to VN, AN, AA, LA, VP, AP, and LO states.

7 If the MRPDU is full and cannot convey a required message there is no change of state and an additional transmit opportunity is requested if that has not been done already.

8 QA if the Registrar is IN, and AA otherwise. See MRP Design Notes below.

MRP design notes:

5 On shared media the receipt of In does not confirm registration by all Participants, and the In could have been sent by an Applicant-Only participant.

8 Since New messages do not convey registrar state, a Leave could have been received without an Empty or JoinEmpty prompt being sent, the transition to AA guards against loss of that Leave by another Applicant.

9 The design accepts a small possibility of a continued registration (after rLv! if a Lv! occurs before a further Join is sent) in return for not accumulating many Active participants when Join!s and Lv!s are frequent. rLv! processing is deliberately not optimized for point-to-point.

10If a Leave has been received, the Registrar for the transmitting participant is very probably IN, as this Applicant has not yet sent a Leave, so the pending Leave is required. The small savings from avoiding transmission of Leaves pending on receipt of LeaveAlls does not merit distinguishing the rLv! and rLA! cases.

11The VO, AO, and QO states represent states where the attribute is neither being declared by the Participant nor being registered by any other station on the LAN. In implementations where dynamic creation and discarding of state machines is desirable, the state machine can be discarded when in any of these states, pending a future requirement to declare or register that attribute value.

12A New-Only Participant recognizes only the Begin!, New!, and tx! events, and ignores all others, so can only reach the VO, VN, AN, and QA states.

10.7.8 Registrar state machine

A full MRP Participant maintains a single instance of this state machine for each Attribute value that is currently registered, or that the Registrar state machine is in the process of deregistering.

NOTE—As with the Applicant, state information is conceptually maintained for all possible values of all Attribute types that are defined for a given application; however, in real implementations of MRP, it is likely that the range of possible Attribute values in some applications will preclude this, and the implementation will limit the state to those Attribute values in which the Participant has an immediate interest. In the case of simple devices that have no interest in what other Participants have registered, it may be appropriate for that device to ignore Registrar operation altogether.

The detailed operation of this state machine is described in Table 10-4.

Table 10-4—Registrar state table

<table><tr><td rowspan="2" colspan="2"></td><td colspan="3">STATE</td></tr><tr><td>IN</td><td>LV</td><td>MT</td></tr><tr><td rowspan="6">EVENT</td><td>Begin!</td><td>MT</td><td>MT</td><td>MT</td></tr><tr><td>rNew!</td><td>NewIN</td><td>NewStop leavetimerIN</td><td>NewIN</td></tr><tr><td>rJoinIn! ||rJoinMt!</td><td>IN</td><td>Stop leavetimerIN</td><td>JoinIN</td></tr><tr><td>rLv! ||rLA! ||txLA! ||Re-declare!</td><td>Start leavetimerLV</td><td>-x-</td><td>-x-</td></tr><tr><td>Flush!</td><td>LvMT</td><td>LvMT</td><td>MT</td></tr><tr><td>leavetimer!</td><td>-x-</td><td>LvMT</td><td>MT</td></tr></table>

10.7.9 LeaveAll state machine

A single LeaveAll state machine exists for each full MRP Participant. Leave All messages generated by this state machine also generate LeaveAll events against all the Applicant and Registrar state machines associated with that Participant and Port; hence, LeaveAll generation is treated by those state machines in the same way as reception of a LeaveAll message from an external source.

The detailed operation of this state machine is described in Table 10-5.

Table 10-5—LeaveAll state table

<table><tr><td rowspan="2" colspan="2"></td><td colspan="2">STATE</td></tr><tr><td><eq>Active^a</eq></td><td>Passive</td></tr><tr><td rowspan="4">EVENT</td><td>Begin!</td><td>Start leavealltimer Passive</td><td>Start leavealltimer Passive</td></tr><tr><td>tx!</td><td>sLA Passive</td><td>-x-</td></tr><tr><td>rLA!</td><td>Start leavealltimer Passive</td><td>Start leavealltimer Passive</td></tr><tr><td>leavealltimer!</td><td>Start leavealltimer Active</td><td>Start leavealltimer Active</td></tr></table>

a Request opportunity to transmit on entry to the Active state

10.7.10 PeriodicTransmission state machine

A single PeriodicTransmission state machine exists for each Port. Periodic Transmission events are generated on a regular basis, against all Applicant state machines that are associated with that Port.

The detailed operation of this state machine is described in Table 10-6.

Table 10-6—PeriodicTransmission state table

<table><tr><td rowspan="2" colspan="2"></td><td colspan="2">STATE</td></tr><tr><td>Active</td><td>Passive</td></tr><tr><td rowspan="4">EVENT</td><td>Begin!</td><td>Start periodictimer Active</td><td>Start periodictimer Active</td></tr><tr><td>periodicEnabled!</td><td>-x-</td><td>Start periodictimer Active</td></tr><tr><td>periodicDisabled!</td><td>Passive</td><td>-x-</td></tr><tr><td>periodictimer!</td><td>Start periodictimer periodic Active</td><td>-x-</td></tr></table>

10.7.11 Timer values

MRP correctness is not critically dependent on the values of protocol timers. However, the protocol operates more efficiently, and with less likelihood of unwanted deregistrations, if the following relationships are maintained between timer values used by peer Participants:

a) LeaveTime should be at least twice the maximum JoinTime, plus six times the timer resolution, to allow reregistration after a Leave or LeaveAll even if a message is lost.

b) To minimize the volume of rejoining traffic generated following a LeaveAll, the value chosen for LeaveAllTime should be large relative to LeaveTime.

The default timer values (Table 10-7) maintain these relationships. They may be modified on a per-Port basis by means of the management functionality defined in Clause 12.

Table 10-7—MRP timer parameter values

<table><tr><td>Parameter</td><td>Value (centiseconds)</td></tr><tr><td>JoinTime</td><td>20</td></tr><tr><td>LeaveTime</td><td>60–100</td></tr><tr><td>LeaveAllTime</td><td>1000</td></tr></table>

NOTE—The default values for the MRP timers are independent of media access method or data rate. This is a deliberate choice, made in the interests of maximizing the “plug and play” characteristics of the protocol.

Implementation of the timers for MRP shall be based on a timer resolution of 1 centisecond or less.

If operPointToPointMAC (IEEE Std 802.1AC) is TRUE, a request for a transmit opportunity should result in such an opportunity as soon as is practicable, given other system constraints, and shall occur within the value specified for JoinTime subject to not more than three such transmission opportunities occurring in any period of 1.5*JoinTime.

If operPointToPointMAC is FALSE, and there is no pending request, a transmit opportunity shall occur at a time value randomized between 0 and JoinTime seconds. These provisions shall apply even if a point-topoint subset Applicant has been implemented.

10.7.12 Operational reporting and statistics

10.7.12.1 Failure to register

Each MRP Participant maintains a count of the number of times that it has received a registration request, but has failed to register the attribute concerned due to lack of space in the FDB to record the registration. The value of this count may be examined by management (see 12.9.2.1.3).

NOTE—Further action to be taken on such events is a matter for implementation choice.

10.7.12.2 Peer tracking

An implementation may support the ability to record against each Registrar state machine the MAC address of the originator of the MRPDU that caused the most recent state change for that state machine (see 12.9.3.1.3).

10.7.13 Interoperability considerations

Correct operation of MRP for a given MRP application requires that protocol exchanges among a given set of communicating MRP Participants maintain sequentiality; i.e., that Participant A cannot receive MRPDU B (generated as a consequence of Participant B receiving MRPDU A) before Participant A has received MRPDU A. In circumstances where the Participants concerned are all attached to the same LAN, such sequentiality is ensured. However, if a set of MRP Participants communicates via an intervening Bridge that does not implement that MRP application (or does not implement MRP at all), the sequentiality constraints expressed in 8.6.6, 8.6.7, and 8.6.8 are insufficient to guarantee the correct operation of MRP. In order for the correct sequencing of PDUs to be maintained through such a Bridge, the following constraint must be met:

If MRPDU A is received on Port X, and is due to be forwarded on Ports Y and Z, and subsequent to being forwarded on Y, MRPDU B is received on Port Y for forwarding on Port Z, then forwarding of B cannot precede A on Port Z.

NOTE—This expresses a stronger sequencing constraint for multicast frames than is stated in 8.6, but a weaker constraint than was required for conformance to IEEE Std 802.1D, 1993 Edition [B8].

The consequence of failure to meet this constraint is that the users of a given MRP application may experience an increased incidence of loss of registration. Therefore, it is inadvisable to construct LAN configurations involving forwarding of MRPDUs through intervening Bridges if those Bridges do not meet the constraint expressed previously.

10.8 Structure and encoding of Multiple Registration Protocol Data Units (MRPDUs)

This subclause describes the generic structure and encoding of the MRPDUs exchanged between all MRP Participants. The structure and encoding of elements that are specific to the operation of the MRP applications are defined by the applications themselves.

Each MRPDU identifies the MRP application by which it was generated, and to which it is being transmitted. Bridges that receive MRPDUs identified as belonging to an MRP application that they do not support shall forward such PDUs on all other Ports that are in a Forwarding state.

NOTE 1—If MRP is used to support an application that can operate in any MAP Context other than 0 (the Base Spanning Tree Context), the application specification describes how that context is identified in protocol exchanges.

Each MRPDU carries one or more MRP messages, each of which identify one or more MRP events (e.g., Join, Leave, LeaveAll) and the attribute class(es) and value(s) to which each event applies. A given MRP Participant shall process MRPDUs in the order in which they are received, and shall process the MRP Messages in a PDU in the order in which they were put into the Data Link Service Data Unit (DLSDU).

NOTE 2—Any messages generated as a consequence of state machine responses to an sLA action and its associated LeaveAll events will be put into the DLSDU after the LeaveAll message(s), or into a later DLSDU.

10.8.1 Structure

10.8.1.1 Transmission and representation of octets

All MRPDUs consist of an integral number of octets, numbered starting from 1 and increasing in the order that they are put into a DLSDU. The bits in each octet are numbered from 1 to 8, where 1 is the low-order bit.

When consecutive octets are used to represent a binary number, the lower octet number has the most significant value.

When the encoding of (an element of) an MRPDU is represented using a diagram in this clause, the following representations are used:

a) Octet 1 is shown toward the top of the page, higher numbered octets being toward the bottom.

b) Where more than one octet appears on a given line, octets are shown with the lowest numbered octet to the left, higher numbered octets being to the right.

c) Within an octet, bits are shown with bit 8 to the left and bit 1 to the right.

10.8.1.2 Structure definition

MRP makes use of an EtherType value as the means of identifying the MRP application that has transmitted, and that will receive, a given MRPDU. Table 10-2 lists the set of MRP applications that are defined, and the EtherType values that correspond to them.

A protocol version field is included in the structure of the MRPDU, in order to provide the ability to identify future enhancements to MRP applications.

MRPDUs exchanged according to the protocol specified in this clause shall have the following structure:

a) The first octet contains the ProtocolVersion.

Following the Protocol Version are one or more Messages. The last element in the PDU is an EndMark.

c) Each Message consists of an AttributeType, an AttributeLength, and an AttributeList, in that order.

d) An Attribute List consists of one or more VectorAttributes. The last element in the AttributeList is an EndMark.

e) A VectorAttribute consists of a VectorHeader, a FirstValue, and a Vector, in that order. The VectorHeader is able to encode both a LeaveAllEvent and the number of attribute events encoded in the vector.

f) If the end of an MRPDU is encountered before an EndMark is reached, then processing of the PDU is terminated as if an EndMark had been reached.

The following Backus-Naur Form (BNF) productions give the formal description of the MRPDU structure:


  MRPDU ::= ProtocolVersion, Message {, Message}, EndMark
  ProtocolVersion BYTE ::= Defined by the specific MRP application
  Message ::= AttributeType, AttributeLength[, AttributeListLength], AttributeList
  AttributeType BYTE ::= Nonzero integer defined by the specific MRP application
  AttributeLength BYTE ::= Nonzero integer defined by the specific MRP application
  AttributeListLength SHORT ::= Nonzero integer defined by the specific MRP application
  AttributeList ::= VectorAttribute {, VectorAttribute}, EndMark
  VectorAttribute ::= VectorHeader, FirstValue {, Vector}
  VectorHeader SHORT ::= (LeaveAllEvent * 8192) + NumberOfValues
  FirstValue ::= Defined by the specific MRP application
  Vector ::= ThreePackedEvents {, ThreePackedEvents}
  [, FourPackedEvents {, FourPackedEvents}]
  ThreePackedEvents BYTE ::= (((((AttributeEvent) *6) + AttributeEvent) *6) + AttributeEvent)
  AttributeEvent BYTE ::= New | JoinIn | In | JoinMt | Mt | Lv
  FourPackedEvents BYTE ::= ((FourPackedType *64) + (FourPackedType *16)
  + (FourPackedType *4) + FourPackedType)
  FourPackedType BYTE ::= Integer defined by the specific MRP application
  LeaveAllEvent BYTE ::= NullLeaveAllEvent | LeaveAll
  NumberOfValues SHORT ::= Number of events encoded in the vector
  EndMark SHORT ::= 0x0000 | End of PDU
  NullLeaveAllEvent ::= 0
  LeaveAll ::= 1
  New ::= 0
  JoinIn ::= 1
  In ::= 2
  JoinMt ::= 3
  Mt ::= 4
  Lv ::= 5

The parameters carried in MRPDUs, as identified in this structure definition, shall be encoded as specified in 10.8.2.

Figure 10-5 illustrates the structure of the MRPDU and its components.

Octet #

<table><tr><td colspan="2">ProtocolVersion</td><td>Message 1</td><td>...</td><td>Message N</td><td>EndMark</td><td>MRPDU structure</td></tr><tr><td colspan="7">Octet #</td></tr><tr><td>1</td><td>2</td><td colspan="2">3</td><td>5</td><td>N</td><td></td></tr><tr><td colspan="2">AttributeType</td><td colspan="2">AttributeLength</td><td>AttributeListLength</td><td>AttributeList</td><td>Message structure</td></tr><tr><td colspan="7">Octet #</td></tr><tr><td colspan="5">1</td><td>N</td><td></td></tr><tr><td colspan="2">VectorAttribute 1</td><td>...</td><td>VectorAttribute N</td><td colspan="2">EndMark</td><td>Attribute List structure</td></tr><tr><td colspan="7">Octet #</td></tr><tr><td>1</td><td colspan="2">3</td><td>M</td><td colspan="2">N</td><td></td></tr><tr><td colspan="2">VectorHeader</td><td colspan="2">FirstValue</td><td colspan="2">Vector</td><td>VectorAttribute structure</td></tr><tr><td colspan="7">Octet #</td></tr><tr><td colspan="2">1</td><td colspan="5">2</td></tr><tr><td colspan="2">LeaveAllEvent</td><td colspan="4">NumberOfValues (13 bits)</td><td>VectorHeader structure</td></tr></table>

Figure 10-5—Format of the major components of an MRPDU

10.8.2 Encoding of MRPDU parameters

10.8.2.1 Encoding of ProtocolVersion

A ProtocolVersion shall be encoded in a single octet, taken to represent an unsigned binary number. It takes a value that is determined by the application concerned.

NOTE—The handling of protocol version information is defined in 10.8.3.5.

10.8.2.2 Encoding of AttributeType

An AttributeType shall be encoded as a single octet, taken to represent an unsigned binary number. The AttributeType identifies the type of Attribute to which the message applies. The range of values that can be taken by the AttributeType, and the meanings of those values, are defined by the application concerned. The value 0 is reserved, and shall not be used as an AttributeType by any MRP application. MRP applications may otherwise allocate meanings to any set of values of AttributeType in the range 1 through 255.

The definition of AttributeType values in the application associates the following with each AttributeType value defined:

a) The size, in octets, of attribute values, and how they are encoded.

b) Any restrictions that are placed upon the range of attribute values that the vector is permitted to represent.

10.8.2.3 Encoding of AttributeLength

An AttributeLength shall be encoded as a single octet, taken to represent an unsigned binary number. The AttributeLength indicates the length, in octets, of the FirstValue field (10.8.2.7) for the Attribute to which the message applies.

10.8.2.4 Encoding of AttributeListLength

An AttributeListLength shall be encoded as two octets, taken to represent an unsigned binary number. The AttributeListLength indicates the length, in octets, of the AttributeList field for the Attribute to which the message applies. This field is not present in all MRPDUs. Specifically, Multiple MAC Registration Protocol Data Units (MMRPDUs) and Multiple VLAN Registration Protocol Data Units (MVRPDUs) do not use this field, whereas Multiple Stream Protocol Data Units (MSRPDUs) do use this field.

10.8.2.5 Encoding of AttributeEvent

An AttributeEvent shall be encoded as an unsigned decimal number in the range 0 through 5. The permitted values and meanings of the AttributeEvent are as follows:

0: New operator

1: JoinIn operator

2: In operator

3: JoinMt operator

4: Mt operator

5: Lv operator

Further values of AttributeEvent are reserved.

The AttributeEvent is interpreted on receipt as a MAD event to be applied to the state machine for the Attribute defined by the AttributeType and AttributeValue to which the AttributeEvent relates.

10.8.2.6 Encoding of LeaveAllEvent

A LeaveAllEvent shall be encoded as an unsigned binary number. The permitted values and meanings of LeaveAllEvent are as follows:

0: NullLeaveAllEvent operator

1: LeaveAll operator

Further values of LeaveAllEvent are reserved.

The LeaveAllEvent is interpreted on receipt as a MAD Leave All event to be applied to the state machines for all Attributes of the type defined by the AttributeType field.

The value NullLeaveAllEvent signifies that there is no Leave All event to process, and is included purely for encoding efficiency in the vector attribute structures. Receipt of this value does not cause any event to be applied to any state machine.

10.8.2.7 Encoding of FirstValue

A FirstValue is encoded in N octets, taken to be an unsigned binary number, in accordance with the specification for the AttributeType defined by the MRP application concerned. The length, in octets, of the FirstValue field is specified by the value contained in the AttributeLength field (10.8.2.3). When NumberOfValues is greater than one (1) FirstValue is incremented in a way that is defined by each MRP application. For example MMRP simply increments FirstValue by adding the number one (1) to it, whereas MSRP adds one (1) to multiple fields within the FirstValue for each increment. Throughout this specification FirstValue incremented by one is denoted as FirstValue + 1, incrementing by two is denoted as FirstValue + 2, etc.

10.8.2.8 Encoding of VectorHeader

The VectorHeader is used to encode both the value of the LeaveAllEvent (10.8.2.6) and the NumberOfValues, the number of AttributeEvent values encoded in a Vector (10.8.2.10). The VectorHeader is taken to be an unsigned binary number, encoded in two octets, as follows:

a) The value of the LeaveAllEvent is multiplied by 8192.

b) The resulting number is added to NumberOfValues.

The range of values that NumberOfValues can take is restricted, such that the following are true:

c) The size of the Vector that is defined by this number will fit in the available space in the PDU.

d) Incrementing FirstValue the number of times specified in NumberOfValues does not exceed the permitted numeric range of FirstValue as defined for the application concerned.

e) The number of AttributeEvent values does not exceed 8191.

f) If the number of AttributeEvent values is zero, FirstValue is ignored and the value is skipped. However, FirstValue is still present, and of the correct length, in octets, as specified by the AttributeLength field (10.8.2.3) for the Attribute to which the message applies.

g) If LeaveAllEvent is a NullLeaveAllEvent, the number of AttributeEvent values is nonzero.

10.8.2.9 Encoding of EndMark

An EndMark shall be encoded as two octets, taken to represent an unsigned binary number. It takes the numeric value 0.

Further values of EndMark are reserved and shall not be used.

NOTE—As defined by the MRPDU structure definition in 10.8.1, if the end of the MRPDU is encountered, this is taken to be an End Mark from the point of view of processing the PDU contents.

10.8.2.10 Encoding of Vector

10.8.2.10.1 Encoding of Vector ThreePackedEvents

The Vector is encoded as zero or more 8-bit values, each containing a numeric value, ThreePackedEvents, derived from three packed numeric values, each of which represents an AttributeEvent, in the range 0 through 5.

As can be seen from the BNF definition of ThreePackedEvents, each 8-bit value is derived by successively adding an event value and multiplying the result by 6. In order to facilitate the subsequent description, the event values are numbered from first to third, as follows:

The NumberOfValues field in the VectorHeader of the VectorAttribute determines the number of 8-bit ThreePackedEvents values, E, that will be present in the vector; hence E is determined by dividing NumberOfValues by 3 and rounding any noninteger answer up to the nearest larger integer.

The FirstValue field of the VectorAttribute determines which of the originator’s state machines the first AttributeEvent value in the first ThreePackedEvents value relates to. The second AttributeEvent value in the first ThreePackedEvents value corresponds to the state machine identified by (FirstValue + 1), and the third AttributeEvent value in the first ThreePackedEvents value corresponds to the state machine identified by (FirstValue + 2), and so on, through subsequent packed values.

Where the NumberOfValues field carries a value that is not a multiple of 3, there will be either one or two AttributeEvent values packed in the final ThreePackedEvents that are ignored; these values are encoded as the numeric value 0 on transmission and are ignored on receipt.

NOTE—If NumberOfValues is zero, there will be no ThreePackedEvents encoded in the vector.

10.8.2.10.2 Encoding of Vector FourPackedEvents

The Vector is encoded as zero or more 8-bit values, each containing a numeric value, FourPackedEvents, derived from four packed numeric values, each of which represent a FourPackedType, in the range 0 through 3. The FourPackedTypes are defined by each MRP application that uses FourPackedEvents. Note that not all MRP applications use FourPackedEvents.

As can be seen from the BNF definition of FourPackedEvents, each 8-bit value is derived by successively adding a FourPackedType value and multiplying the result by 4. In order to facilitate the subsequent description, the event values are numbered from first to fourth, as follows:

\text { FourPackedEvents BYTE } := ((\text { firstFourPackedType } * 6 4) + (\text { secondFourPackedType } * 1 6) + (\text { thirdFourPackedType } * 4) + (\text { fourthFourPackedType }))

The NumberOfValues field in the VectorHeader of the VectorAttribute determines the number of 8-bit FourPackedEvents values, E, that will be present in the vector; hence E is determined by dividing NumberOfValues by 4 and rounding any noninteger answer up to the nearest larger integer.

The FirstValue field of the VectorAttribute determines which of the originator’s state machines the first FourPackedType value in the first FourPackedEvents value relates to. The second FourPackedType value in the first FourPackedEvents value corresponds to the state machine identified by (FirstValue + 1). The third FourPackedType value in the first FourPackedEvents value corresponds to the state machine identified by (FirstValue + 2), and the fourth FourPackedType value in the first FourPackedEvents value corresponds to the state machine identified by (FirstValue + 3), and so on, through subsequent packed values.

Where the NumberOfValues field carries a value that is not a multiple of 4, there will be one, two or three FourPackedType values packed in the final FourPackedEvent that are ignored; these values are encoded as the numeric value 0 on transmission and are ignored on receipt.

NOTE— If NumberOfValues is zero, there will be no FourPackedEvents encoded in the vector.

10.8.3 Packing and parsing MRPDUs

The use of the End Mark (10.8.2.9) to signal the end of an AttributeList and the end of an MRPDU, and the fact that the (physical) end of the PDU is interpreted as an End Mark, simplifies the requirements both for packing information into MRPDUs and for correctly interpreting that information on receipt.

10.8.3.1 Packing

Successive Messages are packed into the MRPDU, and within each Message, successive VectorAttributes are packed into each Message, until the end of the PDU is encountered or there are no more VectorAttributes to pack at that time. The following cases can occur:

a) The PDU has sufficient room for all the VectorAttributes that require to be transmitted at that time to be packed. In this case, the PDU is transmitted, and subsequent PDUs are transmitted when there are further VectorAttributes to transmit.

b) The PDU has enough room for the first N VectorAttributes that require to be transmitted at that time to be packed. In this case, the PDU is transmitted, and the next N VectorAttributes are encoded in a subsequent PDU.

10.8.3.2 Handling of received MRPDUs

Received MRPDUs, i.e., PDUs that are constructed in accordance with the MRPDU format defined in 10.8, that carry a destination MAC address and MRP EtherType value as specified for use by a defined MRP application, are processed as follows:

a) In Bridges and end stations that support the operation of the MRP application concerned, all such PDUs shall be submitted to the MRP Participant associated with the reception Port for further processing.

b) In Bridges that do not support the operation of the MRP application concerned, all such PDUs shall be submitted to the Forwarding Process.

10.8.3.3 Discarding badly formed MRPDUs

An MRP Participant that receives an MRPDU shall discard that PDU if the PDU is not formatted according to the MRPDU format defined in 10.8.

10.8.3.4 Parsing

Successive Messages, and within each Message, successive VectorAttributes, are unpacked from the PDU. If this process terminates because the end of the PDU is reached, then the end of the PDU is taken to signal termination both of the current AttributeList and the overall PDU. The following two cases can occur:

a) The last VectorAttribute to be unpacked was complete. In this case, the VectorAttribute is processed normally, and processing of the PDU terminates.

b) The last VectorAttribute to be unpacked was incomplete. In this case, the entire PDU is discarded, and processing of the PDU terminates.

10.8.3.5 Handling of protocol versions

In order to ensure compatibility with previous protocol versions, while allowing the protocol to be extended in the future, the following requirements shall be met by the implementation:

a) MRPDUs that carry a protocol version lower than the protocol version implemented shall be interpreted according to the definition corresponding to the protocol version carried in the PDU.

b) MRPDUs that carry a protocol version equal to or higher than the protocol version implemented shall be interpreted according to the definition corresponding to the protocol version implemented.

c) Where the MRPDU carries a higher protocol version than the version implemented, then

1) If a Message is encountered in which the AttributeType is not recognized, then that Message is discarded. This is achieved by discarding the successive VectorAttributes in the AttributeList until either an EndMark or the end of the PDU is reached. If an EndMark is reached, processing continues with the next Message.

2) If a VectorAttribute is encountered in which the AttributeEvent is not recognized for the AttributeType concerned, then the VectorAttribute is discarded and processing continues with the next VectorAttribute, if the end of the PDU has not been reached.

10.9 Multiple MAC Registration Protocol (MMRP)—Purpose

MMRP provides a mechanism that allows end stations and MAC Bridges to dynamically register (and subsequently, deregister) Group membership or individual MAC address information with the Bridges attached to the same LAN, and disseminates that information across all the Bridges that support Extended Filtering Services in the Bridged Network. The operation of MMRP relies upon the services provided by MRP.

The information registered, deregistered, and disseminated via MMRP can appear in any of the following forms:

a) Group membership information. This indicates the presence of MMRP participants that are members of a particular Group (or Groups), and carries the group MAC address(es) associated with the Group(s). The exchange of specific Group membership information can result in the creation or updating of MAC Address Registration Entries in the FDB to indicate the Port(s) and VID(s) of the VLAN(s) on which members of the Group(s) have been registered. The structure of these entries is described in 8.8.4.

b) Group service requirement information. This indicates that one or more MMRP participants require Forward All Groups or Forward Unregistered Groups to be the default Group filtering behavior (see 6.16.7 and 8.8.6).

c) Individual MAC address information.

Registration of Group membership information makes Bridges aware that frames destined for the group MAC address concerned should only be forwarded in the direction of the registered members of the Group. Therefore, forwarding of frames destined for the address associated with that Group occurs only on Ports on which such membership registration has been received.

Registration of Group service requirement information makes the Bridges aware that Ports that can forward frames in the direction from which the information has been received should modify their default Group forwarding behavior in accordance with the service requirement expressed.

NOTE 1—Modification of default Group forwarding behavior allows Bridge Ports to accommodate MMRP-unaware devices in the Bridged Network by forwarding frames destined for unregistered group MAC addresses.

The operation of MMRP can result in

d) The propagation of Group membership information and Group service requirement information, and consequent creation, updating, or deletion of MAC Address Registration Entries in the FDBs of all Bridges in the network that support Extended Filtering Services.

e) Consequent changes to the Group filtering behavior of such Bridges.

In VLAN Bridges, MMRP operates only when the Bridge Filtering Mode is set to Extended Filtering Mode. Bridges that are unable to operate in Extended Filtering Mode, or have been set to operate in Basic Filtering Mode, are transparent with respect to MMRP exchanges, and forward any MRPDUs destined for the MMRP application through all Ports that are in Forwarding.

NOTE 2—An MMRP user is not prevented from registering an individual MAC address associated with a location different from its actual location. Such registration could result in denial of service to the station associated with that MAC address and, possibly, the interception of associated traffic by an unintended recipient. Such consequences of the misuse of individual MAC address registration can be prevented by using MMRP individual MAC address registration only in secure network environments (i.e., only in networks providing perimeter security).

10.10 Model of operation

MMRP defines an MRP application that provides the extended filtering services defined in 6.16.5 and 6.16.7. To this end, MMRP makes use of

a) The declaration and propagation services offered by MRP Attribute Declaration (MAD; 10.2 and 10.3,) and MRP Attribute Propagation (MAP; 10.2 and 10.3) to declare and propagate Group membership, Group service requirement, and individual MAC address information within the Bridged Network.

b) The registration services offered by MAD (10.2 and 10.3) to allow Group membership, Group service requirement, and individual MAC address information to control the frame filtering behavior of participating devices.

Figure 10-6 illustrates the architecture of MMRP in the case of a two-Port Bridge and an end station, for a given VLAN Context. Where MMRP is used in multiple VLAN Contexts, an instance of the MMRP Participant exists for each VLAN context.

!image

Figure 10-6—Operation of MMRP for a single VLAN Context

As shown in the diagram, the MMRP Participant consists of the following components:

c) The MMRP application, described in 10.12

d) MRP Attribute Propagation (MAP), described in 10.3

e) MRP Attribute Declaration (MAD), described in 10.2

10.10.1 Propagation of Group Membership information

The Forwarding Process uses the MAC Address Registration entries in the FDBs to ensure that frames are transmitted only through those Bridge Ports necessary to reach LANs to which Group members are attached. Figure 10-7 illustrates the MAC Address Registration Entries created by MMRP for a single Group.

!image

Figure 10-7—Example Directed Graph

By receiving frames from all Ports and forwarding only through Ports for which MMRP has created MAC Address Registration Entries, Bridges facilitate Group distribution mechanisms based on the concept of an Open Host Group. Any MMRP Participants (10.2) that wish to receive frames transmitted to a particular Group or Groups request membership of the Group(s) concerned. Any MAC Service user that wishes to send frames to a particular Group can do so from any point of attachment to the Bridged Network. These frames can be received on all LANs to which registered MMRP Participants are attached, but the filtering applied by Bridges ensures that frames are not transmitted on LANs that are not part of the active topology between the sources of the frames and the registered Group members. MMRP and the MAC Address Registration Entries thus restrict the frames to pruned subsets of the overall loop-free active topology.

NOTE—The term “Open Host Group” comes from the terminology introduced in the definition of the Internet Group Membership Protocol (IGMP) defined by the IETF.

MAC Service users that are sources of MAC frames destined for the Group do not have to register as members of the Group themselves unless they also wish to receive frames transmitted to the Group address by other sources.

10.10.2 Propagation of Group service requirement information

MMRP propagates Group service requirement information in the same manner as for Group registration information. If any Port in a given Bridge has a registered Group service requirement of All Groups or All Unregistered Groups (expressed in terms of the control information in Static Filtering Entries and/or MAC Address Registration Entries with a MAC address specification of All Groups or All Unregistered Groups), this fact is propagated on all other Ports of the Bridge, resulting in the registration of that information on Ports of adjacent Bridges. As a consequence of that registration, the default Group filtering behavior of those Ports can change in order to maintain compatibility with the service requirements expressed by the registered information, as defined in 8.8.6. This ensures that connectivity can be maintained in LANs where the service requirements of different regions of the Bridged Network differ.

NOTE—In a Bridged Network where the default Group filtering behavior is not the same for all “edge” Ports, service requirement propagation will tend to result in all “backbone” Ports switching to the highest precedence Group filtering behavior in use in the network. The precedence rules are defined in 8.8.6.

10.10.3 Source pruning

As described in 10.10.1, the operation of MMRP defines a subtree of the spanning tree as a result of the creation of MAC Address Registration Entries in the FDBs of the Bridges. End stations are also able to make use of the Group Membership information registered via MMRP to allow them to keep track of the set of Groups for which active members currently exist and the service requirements of upstream devices. This allows end stations that are sources of frames destined for a Group to suppress the transmission of such frames, if their registered Group membership and Group service requirement information indicates that there are no valid recipients of those frames reachable via the LANs to which they are attached.

NOTE—In effect, for the purposes of frame transmission, the end station can be viewed as if it operates as a single Port Bridge, with its own default Group filtering behavior and FDB entries updated via MMRP that tell it whether multicast frames that it has generated should be forwarded onto the attached LAN. In order to achieve this, it is necessary for the end station to implement both the Registrar and the Applicant functionality of MRP, as described in 10.6, 10.7.7, and 10.7.8. The Applicant-Only and Simple-Applicant Participants described in 10.6 do not contain the Registrar functionality that would be required for source pruning.

This end system behavior is known as source pruning. Source pruning allows MAC Service users that are sources of MAC frames destined for a number of Groups, such as server stations or routers, to avoid unnecessary flooding of traffic on their local LANs in circumstances where there are no current Group members in the network that wish to receive such traffic.

10.10.4 Use of Group service requirement registration by end stations

The ability to propagate Group service requirement information is described in this standard primarily as a means of propagating the requirements of the Bridges themselves. However, this mechanism can also be used by end stations that have requirements involving some aspect of promiscuous reception, such as Routers or network monitors. A MMRP-aware end station wishing to receive all multicast traffic can declare membership of All Groups on the LAN to which it is attached; similarly, an end station that wishes to receive unregistered multicast traffic can do so by declaring membership of All Unregistered Groups.

10.11 Default Group filtering behavior and MMRP propagation

The propagation of MMRP registrations within a VLAN Context has implications with respect to the choice of default Group filtering behavior within a Bridged Network. As MMRP frames are transmitted only on outbound Ports that are in the Member set (8.8.10) for the VID concerned, propagation of Group registrations by a given Bridge occurs only toward regions of the Bridged Network where that VID has been (statically or dynamically) registered. This is illustrated in Figure 10-8; dotted lines in the diagram show those regions of the Bridged Network where propagation of registrations for Group M for VID V does not occur. Consequently, the FDBs of the lower two Bridges will not contain any Dynamic MAC Address Registration Entry for Group M for VID V.

!image

Filtering Database Bridge

M Applicant station that is a member of Group M in VLAN Context V

Applicant station that is not a member of Group M

S End station transmitting frames to Group M with VID V

Regions of the LAN where registrations for Group M in VLAN Context V are not propagated

Figure 10-8—Example of MMRP propagation in a VLAN Context

The action of these two Bridges on receipt of frames, on either of their lower Ports, destined for Group M and VID V, will depend upon the Default Group Filtering Behavior adopted by their upper Ports, which are the Ports that are in the Member set for VID V. If the Default Group Filtering Behavior is either Forward All Groups or Forward Unregistered Groups, then these Bridges will forward the frames. If the Default Group Filtering Behavior is Filter Unregistered Groups, then these Bridges will filter the frames. In the scenario shown, the choice of Default Group Filtering Behavior is therefore crucial with respect to whether end station S, or any other station that is “outside” the VLAN, is able to send frames to members of the Group. The choice between Filter Unregistered Groups and the other default behaviors therefore has the effect of defining VLANs that are closed to external unregistered traffic (Filter Unregistered Groups) or open to external unregistered traffic (either of the other default behaviors).

10.12 Definition of the MMRP application

10.12.1 Definition of MRP elements

10.12.1.1 Use of MAP Contexts by MMRP

MMRP operates within a MAP Context, or set of MAP Contexts, that is determined by the type of Bridge component supporting the MMRP application. In a MAC Bridge component MMRP operates in the Base Spanning Tree Context. In a C-VLAN component or S-VLAN component MMRP operates in the set of C-VLAN Contexts or S-VLAN Contexts, respectively, that corresponds to the VIDs that are supported by the Virtual Bridged Network.

The MAP Context Identifier used to identify a VLAN Context shall be equal to the VID used to identify the corresponding VLAN.

The set of Ports of a Bridge defined to be part of the active topology for a given VLAN Context shall be equal to the set of Ports of a Bridge for which the following are true:

a) The Port is a member of the Member set (8.8.10) for that VID; and

b) The Port is one of the Ports of the Bridge that are part of the active topology for the spanning tree that supports that VID.

NOTE—The above definition applies equally to SST and MST environments. It ensures that MMRP operates in either environment, without the MMRP implementations needing to be aware of whether the VLAN Contexts that apply are all supported by the same spanning tree, as in the SST environment, or are potentially distributed across two or more spanning trees, as in the MST environment.

VLAN Contexts can be hierarchical. For example, in a PBN that forwards C-VLAN-tagged frames between CBNs, there can be multiple C-VLAN Contexts within each S-VLAN context. Likewise, there can be multiple C-VLAN Contexts and/or S-VLAN Contexts within the Base Spanning Tree Context. While it is theoretically possible for an MMRP application to support hierarchical MAP Contexts by maintaining an MMRP Participant for each possible (or at least anticipated) combination of C-VLAN, S-VLAN and Base Spanning Tree MAP Contexts, an MMRP application is not required to support hierarchical MAP Contexts. The identification of MMRPDUs belonging to a hierarchical MAP Context, and the treatment of such MMRPDUs, is discussed in 10.12.1.2.

10.12.1.2 Context identification in MMRP

In a MAC Bridge component, received MMRPDUs that are untagged are identified with the Base Spanning Tree Context and are directed to the MRP Participant for the Base Spanning Tree. Received MMRPDUs that are VLAN-tagged identify hierarchical MAP Contexts. If the MMRP application does not support hierarchical MAP Contexts (i.e., maintain an MRP Participant for each possible S-VLAN and/or C-VLAN Context within the Base Spanning Tree Context), then the received MMRPDUs are not directed to any MRP Participant and are transmitted, including the original VLAN tag(s), on each port in the Base Spanning Tree Context except the reception port.

Implementations of MMRP in VLAN Bridges apply the same ingress rules (8.6.2) to received MMRPDUs that are defined for the reception Port. Therefore,

a) MMRP frames with no VLAN classification (i.e., untagged or priority-tagged MMRPDUs) are discarded if the Acceptable Frame Types parameter (6.9) for the Port is set to Admit Only VLANtagged frames. Otherwise, they are classified either according to the PVID for the Port, or as determined by protocol-based VLAN classification (6.12) if that capability is implemented.

b) VLAN-tagged MMRP frames are classified according to the VID carried in the tag header, optionally translated using the VID translation table (6.9).

c) If Ingress Filtering (8.6.2) is enabled, and if the Port is not in the Member set (8.8.10) for the MMRP frame’s VLAN classification, then the frame is discarded.

The VLAN classification thus associated with a received MMRP frame establishes the C-VLAN Context or S-VLAN Context for the received PDU, depending on whether the reception port is on a C-VLAN component or S-VLAN component, and identifies the MRP Participant instance to which the PDU is directed. MMRPDUs received at an S-VLAN component and containing a C-TAG, either alone or within an S-TAG, identify hierarchical MAP Contexts. If the MMRP application does not support hierarchical MAP Contexts (i.e., maintain an MRP Participant for each possible C-VLAN Context within each S-VLAN Context), then the received MMRPDUs are not directed to any MRP Participant and are transmitted, including the original C-TAG, on each port in the S-VLAN Context except the reception port.

MMRPDUs transmitted by MMRP Participants are VLAN classified according to the VLAN Context associated with that Participant. MMRP Participants in VLAN Bridges apply the same egress rules that are defined for the transmission Port (8.6.4). Therefore

d) MMRPDUs are transmitted through a given Port only if the Member Set for the VID concerned indicates that the VID is registered on that Port.

e) MMRPDUs are transmitted through a given Port as VLAN-tagged frames or as untagged frames in accordance with the state of the Untagged Set (8.8.10) for that Port and for the VID concerned.

Where VLAN-tagged frames are transmitted, the VID field of the tag header carries the VLAN Context Identifier value, optionally translated using the VID translation table (6.9).

10.12.1.3 MMRP application address

The group MAC address used as the destination address for MRPDUs destined for MMRP Participants shall be the group MAC address identified in Table 10-1 as “Customer and Provider Bridge MMRP address.”

10.12.1.4 MMRP application EtherType

The EtherType used for MRPDUs destined for MMRP Participants shall be the MMRP EtherType identified in Table 10-2.

10.12.1.5 MMRP ProtocolVersion

The ProtocolVersion for the version of MMRP defined in this standard takes the hexadecimal value 0x00.

10.12.1.6 MMRP AttributeType definitions

MMRP defines two AttributeTypes (10.8.2.2) that are carried in MRP exchanges, as follows:

a) The Service Requirement Vector Attribute Type.

b) The MAC Vector Attribute Type.

Attributes identified by the Service Requirement Vector Attribute Type are instances of VectorAttributes (10.8.1), used to identify values of Group service requirements. The value of AttributeType used to identify the Service Requirement Vector Attribute Type in MRPDUs (10.8.2.2) shall be 1.

Attributes identified by the MAC Vector Attribute Type are instances of VectorAttributes (10.8.1), used to identify a sequence of values of MAC addresses. The value of AttributeType used to identify the MAC Vector Attribute Type in MRPDUs (10.8.2.2) shall be 2.

10.12.1.7 MMRP FirstValue definitions

The FirstValue field (10.8.2.7) in instances of the MAC Vector Attribute Type shall be encoded in MRPDUs as six octets, each taken to represent an unsigned binary number. The octets are derived from the Hexadecimal Representation of an EUI-48 MAC Address (defined in IEEE Std 802) as follows:

a) Each two-digit hexadecimal numeral in the Hexadecimal Representation is taken to represent an unsigned hexadecimal value, in the normal way, i.e., the rightmost digit of each numeral represents the least significant digit of the value, the leftmost digit is the most significant.

b) The first octet of the attribute value encoding is derived from the left-most hexadecimal value in the Hexadecimal Representation of the MAC address. The LSB of the octet (bit 1) is assigned the LSB of the hexadecimal value, the second significant bit is assigned the value of the second significant bit of the hexadecimal value, and so on.

c) The second through sixth octets of the encoding are similarly assigned the value of the second through sixth hexadecimal values in the Hexadecimal Representation of the MAC address.

FirstValue+1 is defined as adding 1 to FirstValue. There are no restrictions on the range of values that can be represented in this data type.

The FirstValue field in instances of the Service Requirement Attribute Type shall be encoded in MRPDUs (10.8.2.7) as a single octet, taken to represent an unsigned binary number. Only two values of this type are defined:

d) All Groups shall be encoded as the value 0.

e) All Unregistered Groups shall be encoded as the value 1.

The remaining possible values (2 through 255) are reserved.

10.12.1.8 MMRP AttributeLength definitions

The AttributeLength field (10.8.2.3) in instances of the MAC Vector Attribute Type shall be encoded in MRPDUs (10.8) as an unsigned binary number, equal to the value 0x06.

The AttributeLength field (10.8.2.3) in instances of the Service Requirement Vector Attribute Type shall be encoded in MRPDUs (10.8) as an unsigned binary number, equal to the value 0x01.

10.12.1.9 MMRP AttributeListLength definitions

The AttributeListLength field (10.8.2.4) is not present in the MMRPDUs.

10.12.1.10 MMRP Vector definitions

The ThreePackedEvent vectors are encoded as defined in 10.8.2.10.1.

The FourPackedEvent vectors (10.8.2.10.2) are not present in the MMRPDUs.

10.12.2 Provision and support of Extended Filtering Services

10.12.2.1 Initiating MMRP registration and deregistration

The MMRP application element of an MRP Participant provides the dynamic registration and deregistration services defined in 6.16.7.1, as follows:

On receipt of a REGISTER_MAC_ADDRESS service primitive, the MMRP Participant issues a MAD_Join.request. The attribute_type parameter of the request carries the value of the MAC Vector Attribute Type (10.12.1.6) and the attribute_value parameter carries the value of the MAC_ADDRESS parameter of the service primitive.

On receipt of a DEREGISTER_MAC_ADDRESS service primitive, the MMRP Participant issues a MAD_Leave.request. The attribute_type parameter of the request carries the value of the MAC Vector Attribute Type (10.12.1.6) and the attribute_value parameter carries the value of the MAC_ADDRESS parameter of the service primitive.

On receipt of a REGISTER_SERVICE_REQUIREMENT service primitive, the MMRP Participant issues a MAD_Join.request. The attribute_type parameter of the request carries the value of the Service Requirement Vector Attribute Type (10.12.1.6) and the attribute_value parameter carries the value of the REQUIREMENT_SPECIFICATION parameter of the service primitive.

On receipt of a DEREGISTER_SERVICE_REQUIREMENT service primitive, the MMRP Participant issues a MAD_Leave.request. The attribute_type parameter of the request carries the value of the Service Requirement Vector Attribute Type (10.12.1.6) and the attribute_value parameter carries the value of the REQUIREMENT_SPECIFICATION parameter of the service primitive.

NOTE—If the EISS is supported, the Extended Filtering service primitives issued by the MAC Service user should include a VID parameter in addition to the MAC_ADDRESS or REQUIREMENT_SPECIFICATION parameters, in order to identify the MMRP Participant associated with the primitive.

10.12.2.2 Registration and deregistration events

The MMRP application element of an MRP Participant responds to registration and deregistration events signaled by MAD as follows:

On receipt of a MAD_Join.indication, the MMRP application element specifies the Port associated with the MMRP Participant as Forwarding in the Port Map field of the MAC Address Registration Entry (8.8.4) for the MAC address specification carried in the attribute_value parameter and the VID associated with the MAP Context. If such a MAC Address Registration Entry does not exist in the FDB, a new MAC Address Registration Entry is created.

Creation of new MAC Address Registration Entries may be restricted by the Restricted_MAC_Address_Registration control (10.12.2.3). If this control is TRUE, creation of a new dynamic entry is permitted only if there is a Static Filtering Entry for the MAC address with a Registrar Administrative Control value of Normal Registration.

NOTE—Group Membership and Group service requirement information can be recorded in the FDB by means of MAC Address Registration Entries (see 8.8.4). In the case of Group Membership Information, the MAC address specification in the MAC Address Registration Entry is a group MAC address. In the case of Group service requirement information, the MAC address specification is either “All Group Addresses” or “All Unregistered Group Addresses.”

On receipt of a MAD_Leave.indication, the MMRP application element specifies the Port associated with the MMRP Participant as Filtering in the Port Map field of the MAC Address Registration Entry (8.8.4) for the MAC address specification carried in the attribute_value parameter and the VID associated with the MAP Context. If such an FDB entry does not exist in the FDB, then the indication is ignored. If setting that Port to Filtering results in there being no Ports in the Port Map specified as Forwarding (i.e., all MMRP members are deregistered), then that MAC Address Registration Entry is removed from the FDB.

10.12.2.3 Administrative controls

The provision of static control over the registration state of the state machines associated with the MMRP application is achieved by means of the Registrar Administrative Control parameters associated with the operation of MRP (10.7.2). These parameters are represented in the FDB by the information held in Static Filtering Entries (8.8.1). If no Static Filtering Entry exists for a given MAC address specification, the value of the Registrar Administrative Control parameter for the corresponding attribute value is Normal Registration for all Ports of the Bridge.

The initial state of the Permanent Database (i.e., the state of the Permanent Database in a Bridge that has not been otherwise configured by management action) includes a Static Filtering Entry with a MAC address specification of All Groups, in which the Port Map indicates Registration Fixed (New ignored). This Static Filtering Entry will have the effect of determining the default Group filtering behavior of all Ports of the Bridge to be Forward All Groups. This Permanent Database entry may be deleted or updated by management action..

NOTE—This specification of an initial Static Filtering Entry means that operation using Forward Unregistered Groups or Filter Unregistered Groups requires a conscious action on the part of the network manager or administrator.

Where management capability is implemented, the Registrar Administrative Control parameters can be applied and modified by means of the management functionality defined in 12.7.

The provision of static control over the ability of Applicant state machines to participate in protocol exchanges is achieved by means of the Applicant Administrative Control parameters associated with the operation of MRP (10.7.3). Where management capability is implemented, the Applicant Administrative Control parameters can be applied and modified by means of the management functionality defined in Clause 12.

Further administrative control over dynamic MAC address registration may be achieved, if supported, by means of a per-Port Restricted_MAC_Address_Registration control parameter. If the value of this control is TRUE for a given Port, the creation or modification of Dynamic MAC Address Registration Entries as a result of MMRP exchanges on that Port shall be restricted only to those MAC addresses for which Static Filtering Entries exist in which the Registrar Administrative Control value is Normal Registration. If the value of the Restricted_MAC_Address_Registration control is FALSE, dynamic MAC address registration is not so restricted. Where management capability is implemented, the value of the Restricted_MAC_Address_Registration control can be manipulated by means of the management functionality defined in Clause 12. If management of this parameter is not supported, the value of this parameter shall be FALSE for all Ports.

10.12.3 Use of “new” declaration capability

MMRP does not make use of the “new” declaration capability.

10.12.4 Attribute value support requirements

Implementations of MMRP shall maintain state information for all attribute values that support the Group service requirement registration (10.12.1.7).

Implementations of MMRP shall be capable of supporting any attribute value in the range of possible values that can be registered using Group membership and individual MAC address registration (10.12.1.7); however, the maximum number of attribute values for which the implementation is able to maintain current state information is an implementation decision. The number of values that the implementation can support shall be stated in the PICS.

10.12.5 Registrar Administrative Controls

MMRP supports the Registration Fixed (New ignored) value, but not the Registration Fixed (New propagated) value, of the Registrar Administrative Controls (10.7.2)

11 VLAN topology management

The egress rules (8.6.4) defined for the Forwarding Process in VLAN Bridges rely on the existence of configuration information for each VID that defines the set of Ports of the Bridge through which one or more members are reachable. This set of Ports is known as the Member Set (8.8.10), and its membership is determined by the presence or absence of configuration information in the FDB, in the form of Static and Dynamic VLAN Registration Entries (8.8.2, 8.8.5).

Reliable operation of the VLAN infrastructure requires VLAN membership information held in the FDB to be maintained in a consistent manner across all VLAN Bridges in the Virtual Bridged Network, in order to ensure that frames destined for end station(s) on a given VLAN can be correctly delivered, regardless of where in the Bridged Network the frame is generated. Maintenance of this information by end stations that are sources of VLAN-tagged frames can allow such stations to suppress transmission of such frames if no members exist for the VLAN concerned.

This standard defines the following mechanisms that allow VLAN membership information to be configured:

a) Dynamic configuration and distribution of VLAN membership information by means of the MVRP, as described in 11.2.

b) Static configuration of VLAN membership information via Management mechanisms, as described in Clause 12, which allow configuration of Static VLAN Registration Entries.

These mechanisms provide for the configuration of VLAN membership information as a result of the following:

c) Dynamic registration actions taken by end stations or Bridges in the Bridged Network.

d) Administrative actions.

11.1 Static and dynamic VLAN configuration

The combined functionality provided by the ability to configure Static VLAN Registration Entries in the FDB, coupled with the use of the Restricted_VLAN_Registration control (11.2.3.2.3) and the ability of MVRP to dynamically create and update Dynamic VLAN Registration Entries, offers the following possibilities with respect to how VIDs are configured on a given Port:

a) Static configuration only. The management facilities described in Clause 12 are used to establish precisely which VIDs have this Port in their Member set, and the MVRP management controls are used to disable the operation of MVRP on that Port. Hence, any use of MVRP by devices reachable via that Port is ignored, and the Member set for all VIDs can therefore only be determined by means of static entries in the FDB.

b) Static configuration with topology changes. The management facilities described in Clause 12 are used to establish precisely which VLANs have this Port in their Member set, and the MVRP or MIRP management controls are used to permit the signaling, via MVRP or MIRP, of network topology changes that require flushing learned address information from the FDB. MVRPDUs and MIRPDUs received from devices reachable via that Port are ignored for the purposes of creating or deleting Dynamic VLAN Registration Entries in the FDB on that Port, and the Member set for all VLANs can therefore only be determined by means of static entries in the FDB.

c) Dynamic configuration only. The operation of MVRP is relied upon to establish Dynamic VLAN Registration Entries that will dynamically reflect which VIDs are registered on the Port, their contents changing as the configuration of the network changes. The MVRP management controls are set to enable the operation of MVRP on that Port.

d) Combined static and dynamic configuration. The static configuration mechanisms are used in order to configure some VLAN membership information; for other VIDs, MVRP is relied upon to establish the configuration. The MVRP management controls are set to enable the operation of MVRP on that Port.

All of the previous approaches are supported by the mechanisms defined in this standard, and each approach is applicable in different circumstances. For example:

e) Use of static configuration may be appropriate on Ports where the configuration of the attached devices is fixed, or where the network administrator wishes to establish an administrative boundary outside of which any MVRP registration information is to be ignored. For example, it might be desirable for all Ports serving end user devices to be statically configured in order to ensure that particular end users have access only to VLANs identified by particular VIDs.

f) Use of static configuration with topology changes can be appropriate where the configuration of VLANs and ports is static in some part of the network, but dynamic in another part, so that changes in the topology of the dynamic part can necessitate the flushing of learned MAC address information in Bridges in the static part. For example, in a PBBN, a topology change in a customer network with dual attachments to the provider can require a provider’s I-component to signal a MAC address flush across the backbone, even though the VLANs on the VIPs involved are statically configured.

g) Use of dynamic configuration may be appropriate on Ports where the VLAN configuration is inherently dynamic; where users of particular VIDs can connect to the network via different Ports on an ad hoc basis, or where it is desirable to allow dynamic reconfiguration in the face of spanning tree topology changes. In particular, if the “core” of the Virtual Bridged Network contains redundant paths that are pruned by the operation of the spanning tree protocol, then it is desirable for Bridge Ports that form the core network to be dynamically configured.

h) Use of both static and dynamic configuration can be appropriate on Ports where it is desirable to place restrictions on the configuration of some VIDs, while maintaining the flexibility of dynamic registration for others. For example, on Ports serving mobile end user devices, this would maintain the benefits of dynamic VLAN registration from the point of view of traffic reduction, while still allowing administrative control over some VIDs via that Port.

11.2 Multiple VLAN Registration Protocol (MVRP)

MVRP defines an MRP application that provides the VLAN registration service defined in 11.2.2. MVRP makes use of MRP Attribute Declaration (MAD) and MRP Attribute Propagation (MAP), which provide the common state machine descriptions and the common attribute propagation mechanisms defined for use in MRP-based applications. The MRP architecture, MAD, and MAP are defined in Clause 10.

MVRP provides a mechanism for dynamic maintenance of the contents of Dynamic VLAN Registration Entries for each VID, and for propagating the information they contain to other Bridges. This information allows MVRP-aware devices to dynamically establish and update their knowledge of the set of VIDs associated with VLANs that currently have active members, and through which Ports those members can be reached.

11.2.1 MVRP overview

The operation of MVRP is closely similar to the operation of MMRP (10.9), which is used for registering Group membership and individual MAC address information. The primary differences are as follows:

a) The attribute values carried by the protocol are 12-bit VID values, rather than Group service requirement information and EUI-48 MAC Addresses.

b) The act of registering/deregistering a VID affects the contents of Dynamic Registration Entries (8.8.5), rather than the contents of MAC Address Registration Entries (8.8.4).

c) In an SST environment, there is a single MVRP Participant per port, as opposed to one MMRP Participant per VID per port, and the MVRP Participants all operate in a single MAP Context.

In an MST environment, there is again a single MVRP Participant per port, but each MVRP Participant operates in multiple MAP Contexts.

MVRP allows both end stations and Bridges in a Bridged Network to issue and revoke declarations relating to membership of VLANs. The effect of issuing such a declaration is that each MVRP Participant that receives the declaration will create or update a Dynamic VLAN Registration Entry in the FDB to indicate that VID is registered on the reception Port. Subsequently, if all Participants on a LAN that had an interest in a given VID revoke their declarations, the Port attached to that LAN is set to Unregistered in the Dynamic VLAN Registration Entry for that VID by each MVRP Participant attached to that LAN.

Figure 11-1 illustrates the architecture of MVRP in the case of a two-Port Bridge and an end station.

!image

Figure 11-1—Operation of MVRP

As shown in the diagram, the MVRP Participant consists of the following components:

e) The MVRP application, described in 11.2.3

f) MRP Attribute Propagation (MAP), described in 10.3

g) MRP Attribute Declaration (MAD), described in 10.2

11.2.1.1 Behavior of end stations

VLAN-aware end stations participate in MVRP activity, as appropriate for the set of VIDs of VLANs of which they are currently members. MVRP provides a way for such an end station to ensure that the VIDs of VLAN(s) of which it is a member are registered for each Port on any LAN to which the end station is attached. MVRP also provides for that VID information to be propagated across the spanning tree to other VLAN-aware devices, as described in 11.2.1.2.

Incoming VLAN membership information (from all other devices on the same LAN) allows such end stations to “source prune” (i.e., discard at source; see 10.10.3) any traffic destined for VLANs that currently have no other members in the Bridged Network, thus avoiding the generation of unnecessary traffic on their local LANs. This is illustrated in Figure 11-1 by an FDB shown as being present in the end station.

NOTE—Non-VLAN-aware end stations have no need to register VLAN membership via MVRP; indeed, this would be impossible for them to achieve if truly VLAN-unaware, as they would have no knowledge of the set of VLANs in which they participate. Their VLAN registration requirements are taken care of by means of the configuration of PVIDs (and possibly other VLAN classification mechanisms) and the propagation of registered VIDs by the Bridges.

11.2.1.2 Behavior of Bridges

VLAN Bridges register and propagate VLAN memberships on all Bridge Ports that are part of the active topology of the underlying spanning tree(s). Incoming VID registration and deregistration information is used to update the Dynamic VLAN Registration Entries associated with each VID. Any changes in the state of registration of a given VID on a given Port are propagated on Ports that are part of the active topology of the underlying spanning tree, in order to ensure that other MVRP-aware devices in the Bridged Network update their FDBs appropriately. In Bridges that support multiple spanning tree instances, the MST Configuration Table (12.12, 13.8) is used to determine which spanning tree instance is to be used to propagate registration information for each supported VID.

The FDBs in all MVRP-aware devices are thus automatically configured such that the Port Map in the Dynamic VLAN Registration Entry for a given VID indicates that a given Port is registered if one or more members of the corresponding VLAN are reachable through the Port.

NOTE—The information that determines whether frames destined for each VID are transmitted VLAN-tagged or untagged is carried in Static VLAN Registration Entries (8.8.2); if no such entry exists for a VID, then it is assumed that frames for that VID are transmitted VLAN-tagged on all Ports. Therefore, if the configuration information held in the FDB for a given VID consists only of information configured by the operation of MVRP (i.e., only a Dynamic VLAN Registration Entry), then all traffic for that VID will be VLAN-tagged on transmission.

11.2.1.3 Use of the PVID and VID Set

The initial state of the Permanent Database contains a Static VLAN Registration Entry for the Default PVID, in which the Port Map indicates Registration Fixed (New ignored) on all Ports. This ensures that in the default state, where the value of every PVID of each Port is the Default PVID and where the VID Set of each Port is empty, membership of the Default PVID is propagated across the Bridged Network to all other MVRP-aware devices. Subsequent management action may change both the Permanent Database and the FDB in order to modify or remove this initial setting, and may change the PVID and/or VID Set value(s) on any Port of the Bridge.

NOTE—In the absence of any modification of these initial settings, this ensures that connectivity is established across the Bridged Network for the VLAN corresponding to the Default PVID.

11.2.2 VLAN registration service definition

The VLAN registration service allows MAC Service users to indicate to the MAC Service provider the set of VLANs in which they wish to participate; i.e., that the MAC Service user wishes to receive traffic destined for members of that set of VLANs. The service primitives allow the service user to

a) Register membership of a VLAN

b) Deregister membership of a VLAN

Provision of these services is achieved by means of MVRP and its associated procedures, as described in 11.2.3.

ES_REGISTER_VLAN_MEMBER (VID)

Indicates to the MAC Service provider that the MAC Service user wishes to receive frames destined for the VLAN identified by the VID parameter.

ES_DEREGISTER_VLAN_MEMBER (VID)

Indicates to the MAC Service provider that the MAC Service user no longer wishes to receive frames destined for the VLAN identified by the VID parameter.

The use of these services can result in the propagation of VID information across the spanning tree, affecting the contents of Dynamic VLAN Registration Entries (8.8.5) in Bridges and end stations in the Bridged Network, and thereby affecting the frame forwarding behavior of those Bridges and end stations.

11.2.3 Definition of the MVRP application

11.2.3.1 Definition of MRP elements

11.2.3.1.1 MAP Context for MVRP in SST environments

In an SST environment, MVRP operates in the Base Spanning Tree Context (10.3.1); i.e., MVRP operates only on the CIST. Consequently, all MVRPDUs sent and received by MVRP Participants in SST Bridges are transmitted as untagged frames.

11.2.3.1.2 MAP Contexts for MVRP in MST environments

In an MST environment, MVRP operates in multiple spanning tree contexts, one for each of the spanning trees. Each spanning tree context consists of the ports that are in the forwarding state for the corresponding spanning tree. The MVRP Participants associated with a given spanning tree operate in the MAP context identified by that spanning tree instance. MST Bridges can identify the MAP Contexts using the mappings of VID values to MSTID values (see 8.9.1). All MVRPDUs sent and received by MVRP Participants in MST Bridges are transmitted as untagged frames.

11.2.3.1.3 MVRP application address

The group MAC address used as the destination address for MRPDUs destined for MVRP Participants shall be either

a) The group MAC address identified in Table 10-1 as “Customer Bridge MVRP address” if the MVRP Participant is implemented in a C-VLAN component; or

b) The group MAC address identified in Table 8-1 as “Provider Bridge MVRP Address” if the MVRP Participant is implemented in an S-VLAN component.

11.2.3.1.4 MVRP application EtherType

The EtherType used for MRPDUs destined for MVRP Participants shall be the MVRP EtherType identified in Table 10-2.

11.2.3.1.5 MVRP ProtocolVersion

The ProtocolVersion for the version of MVRP defined in this standard takes the hexadecimal value 0x00.

11.2.3.1.6 MVRP AttributeType definitions

MVRP defines a single Attribute Type (10.8.2.2) that is carried in MRP exchanges, as follows:

Attributes identified by the VID Vector Attribute Type are instances of VectorAttributes (10.8.1), used to identify a sequence of values of VIDs. The value of AttributeType used to identify the VID Vector Attribute Type in MRPDUs (10.8.2.2) shall be 1.

11.2.3.1.7 MVRP FirstValue definitions

The FirstValue field in instances of the VID Vector Attribute Type shall be encoded in MRPDUs (10.4) as two octets, taken to represent an unsigned binary number, and equal to the value of the VID that is to be encoded.

The range of permitted values that can be encoded in the FirstValue fields in MVRP is restricted to the range 0 through 4094.The value 0 represents the VID of the untagged frame on which the MRPDU is transmitted or received, and 1 through 4094 identify specific VIDs. If enabled by management [item (e) in 12.9.2.2.2], and if there is only one VID whose untagged set includes the Port of an MVRP Participant, the Participant shall transmit the value 0 in place of that VID. All MVRP Participants shall translate the value 0 in a received message to the PVID of the receiving Port.

NOTE—Previous revisions of this Standard did not provide for transmission or reception of 0 as an MVRP Attribute value. No automatic means for determining whether the other MVRP Participants on a LAN are capable of receiving the value 0 are provided. Therefore, extreme care is in order when configuring an MVRP Participant to transmit Attribute value 0, as compliant implementations of previous revisions of this standard could drop such MRPDUs as badly formed.

11.2.3.1.8 MVRP AttributeLength definitions

The AttributeLength field (10.12.1.8) in instances of the VID Vector Attribute Type shall be encoded in MRPDUs (10.8) as an unsigned binary number, equal to the value 0x02.

11.2.3.1.9 MVRP AttributeListLength definitions

The AttributeListLength field (10.8.2.4) is not present in the MVRPDUs.

11.2.3.1.10 MVRP Vector definitions

The ThreePackedEvent vectors are encoded as defined in 10.8.2.10.1.

The FourPackedEvent vectors (10.8.2.10.2) are not present in the MVRPDUs.

11.2.3.2 Provision and support of the VLAN registration service

11.2.3.2.1 Initiating VLAN membership declaration

The MVRP application element of a MVRP Participant provides the dynamic registration and deregistration services defined in 11.2.2, as follows:

On receipt of an ES_REGISTER_VLAN_MEMBER service primitive, the MVRP Participant issues a MAD_Join.request service primitive (10.2, 10.3). The attribute_type parameter of the request carries the value of the VID Vector Attribute Type (11.2.3.1.6) and the attribute_value parameter carries the value of the VID parameter carried in the ES_REGISTER_VLAN_MEMBER primitive.

On receipt of an ES_DEREGISTER_VLAN_MEMBER service primitive, the MVRP Participant issues a MAD_Leave.request service primitive (10.2, 10.3). The attribute_type parameter of the request carries the value of the VID Vector Attribute Type (11.2.3.1.6) and the attribute_value parameter carries the value of the VID parameter carried in the ES_DEREGISTER_VLAN_MEMBER primitive.

11.2.3.2.2 VLAN membership registration

The MVRP application element of a MVRP Participant responds to registration and deregistration events signaled by MAD as follows:

On receipt of a MAD_Join.indication whose attribute_type is equal to the value of the VID Vector Attribute Type (11.2.3.1.6), the MVRP application element indicates the reception Port as Registered in the Port Map of the Dynamic VLAN Registration Entry for the VID indicated by the attribute_value parameter. If no such entry exists, there is sufficient room in the FDB, and the VID is within the range of values supported by the implementation (see 9.6), then an entry is created. If not, then the indication is not propagated and the registration fails.

The creation of new Dynamic VLAN Registration Entries can be restricted by use of the Restricted_VLAN_Registration control (11.2.3.2.3). If the value of this control is TRUE, then creation of a new dynamic entry is permitted only if there is a Static VLAN Registration Entry for the VID concerned, in which the Registrar Administrative Control value is Normal Registration.

On receipt of a MAD_Leave.indication whose attribute_type is equal to the value of the VID Vector Attribute Type (11.2.3.1.6), the MVRP application element indicates the reception Port as not Registered in the Port Map of the Dynamic VLAN Registration Entry for the VID indicated by the attribute_value parameter. If no such entry exists, the indication is ignored.

11.2.3.2.3 Administrative controls

The provision of static control over the declaration or registration state of the state machines associated with the MVRP application is achieved by means of the Registrar Administrative Control parameters provided by MRP (10.7.2). These parameters are represented as Static VLAN Registration Entries in the FDB (8.8.2). Where management capability is implemented, these parameters can be manipulated by means of the management functionality defined in 12.7.

The provision of static control over the ability of Applicant and Registrar state machines to participate in protocol exchanges is achieved by means of the Applicant Administrative Control parameters and Registrar Administrative Control parameters associated with the operation of MRP (10.7.2, 10.7.3). Where management capability is implemented, the Applicant and Registrar Administrative Control parameters can be applied and modified by means of the management functionality defined in 12.9. A separate managed variable [item (c) in 12.9.2.1.3] controls whether the Applicant state machine transmits 0 or the VID as the Attribute for a VLAN on a Port in that VLAN’s untagged set.

Further administrative control over dynamic VLAN registration can be achieved, if supported, by means of a per-Port Restricted_VLAN_Registration control parameter. If the value of this control is TRUE for a given Port, the creation or modification of Dynamic VLAN Registration Entries as a result of MVRP exchanges on that Port shall be restricted only to those VIDs for which Static VLAN Registration Entries exist in which the Registrar Administrative Control value is Normal Registration. If the value of the Restricted_VLAN_Registration control is FALSE, dynamic VLAN registration is not so restricted. The recommended default value of this parameter is FALSE. Where management capability is implemented, the value of the Restricted_VLAN_Registration control can be manipulated by means of the management functionality defined in 12.10. If management of this parameter is not supported, the value of this parameter shall be FALSE for all Ports.

11.2.4 VID translation table

If a VID Translation Table (6.9) is in use for a Bridge Port, the VID values received in MVRP Attributes are translated on reception of MVRPDUs prior to MVRP processing as specified in this subclause (11.2), and translated after processing for encoding MVRP Attributes in transmitted MVRPDUs. The interpretation of the MVRP Attribute value 0 is not affected by the VID Translation Table in either direction.

NOTE—In the case that the Port on which an MVRPDU is transmitted is in the untagged set of the VID matching the PVID of the Port receiving the MVRPDU, the use of the value 0 in the FirstValue field effectively performs a VID translation.

11.2.5 Use of “new” declaration capability

MVRP makes use of the “new” declaration capability in order to allow FDB entries to be removed or rapidly aged out on a per-VID basis following a topology change in the network connectivity supporting the VID concerned. The rules for propagation of “new” declarations as defined in Clause 10 ensure that all MADs that originate from, or are propagated through, a Bridge Port that has recently transitioned to Forwarding are marked as “new” declarations.

When any MVRP declaration marked as “new” is received on a given Port, either as a result of receiving an MVRPDU from the attached LAN (MAD_Join.indication), or as a result of receiving a request from MAP or the MVRP Application (MAD_Join.request), any Dynamic Filtering Entries in the FDB for that Port and for the VID corresponding to the attribute value in the MAD_Join primitive are removed.

11.2.6 New-Only Participant and Registrar Administrative Controls

A Bridge may support an MVRP New-Only Participant (10.6). This can be useful in an I-component that has statically configured S-VLAN registrations, but must still accommodate signaling the flushing of learned MAC address information. The choice of whether a given Port’s MVRP Participant operates as a Full Participant or a New-Only Participant is controlled by a managed object [12.9.2]. This managed object is separate from the one controlling whether a given Port uses Registration Fixed (New ignored) or Registration Fixed (New propagated) Static VLAN Registration Entries [item (d) in 12.7.7.3.3].

NOTE 1—Configuring an MVRP Participant as a New-Only Participant makes the assumption that all of the MVRP Participants on the LAN are configured completely via Static VLAN Registration Entries, and that no Dynamic VLAN Registration Entries are needed. If this assumption is violated, then the Bridged Network can fail to provide connectivity for the VLANs that need Dynamic VLAN Registration Entries. Therefore, extreme care is in order when configuring a New-Only MVRP Participant.

If a MAD_Join.indication is received by the MVRP MAD with the new parameter set, e.g., because a “new” MVRP declaration is received on a Port configured for New propagated [item (d) in 12.7.7.3.3] as a result of receiving an MVRPDU from the attached LAN, and that MAD_Join.indication does not correspond to a Static VLAN Registration Entry of Registration Fixed (New propagated) in the FDB, that MAD_Join.indication shall be discarded without being propagated.

NOTE 2—If only one S-VLAN is configured per VIP, then using a MIRP Participant (Clause 39) can provide bandwidth and processing savings over using an MVRP New-Only Participant on a VIP. See 39.2.1.1 and 39.2.1.6.

11.2.7 Attribute value support requirements

Implementations of MVRP shall be capable of supporting all attribute values in the range of possible values that can be registered using MVRP, and shall be capable of maintaining current state information for all attributes in the range of possible values.

12 Bridge management

This clause defines the set of managed objects, and their functionality, that allow administrative configuration of VLANs.

This clause

a) Introduces the functions of management to assist in the identification of the requirements placed on Bridges for the support of management facilities.

b) Establishes the correspondence between the Processes used to model the operation of the Bridge (8.3) and the managed objects of the Bridge.

c) Specifies the management operations supported by each managed object.

12.1 Management functions

Management functions relate to the users’ needs for facilities that support the planning, organization, supervision, control, protection, and security of communications resources, and account for their use. These facilities may be categorized as supporting the functional areas of Configuration, Fault, Performance, Security, and Accounting Management. Each functional area is summarized in 12.1.1 through 12.1.5, together with the facilities commonly required for the management of communication resources, and the particular facilities provided in that functional area by Bridge Management.

It can be necessary, particularly in PBNs, for multiple organizations to manage a single Bridge, with each organization having different abilities to manage, or even detect the existence of, Bridge Ports, Bridges, or entire networks. Access to all of the managed objects in Clause 12 for reading, writing, or detection can be restricted. Access by certain organizations can be limited to only a small number of managed objects, particularly to those specified in 12.14.

12.1.1 Configuration Management

Configuration Management provides for the identification of communications resources, initialization, reset and close-down, the supply of operational parameters, and the establishment and discovery of the relationship between resources. The facilities provided by Bridge Management in this functional area are

a) The identification of all Bridges that together make up the network and their respective locations and, as a consequence of that identification, the location of specific end stations to particular individual LANs.

b) The ability to remotely reset, i.e., reinitialize, specified Bridges.

c) The ability to control the priority with which a Bridge Port transmits frames.

d) The ability to force a specific configuration of a spanning tree.

e) The ability to control the propagation of frames with specific group MAC addresses to certain parts of the configured network.

f) The ability to identify the VIDs in use, and through which Ports of the Bridge and for which Protocols frames destined for a given VID may be received and/or forwarded.

g) The ability to create and delete the functional elements of CFM and to control their operation.

h) The ability to create and delete the functional elements of DDCFM and to control their operations.

i) The ability to create and delete the functional elements of congestion notification and to control their operation.

j) The ability to control the operation of MIRP.

k) The ability to control the operation of SPB.

l) The ability to configure the functional elements of EVB and to control their operation.

12.1.2 Fault Management

Fault Management provides for fault prevention, detection, diagnosis, and correction. The facilities provided by Bridge Management in this functional area are

a) The ability to identify and correct Bridge malfunctions, including error logging and reporting.

b) Within the context of multiple management organizations, the ability to

1) Actively monitor the connectivity of a set of managed endpoints on individual VLANs, simultaneously over multiple physical extents;

2) Actively monitor and ensure the segregation of data among different VLANs;

3) Issue trains of point-to-point query-response messages to selected network components in a VLAN;

4) Issue multicast query-relay-response messages to determine the path taken by frames addressed to specific individual MAC addresses through a VLAN;

5) Determine whether a flow of specified data frames (e.g., frames associated with a service instance or selected data frames with certain destination address) can reach a particular destination; and

6) Determine whether a flow of data frames can be sent without error from a specific location within a network to a station or stations specified by the DA field of each frame.

12.1.3 Performance Management

Performance Management provides for evaluation of the behavior of communications resources and of the effectiveness of communication activities. The facilities provided by Bridge Management in this functional area are as follows:

a) The ability to gather statistics relating to performance and traffic analysis. Specific metrics include network utilization, frame forward, and frame discard counts for individual Ports within a Bridge.

12.1.4 Security Management

Security Management provides for the protection of resources. Bridge Management does not provide any specific facilities in this functional area.

12.1.5 Accounting Management

Accounting Management provides for the identification and distribution of costs and the setting of charges. Bridge Management does not provide any specific facilities in this functional area.

12.2 VLAN Bridge objects

Managed objects model the semantics of management operations. Operations on an object supply information concerning, or facilitate control over, the process or entity associated with that object.

The managed resources of a VLAN Bridge or Bridge component are those of the processes and entities in 8.3. Specifically,

a) The Bridge Management Entity (12.4 and 8.12).

b) The individual MAC Entities associated with each Bridge Port (12.5, 8.2, and 8.5).

c) The Forwarding Process of the MAC Relay Entity (12.6, 8.2, and 8.6).

d) The FDB of the MAC Relay Entity (12.7 and 8.8).

e) The Bridge Protocol Entity (12.8 and 8.10).

f) MRP participants (Clause 10).

g) MVRP participants (12.10, Clause 11).

h) MMRP participants (12.11, Clause 10).

i) The MST Configuration Table (12.12).

j) Additional objects to support Provider Bridge management (12.13).

k) The CFM Entities (12.14).

l) The DDCFM Entities (12.17).

m) The PBB-TE protection switching Entities (12.18).

n) The TPMR Entities (12.19).

o) The management entities for FQTSS (12.20).

p) The congestion notification entities (12.21).

q) The Shortest Path Bridging managed objects.

r) The EVB entities (12.26).

The management of each of these resources is described in terms of managed objects and operations in 12.4 through 12.12.

NOTE—The values specified in this clause, as inputs and outputs of management operations, are abstract information elements. Questions of formats or encodings are a matter for particular protocols that convey or otherwise represent this information.

Some data elements that are represented by the managed objects specified in this clause are required to be persistent across reinitializations or rebooting of the system within which the objects are implemented. For example, it may be desirable for changes in configuration parameters to persist across such events. Where such a requirement exists, this is indicated in the specification by marking the object concerned with the keyword “Persistent.”

12.3 Data types

This subclause specifies the semantics of operations independent of their encoding in management protocol. The data types of the parameters of operations are defined only as required for that specification.

The following data types are used:

a) Boolean.

b) Enumerated, for a collection of named values.

c) Unsigned, for all parameters specified as “the number of” some quantity, and for spanning tree priority values that are numerically compared. When comparing spanning tree priority values, the lower number represents the higher priority value.

d) MAC address.

e) Latin1 String, as defined by ANSI X3.159, for all text strings.

f) Time Interval, an Unsigned value representing a positive integral number of seconds, for all spanning tree protocol timeout parameters;

g) Counter, for all parameters specified as a “count” of some quantity. A counter increments and wraps with a modulus of 2 to the power of 64.

h) MRP Time Interval, an Unsigned value representing a positive integral number of centiseconds, for all MRP timeout parameters.

i) Port Number, an Unsigned value assigned to a Port as part of a Port Identifier. Valid Port Numbers are in the range 1 through 4095.

j) Port Priority, an Unsigned value used to represent the priority component of a Port Identifier. Valid Port Priorities are in the range 0 through 240, in steps of 16.

k) Bridge Priority, an Unsigned value used to represent the priority component of a Bridge Identifier. Valid Bridge Priorities are in the range 0 through 61440, in steps of 4096.

l) ComponentID, an unsigned value used to uniquely identify the management objects for a particular VLAN Bridge component (12.2, Clause 8, 5.4) within a system (such as a BEB) comprising

multiple such components. ComponentIDs start at 1 and go through 4294967295. If the system has a single component it will have a ComponentID equal to 1.

m) ComponentType, an enumerated list used to classify a particular VLAN Bridge component within a system comprising multiple components.

n) Port Index, a handle, unique within a system, that identifies a port.

o) PIP Index, a Port Index for a PIP.

p) Percentage.

q) ECT-ALGORITHM. A 4-byte unsigned identifier. Used as a worldwide unique definition of an Equal Cost Tree (ECT) Algorithm, the first 3 bytes are expected to be taken from the OUI or CID space for the organization that has defined the algorithm. The last byte is allocated by that organization.

r) SPSourceID. A 20-bit Unsigned identifier. Used to represent a node uniquely within an SPT Domain (27.10).

s) Timer exp, an unsigned value from 0–31 representing a positive integer for the exponent of $^ { 2 , }$ which forms the multiplier of 10 μs, used for EVB protocol timeout parameters.

NOTE—For example, a value of 4 represents $2 ^ { 4 }$  10 μs, or 160 μs.

t) Boolean array, an array of Boolean values.

12.4 Bridge Management Entity

The Bridge Management Entity is described in 8.12.

The objects that comprise this managed resource are

a) The Bridge Configuration (12.4.1)

b) The Port Configuration for each Port (12.4.2)

12.4.1 Bridge Configuration

The Bridge Configuration object models the operations that modify, or inquire about, the configuration of the Bridge’s resources. There is a single Bridge Configuration object per Bridge.

The management operations that can be performed on the Bridge Configuration are

a) Discover Bridge (12.4.1.1)

b) Read Bridge (12.4.1.2)

c) Set Bridge Name (12.4.1.3)

d) Reset Bridge (12.4.1.4)

e) Read component table entry (12.4.1.5)

f) Update component table entry (12.4.1.5)

12.4.1.1 Discover Bridge

12.4.1.1.1 Purpose

To solicit configuration information regarding the Bridge(s) in the network.

12.4.1.1.2 Inputs

a) Inclusion Range, a set of ordered pairs of specific MAC addresses. Each pair specifies a range of MAC addresses. A Bridge shall respond if and only if

1) For one of the pairs, the numerical comparison of its Bridge Address with each MAC address of the pair shows it to be greater than or equal to the first, and

2) Less than or equal to the second, and

3) Its Bridge Address does not appear in the Exclusion List parameter below.

The numerical comparison of one MAC address with another, for the purpose of this operation, is achieved by deriving a number from the MAC address according to the following procedure. The consecutive octets of the MAC address are taken to represent a binary number; the first octet that would be transmitted on a LAN medium when the MAC address is used in the source or destination fields of a MAC frame has the most significant value, the next octet the next most significant value. Within each octet, the first bit of each octet is the LSB.

b) Exclusion List, a list of specific MAC addresses.

12.4.1.1.3 Outputs

a) Bridge Address—the MAC address for the Bridge from which the Bridge Identifiers used by STP, RSTP, and MSTP are derived (8.13.8, 13.26).

b) Bridge Name—a text string of up to 32 characters, of locally determined significance.

c) Number of Ports—the number of Bridge Ports (MAC Entities).

d) Port Addresses—a list specifying the following for each Port:

1) Port Number—the number of the Bridge Port (13.27).

2) Port Address—the specific MAC address of the individual MAC Entity associated with the Port (8.13.2).

e) Uptime—count in seconds of the time elapsed since the Bridge was last reset or initialized.

NOTE—Events that are considered to reset or initialize the Bridge include changing the MCID.

12.4.1.2 Read Bridge

12.4.1.2.1 Purpose

To obtain general information regarding the Bridge.

12.4.1.2.2 Inputs

None.

12.4.1.2.3 Outputs

a) Bridge Address—the MAC address for the Bridge from which the Bridge Identifiers used by RSTP and MSTP are derived (8.13.8, 13.26).

b) Bridge Name—a text string of up to 32 characters, of locally determined significance.

c) Number of Ports—the number of Bridge Ports (MAC Entities).

d) Port Addresses—a list specifying the following for each Port:

1) Port Number (13.27).

2) Port Address—the specific MAC address of the individual MAC Entity associated with the Port (8.13.2).

e) Uptime—count in seconds of the time elapsed since the Bridge was last reset or initialized.

12.4.1.3 Set Bridge Name

12.4.1.3.1 Purpose

To associate a text string, readable by the Read Bridge operation, with a Bridge.

12.4.1.3.2 Inputs

a) Bridge Name—a text string of up to 32 characters.

12.4.1.3.3 Outputs

None.

12.4.1.4 Reset Bridge

12.4.1.4.1 Purpose

To reset the specified Bridge. The FDB is cleared and initialized with the entries specified in the Permanent Database, and the Bridge Protocol Entity is initialized.

12.4.1.4.2 Inputs

None.

12.4.1.4.3 Outputs

None.

12.4.1.5 Bridge component configuration

There is a single Bridge component table per system. Each entry in the component table represents a component of the system (Table 12-1). The entries hold the parameters for each component including the component type and capabilities.

The operations that can be implemented on component table entries are as follows:

a) Read component table entry

b) Update component table entry

NOTE—The Bridge component table is implemented in Clause 17 as the BridgeBaseTable (see Table 17-3).

12.4.1.5.1 Component type enumeration

The compComponentType parameter can be assigned the following values:

a) iComponent—An I-component (5.7)

b) bComponent—A B-component (5.8)

c) cVlanComponent—A C-VLAN component (5.5)

d) sVlanComponent—An S-VLAN component (5.6)

e) dBridgeComponent—A VLAN unaware component (5.12)

f) edgeRelay—An EVB station ER (5.24.1)

Table 12-1—Component table entry managed object

<table><tr><td>Name</td><td>Data type</td><td><eq>Operations\ supported^a</eq></td><td>References</td></tr><tr><td>compComponentId</td><td>ComponentID</td><td>R</td><td>12.3 l)</td></tr><tr><td>compMACAddress</td><td>MAC address</td><td>R</td><td>8.13.8, 13.24</td></tr><tr><td></td><td></td><td></td><td></td></tr><tr><td>compNumberPorts</td><td>unsigned (1..4095)</td><td>R</td><td>12.4.1.1.3 c)</td></tr><tr><td>compComponentType</td><td>ComponentType</td><td>R</td><td>12.3 m)</td></tr><tr><td>compDeviceCapabilities</td><td>Boolean array (0..7)</td><td>R</td><td>12.10.1.1.3 b)</td></tr><tr><td>compTrafficClassesEnabled</td><td>Boolean</td><td>RW</td><td>—</td></tr><tr><td>compMmrpEnabledStatus</td><td>Boolean</td><td>RW</td><td>—</td></tr></table>

a R= Read-only access; RW = Read/Write access.

12.4.1.5.2 Component device capabilities

The compDeviceCapabilities parameter contains an array of Boolean values for the following:

a) ExtendedFilteringServices

b) TrafficClasses

c) StaticEntryIndividualPort

d) IVLCapable

e) SVLCapable

f) HybridCapable

g) ConfigurablePvidTagging

h) LocalVlanCapable

12.4.2 Port configuration

The Port Configuration object models the operations that modify, or inquire about, the configuration of the Ports of a Bridge. Unless the system explicitly supports the ability to dynamically create and/or delete ports, there is a fixed set of Bridge Ports per Bridge (one for each MAC interface), and each is identified by a permanently allocated Port Number.

The allocated Port Numbers are not required to be consecutive. Also, some Port Numbers may be dummy entries, with no actual LAN Port (for example, to allow for expansion of the Bridge by addition of further MAC interfaces in the future). Such dummy Ports shall support the Port Configuration management operations and other Port-related management operations in a manner consistent with the Port being permanently disabled.

The information provided by the Port Configuration consists of summary data indicating its name and type. Specific counter information pertaining to the number of packets forwarded, filtered, and in error is maintained by the Forwarding Process resource. The management operations supported by the Bridge Protocol Entity allow for controlling the states of each Port.

A port table entry can be implemented by a Bridge for each Port of each component (Table 12-2). It comprises the parameters for each Port including the port type, capabilities, and statistics.

The management operations that can be performed on the port table are

a) Read port table entry (12.4.2.1)

b) Update port table entry (12.4.2.1)

Table 12-2—Port table entry

<table><tr><td>Name</td><td>Data type</td><td><eq>Operations\ supported^a</eq></td><td>References</td></tr><tr><td>portComponentId</td><td>ComponentID</td><td>R</td><td>12.4.1.5</td></tr><tr><td>portPortNumber</td><td>Port Number</td><td>R</td><td>13.25</td></tr><tr><td>portMACAddress</td><td>MAC address</td><td>R</td><td>12.4.1.1.3 a)</td></tr><tr><td></td><td></td><td></td><td></td></tr><tr><td>portDelayExceededDiscards</td><td>counter</td><td>R</td><td>—</td></tr><tr><td>portMtuExceededDiscards</td><td>counter</td><td>R</td><td>—</td></tr><tr><td>portCapabilities</td><td>unsigned</td><td>R</td><td>—</td></tr><tr><td>portTypeCapabilities</td><td>unsigned</td><td>R</td><td>—</td></tr><tr><td>portType</td><td>enumerated</td><td>R</td><td>12.4.2.1</td></tr><tr><td>portExternal</td><td>Boolean</td><td>R</td><td>—</td></tr><tr><td>portAdminPointToPoint</td><td>unsigned</td><td>RW</td><td>IEEE Std 802.1AC</td></tr><tr><td>portOperPointToPoint</td><td>Boolean</td><td>R</td><td>IEEE Std 802.1AC</td></tr><tr><td>portName</td><td>Latin1 String (SIZE(0..32))</td><td>RW</td><td>—</td></tr></table>

a R= Read-only access; RW = Read/Write access.

12.4.2.1 Port type capabilities and enumeration

The portTypeCapabilities array has a bit for each port type the Port can take, while the portType is an enumeration. The portTypeCapabilities can take any combination of port types while the portType can take exactly one of the following values:

a) C-VLAN Bridge Port

b) Provider Network Port (PNP)

c) Customer Network Port (CNP)

d) Customer Edge Port (CEP)

e) Customer Backbone Port (CBP)

f) Virtual Instance Port (VIP)

g) D-Bridge Port

h) Remote Customer Access Port (RCAP) (12.13.3)

i) Station-facing Bridge Port (SBP) (12.26.2)

j) Uplink Access Port (UAP) (12.26.4)

k) Uplink relay port (URP) (12.26.5)

NOTE—A portType is not required for a downlink relay port (DRP) or an S-channel Access Port (CAP) as no special EVB objects are necessary. A DRP is type C-VLAN Bridge Port while a CAP is type CNP.

12.5 MAC entities

The Management Operations and Facilities provided by the MAC Entities are those specified in the Layer Management standards of the individual MACs. A MAC Entity is associated with each Bridge Port.

12.5.1 ISS Port Number table managed object (optional)

An instance of the ISS Port Number table can be implemented by a Bridge system to identify the ISS interfaces that can be assigned to Bridge Ports. The ISS table is required when the Bridge Port assigned to an ISS and the ISS itself are referenced using different Port Numbers. The ISS table is keyed on the ISS Port Number. Each ISS table entry identifies a mapping from the ISS Port Number to a Bridge Port’s ComponentID and Port Number. An issToComponentID value of 0 indicates the ISS is not bound to a Bridge Port. The issToComponentID and issToPortNumber parameters are updated indirectly as a result of creating or updating other system-specific Port objects.

The operation that can be implemented on an ISS Port Number table is

a) Read ISS Port Number table entry (see Table 12-3)

Table 12-3—ISS Port Number table entry

<table><tr><td>Name</td><td>Data type</td><td><eq>Operations\ supported^a</eq></td><td>References</td></tr><tr><td>issPortNumber</td><td>Port Number</td><td>R</td><td>12.3 i)</td></tr><tr><td>issMACAddress</td><td>MAC address</td><td>R</td><td>8.13.2</td></tr><tr><td></td><td></td><td></td><td></td></tr><tr><td>issToComponentID</td><td>ComponentID, 0</td><td>R</td><td>12.4.2</td></tr><tr><td>issToPortNumber</td><td>Port Number, 0</td><td>R</td><td>12.4.2</td></tr></table>

a R= Read-only access; RW = Read/Write access.

12.6 Forwarding process

The Forwarding Process contains information relating to the forwarding of frames. Counters are maintained that provide information on the number of frames forwarded, filtered, and dropped due to error. Configuration data, defining how frame priority is handled, is maintained by the Forwarding Process.

The objects that comprise this managed resource are

a) The Port Counters (12.6.1)

b) The Priority Handling objects for each Port (12.6.2)

c) The Traffic Class Table for each Port (12.6.3)

12.6.1 The Port Counters

The Port Counters object models the operations that can be performed on the Port counters of the Forwarding Process resource. There are multiple instances (one for each VID for each MAC Entity) of the Port Counters object per Bridge.

The management operation that can be performed on the Port Counters is Read Forwarding Port Counters (12.6.1.1).

12.6.1.1 Read forwarding port counters

12.6.1.1.1 Purpose

To read the forwarding counters associated with a specific Bridge Port.

12.6.1.1.2 Inputs

a) Port Number (13.27)

b) Optionally, VID (9.6)

If the VID parameter is supported, then the forwarding Port counters are maintained per VID per Port. If the parameter is not supported, then the forwarding Port counters are maintained per Port only.

12.6.1.1.3 Outputs

a) Frames Received—count of all valid frames received (including BPDUs, frames addressed to the Bridge as an end station, and frames that were submitted to the Forwarding Process, 8.5).

b) Optionally, Octets Received—count of the total number of octets in all valid frames received (including BPDUs, frames addressed to the Bridge as an end station, and frames that were submitted to the Forwarding Process).

c) Discard Inbound—count of valid frames received that were discarded by the Forwarding Process (8.6).

d) Forward Outbound—count of frames forwarded to the associated MAC Entity (8.5).

e) Discard Lack of Buffers—count of frames that were to be transmitted through the associated Port but were discarded due to lack of buffers (8.6.6).

f) Discard Transit Delay Exceeded—count of frames that were to be transmitted but were discarded due to the maximum Bridge transit delay being exceeded (buffering may have been available, 8.6.6).

g) Discard on Error—count of frames that were to be forwarded on the associated MAC but could not be transmitted (e.g., frame would be too large, 6.5.8).

h) If Ingress Filtering is supported (8.6.2), Discard on Ingress Filtering—count of frames that were discarded as a result of Ingress Filtering being enabled.

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.6.2 Priority handling

The Priority Handling object models the operations that can be performed on, or inquire about, the Default Priority parameter, the Priority Regeneration Table parameter, the Outbound Access Priority Table parameter, the Priority Code Point parameters, and the Service Access Priority parameters for each Port. The operations that can be performed on this object are

a) Read Port Default Priority (12.6.2.1)

b) Set Port Default Priority (12.6.2.2)

c) Read Port Priority Regeneration Table (12.6.2.3)

d) Set Port Priority Regeneration Table (12.6.2.4)

e) Read Port Priority Code Point Selection (12.6.2.5)

f) Set Port Priority Code Point Selection (12.6.2.6)

g) Read Port Priority Code Point Decoding Table (12.6.2.7)

h) Optionally, Set Port Priority Code Point Decoding Table (12.6.2.8)

i) Read Port Priority Code Point Encoding Table (12.6.2.9)

j) Optionally, Set Port Priority Code Point Encoding Table (12.6.2.10)

k) Read Use_DEI parameter (12.6.2.11)

l) Optionally, Set Use_DEI parameter (12.6.2.12)

m) Read Require Drop Encoding parameter (12.6.2.13)

n) Optionally, Set Require Drop Encoding parameter (12.6.2.14)

o) Read Service Access Priority Selection (12.6.2.15)

p) Optionally, Set Service Access Priority Selection (12.6.2.16)

q) Read Service Access Priority Table (12.6.2.17)

r) Optionally, Set Service Access Priority Table (12.6.2.18)

12.6.2.1 Read Port Default Priority

12.6.2.1.1 Purpose

To read the current state of the Default Priority parameter (IEEE Std 802.1AC) for a specific Bridge Port.

12.6.2.1.2 Inputs

a) Port number.

12.6.2.1.3 Outputs

a) Default Priority value—Integer in range 0–7.

12.6.2.2 Set Port Default Priority

12.6.2.2.1 Purpose

To set the current state of the Default Priority parameter (IEEE Std 802.1AC) for a specific Bridge Port.

12.6.2.2.2 Inputs

a) Port number.

b) Default Priority value—Integer in range 0–7.

12.6.2.2.3 Outputs

None.

12.6.2.3 Read Port Priority Regeneration Table

12.6.2.3.1 Purpose

To read the current state of the Priority Regeneration Table parameter (6.9.4) for a specific Bridge Port.

12.6.2.3.2 Inputs

a) Port number.

12.6.2.3.3 Outputs

a) Regenerated Priority value for Received Priority 0—Integer in range 0–7.

b) Regenerated Priority value for Received Priority 1—Integer in range 0–7.

c) Regenerated Priority value for Received Priority 2—Integer in range 0–7.

d) Regenerated Priority value for Received Priority 3—Integer in range 0–7.

e) Regenerated Priority value for Received Priority 4—Integer in range 0–7.

f) Regenerated Priority value for Received Priority 5—Integer in range 0–7.

g) Regenerated Priority value for Received Priority 6—Integer in range 0–7.

h) Regenerated Priority value for Received Priority 7—Integer in range 0–7.

12.6.2.4 Set Port Priority Regeneration Table

12.6.2.4.1 Purpose

To set the current state of the Priority Regeneration Table parameter (6.9.4) for a specific Bridge Port.

12.6.2.4.2 Inputs

a) Port number.

b) Regenerated Priority value for Received Priority 0—Integer in range 0–7.

c) Regenerated Priority value for Received Priority 1—Integer in range 0–7.

d) Regenerated Priority value for Received Priority 2—Integer in range 0–7.

e) Regenerated Priority value for Received Priority 3—Integer in range 0–7.

f) Regenerated Priority value for Received Priority 4—Integer in range 0–7.

g) Regenerated Priority value for Received Priority 5—Integer in range 0–7.

h) Regenerated Priority value for Received Priority 6—Integer in range 0–7.

i) Regenerated Priority value for Received Priority 7—Integer in range 0–7.

12.6.2.4.3 Outputs

None.

12.6.2.5 Read Port Priority Code Point Selection

12.6.2.5.1 Purpose

To read which row of the Priority Code Point Encoding Table and Priority Code Point Decoding Table (6.9.3) is currently selected for use on this Port.

12.6.2.5.2 Inputs

a) Port Number: the number of the Bridge Port.

12.6.2.5.3 Outputs

a) Priority Code Point Selection: this takes one of the following values:

1) 8P0D

2) 7P1D

3) 6P2D

4) 5P3D

12.6.2.6 Set Port Priority Code Point Selection

12.6.2.6.1 Purpose

To set which row of the Priority Code Point Encoding Table and Priority Code Point Decoding Table (6.9.3) will be selected for use on this Port.

12.6.2.6.2 Inputs

a) Port Number: the number of the Bridge Port.

b) Priority Code Point Selection: this takes one of the following values:

1) 8P0D

2) 7P1D

3) 6P2D

4) 5P3D

12.6.2.6.3 Outputs

None.

12.6.2.7 Read Priority Code Point Decoding Table

12.6.2.7.1 Purpose

To read the current contents of a row in the Priority Code Point Decoding Table (6.9.3) for a Port.

12.6.2.7.2 Inputs

a) Port Number: the number of the Bridge Port.

b) Priority Code Point Row: this takes one of the following values:

1) 8P0D

2) 7P1D

3) 6P2D

4) 5P3D

12.6.2.7.3 Outputs

a) Priority value for Priority Code Point 0: Integer in range 0–7.

b) Drop_eligible value for Priority Code Point 0: Boolean.

c) Priority value for Priority Code Point 1: Integer in range 0–7.

d) Drop_eligible value for Priority Code Point 1: Boolean.

e) Priority value for Priority Code Point 2: Integer in range 0–7.

f) Drop_eligible value for Priority Code Point 2: Boolean.

g) Priority value for Priority Code Point 3: Integer in range 0–7.

h) Drop_eligible value for Priority Code Point 3: Boolean.

i) Priority value for Priority Code Point 4: Integer in range 0–7.

j) Drop_eligible value for Priority Code Point 4: Boolean.

k) Priority value for Priority Code Point 5: Integer in range 0–7.

l) Drop_eligible value for Priority Code Point 5: Boolean.

m) Priority value for Priority Code Point 6: Integer in range 0–7.

n) Drop_eligible value for Priority Code Point 6: Boolean.

o) Priority value for Priority Code Point 7: Integer in range 0–7.

p) Drop_eligible value for Priority Code Point 7: Boolean.

12.6.2.8 Set Priority Code Point Decoding Table

12.6.2.8.1 Purpose

To modify the contents of a row in the Priority Code Point Decoding Table (6.9.3) for a Port.

12.6.2.8.2 Inputs

a) Port Number: the number of the Bridge Port.

b) Priority Code Point Row: this takes one of the following values:

1)2) 8P0D 7P1D 3) 6P2D 4) 5P3D

c) Priority value for Priority Code Point 0: Integer in range 0–7.

d) Drop_eligible value for Priority Code Point 0: Boolean.

e) Priority value for Priority Code Point 1: Integer in range 0–7.

f) Drop_eligible value for Priority Code Point 1: Boolean.

g) Priority value for Priority Code Point 2: Integer in range 0–7.

h) Drop_eligible value for Priority Code Point 2: Boolean.

i) Priority value for Priority Code Point 3: Integer in range 0–7.

j) Drop_eligible value for Priority Code Point 3: Boolean.

k) Priority value for Priority Code Point 4: Integer in range 0–7.

l) Drop_eligible value for Priority Code Point 4: Boolean.

m) Priority value for Priority Code Point 5: Integer in range 0–7.

n) Drop_eligible value for Priority Code Point 5: Boolean.

o) Priority value for Priority Code Point 6: Integer in range 0–7.

p) Drop_eligible value for Priority Code Point 6: Boolean.

q) Priority value for Priority Code Point 7: Integer in range 0–7.

r) Drop_eligible value for Priority Code Point 7: Boolean.

12.6.2.8.3 Outputs

None.

12.6.2.9 Read Priority Code Point Encoding Table

12.6.2.9.1 Purpose

To read the current contents of a row in the Priority Code Point Encoding Table (6.9.3) for a Port.

12.6.2.9.2 Inputs

a) Port Number: the number of the Bridge Port.

b) Priority Code Point Row: this takes one of the following values: 1) 8P0D

2) 7P1D

3) 6P2D

4) 5P3D

12.6.2.9.3 Outputs

a) Priority Code Point value for priority 0 with drop_eligible False: Integer in range 0–7.

b) Priority Code Point value for priority 0 with drop_eligible True: Integer in range 0–7.

c) Priority Code Point value for priority 1 with drop_eligible False: Integer in range 0–7.

d) Priority Code Point value for priority 1 with drop_eligible True: Integer in range 0–7.

e) Priority Code Point value for priority 2 with drop_eligible False: Integer in range 0–7.

f) Priority Code Point value for priority 2 with drop_eligible True: Integer in range 0–7.

g) Priority Code Point value for priority 3 with drop_eligible False: Integer in range 0–7.

h) Priority Code Point value for priority 3 with drop_eligible True: Integer in range 0–7.

i) Priority Code Point value for priority 4 with drop_eligible False: Integer in range 0–7.

j) Priority Code Point value for priority 4 with drop_eligible True: Integer in range 0–7.

k) Priority Code Point value for priority 5 with drop_eligible False: Integer in range 0–7.

l) Priority Code Point value for priority 5 with drop_eligible True: Integer in range 0–7.

m) Priority Code Point value for priority 6 with drop_eligible False: Integer in range 0–7.

n) Priority Code Point value for priority 6 with drop_eligible True: Integer in range 0–7.

o) Priority Code Point value for priority 7 with drop_eligible False: Integer in range 0–7.

p) Priority Code Point value for priority 7 with drop_eligible True: Integer in range 0–7.

12.6.2.10 Set Priority Code Point Encoding Table

12.6.2.10.1 Purpose

To modify the contents of a row in the Priority Code Point Encoding Table (6.9.3) for a Port.

12.6.2.10.2 Inputs

a) Port Number: the number of the Bridge Port.

b) Priority Code Point Row: this takes one of the following values:

1) 8P0D

2) 7P1D

3) 6P2D

4) 5P3D

c) Priority Code Point value for priority 0 with drop_eligible False: Integer in range 0–7.

d) Priority Code Point value for priority 0 with drop_eligible True: Integer in range 0–7.

e) Priority Code Point value for priority 1 with drop_eligible False: Integer in range 0–7.

f) Priority Code Point value for priority 1 with drop_eligible True: Integer in range 0–7.

g) Priority Code Point value for priority 2 with drop_eligible False: Integer in range 0–7.

h) Priority Code Point value for priority 2 with drop_eligible True: Integer in range 0–7.

i) Priority Code Point value for priority 3 with drop_eligible False: Integer in range 0–7.

j) Priority Code Point value for priority 3 with drop_eligible True: Integer in range 0–7.

k) Priority Code Point value for priority 4 with drop_eligible False: Integer in range 0–7.

l) Priority Code Point value for priority 4 with drop_eligible True: Integer in range 0–7.

m) Priority Code Point value for priority 5 with drop_eligible False: Integer in range 0–7.

n) Priority Code Point value for priority 5 with drop_eligible True: Integer in range 0–7.

o) Priority Code Point value for priority 6 with drop_eligible False: Integer in range 0–7.

p) Priority Code Point value for priority 6 with drop_eligible True: Integer in range 0–7.

q) Priority Code Point value for priority 7 with drop_eligible False: Integer in range 0–7.

r) Priority Code Point value for priority 7 with drop_eligible True: Integer in range 0–7.

12.6.2.10.3 Outputs

None.

12.6.2.11 Read Use_DEI Parameter

12.6.2.11.1 Purpose

To read the current state of the Use_DEI parameter (6.9.3) for the Port.

12.6.2.11.2 Inputs

a) Port Number: the number of the Bridge Port.

12.6.2.11.3 Outputs

a) Use_DEI parameter: Boolean.

12.6.2.12 Set Use_DEI Parameter

12.6.2.12.1 Purpose

To set the current state of the Use_DEI parameter (6.9.3) for the Port.

12.6.2.12.2 Inputs

a) Port Number: the number of the Bridge Port.

b) Use_DEI parameter: Boolean.

12.6.2.12.3 Outputs

None.

12.6.2.13 Read Require Drop Encoding Parameter

12.6.2.13.1 Purpose

To read the current state of the Require Drop Encoding parameter (8.6.6) for the Port.

12.6.2.13.2 Inputs

a) Port Number: the number of the Bridge Port.

12.6.2.13.3 Outputs

a) Require Drop Encoding parameter: Boolean.

12.6.2.14 Set Require Drop Encoding Parameter

12.6.2.14.1 Purpose

To set the current state of the Require Drop Encoding parameter (8.6.6) for the Port.

12.6.2.14.2 Inputs

a) Port Number: the number of the Bridge Port.

b) Require Drop Encoding parameter: Boolean.

12.6.2.14.3 Outputs

None.

12.6.2.15 Read Service Access Priority Selection

12.6.2.15.1 Purpose

To read the current state of whether Service Access Priority Selection is enabled (6.13) for the Port.

12.6.2.15.2 Inputs

a) Port Number: the number of the Bridge Port.

12.6.2.15.3 Outputs

a) Enable Service Access Priority Selection: the permissible values are as follows:

1) Enabled

2) Disabled

12.6.2.16 Set Service Access Priority Selection

12.6.2.16.1 Purpose

To enable or disable Service Access Priority Selection (6.13) for the Port.

12.6.2.16.2 Inputs

a) Port Number: the number of the Bridge Port.

b) Service Access Priority Selection: the permissible values are as follows:

1) Enabled

2) Disabled

12.6.2.16.3 Outputs

None.

12.6.2.17 Read Service Access Priority Table

12.6.2.17.1 Purpose

To read the current contents of the Service Access Priority Table (6.13.1) for the Port.

12.6.2.17.2 Inputs

a) Port Number: the number of the Bridge Port.

12.6.2.17.3 Outputs

a) Service Access Priority value for Received Priority 0: Integer in range 0–7.

b) Service Access Priority value for Received Priority 1: Integer in range 0–7.

c) Service Access Priority value for Received Priority 2: Integer in range 0–7.

d) Service Access Priority value for Received Priority 3: Integer in range 0–7.

e) Service Access Priority value for Received Priority 4: Integer in range 0–7.

f) Service Access Priority value for Received Priority 5: Integer in range 0–7.

g) Service Access Priority value for Received Priority 6: Integer in range 0–7.

h) Service Access Priority value for Received Priority 7: Integer in range 0–7.

12.6.2.18 Set Service Access Priority Table

12.6.2.18.1 Purpose

To modify the contents of the Service Access Priority Table (6.13.1) for the Port.

12.6.2.18.2 Inputs

a) Port Number: the number of the Bridge Port.

b) Service Access Priority value for Received Priority 0: Integer in range 0–7.

c) Service Access Priority value for Received Priority 1: Integer in range 0–7.

d) Service Access Priority value for Received Priority 2: Integer in range 0–7.

e) Service Access Priority value for Received Priority 3: Integer in range 0–7.

f) Service Access Priority value for Received Priority 4: Integer in range 0–7.

g) Service Access Priority value for Received Priority 5: Integer in range 0–7.

h) Service Access Priority value for Received Priority 6: Integer in range 0–7.

i) Service Access Priority value for Received Priority 7: Integer in range 0–7.

12.6.2.18.3 Outputs

None.

12.6.3 Traffic Class Table

The Traffic Class Table object models the operations that can be performed on, or inquire about, the current contents of the Traffic Class Table (8.6.6) for a given Port. The operations that can be performed on this object are Read Port Traffic Class Table and Set Port Traffic Class Table.

12.6.3.1 Read Port Traffic Class Table

12.6.3.1.1 Purpose

To read the contents of the Traffic Class Table (8.6.6) for a given Port.

12.6.3.1.2 Inputs

a) Port Number.

12.6.3.1.3 Outputs

a) The number of traffic classes, in the range 1 through 8, supported on the Port.

b) For each value of traffic class supported on the Port, the value of the traffic class in the range 0 through 7, and the set of priority values assigned to that traffic class.

12.6.3.2 Set Port Traffic Class Table

12.6.3.2.1 Purpose

To set the contents of the Traffic Class Table (8.6.6) for a given Port.

12.6.3.2.2 Inputs

a) Port number.

For each value of traffic class supported on the Port, the value of the traffic class in the range 0 through 7, and the set of priority values assigned to that traffic class.

NOTE—If a traffic class value greater than the largest traffic class available on the Port is specified, then the value applied to the Traffic Class Table is the largest available traffic class.

12.6.3.2.3 Outputs

None.

12.7 Filtering Database (FDB)

The FDB is described in 8.8. It contains filtering information used by the Forwarding Process (8.6) in deciding through which Ports of the Bridge frames should be forwarded.

The objects that comprise this managed resource are

a) The Filtering Database (12.7.1)

b) The Static Filtering Entries (12.7.2)

c) The Dynamic Filtering Entries (12.7.3)

d) The MAC Address Registration Entries (12.7.4)

e) The Static VLAN Registration Entries (12.7.5)

f) The Dynamic VLAN Registration Entries (12.7.5)

g) The Permanent Database (12.7.6)

12.7.1 The Filtering Database object

The Filtering Database object models the operations that can be performed on, or affect, the FDB as a whole. There is a single Filtering Database object per Bridge.

The management operations that can be performed on the Database are

a) Read Filtering Database (12.7.1.1)

b) Set Filtering Database Ageing Time (12.7.1.2)

c) Read Permanent Database (12.7.6.1)

d) Create Filtering Entry (12.7.7.1)

e) Delete Filtering Entry (12.7.7.2)

f) Read Filtering Entry (12.7.7.3)

g) Read Filtering Entry Range (12.7.7.4)

12.7.1.1 Read Filtering Database

12.7.1.1.1 Purpose

To obtain general information regarding the Bridge’s FDB.

12.7.1.1.2 Inputs

None.

12.7.1.1.3 Outputs

a) Filtering Database Size—the maximum number of entries that can be held in the FDB.

b) Number of Static Filtering Entries—the number of Static Filtering Entries (8.8.1) currently in the FDB.

c) Number of Dynamic Filtering Entries—the number of Dynamic Filtering Entries (8.8.3) currently in the FDB.

d) Number of Static VLAN Registration Entries—the number of Static VLAN Registration Entries (8.8.2) currently in the FDB.

e) Number of Dynamic VLAN Registration Entries—the number of Dynamic VLAN Registration Entries (8.8.5) currently in the FDB.

f) Ageing Time—for ageing out Dynamic Filtering Entries when the Port associated with the entry is in the Forwarding state (8.8.3).

g) If Extended Filtering Services are supported, Number of MAC Address Registration Entries—the number of MAC Address Registration Entries (8.8.4) currently in the FDB.

12.7.1.2 Set Filtering Database Ageing Time

12.7.1.2.1 Purpose

To set the ageing time for Dynamic Filtering Entries (8.8.3).

12.7.1.2.2 Inputs

a) Ageing Time.

12.7.1.2.3 Outputs

None.

12.7.2 A Static Filtering Entry object

A Static Filtering Entry object models the operations that can be performed on a single Static Filtering Entry in the FDB. The set of Static Filtering Entry objects within the FDB changes only under management control.

A Static Filtering Entry object supports the following operations:

a) Create Filtering Entry (12.7.7.1)

b) Delete Filtering Entry (12.7.7.2)

c) Read Filtering Entry (12.7.7.3)

d) Read Filtering Entry Range (12.7.7.4)

12.7.3 A Dynamic Filtering Entry object

A Dynamic Filtering Entry object models the operations that can be performed on a single Dynamic Filtering Entry (i.e., one that is created by the Learning Process as a result of the observation of network traffic) in the FDB.

A Dynamic Filtering Entry object supports the following operations:

a) Delete Filtering Entry (12.7.7.2)

b) Read Filtering Entry (12.7.7.3)

c) Read Filtering Entry Range (12.7.7.4)

12.7.4 A MAC Address Registration Entry object

A MAC Address Registration Entry object models the operations that can be performed on a single MAC Address Registration Entry in the FDB. The set of MAC Address Registration Entry objects within the FDB changes only as a result of MMRP exchanges.

A MAC Address Registration Entry object supports the following operations:

a) Read Filtering Entry (12.7.7.3)

b) Read Filtering Entry Range (12.7.7.4)

12.7.5 A VLAN Registration Entry object

A VLAN Registration Entry object models the operations that can be performed on a single VLAN Registration Entry in the FDB. The set of VLAN Registration Entry objects within the FDB changes under management control and also as a result of MVRP exchanges.

12.7.5.1 Static VLAN Registration Entry object

A Static VLAN Registration Entry object supports the following operations:

a) Create Filtering Entry (12.7.7.1)

b) Delete Filtering Entry (12.7.7.2)

c) Read Filtering Entry (12.7.7.3)

d) Read Filtering Entry Range (12.7.7.4)

12.7.5.2 Dynamic VLAN Registration Entry object

A Dynamic VLAN Registration Entry object supports the following operations:

a) Read Filtering Entry (12.7.7.3)

b) Read Filtering Entry Range (12.7.7.4)

12.7.6 Permanent Database object

The Permanent Database object models the operations that can be performed on, or affect, the Permanent Database. There is a single Permanent Database per FDB.

The management operations that can be performed on the Permanent Database are

a) Read Permanent Database (12.7.6.1)

b) Create Filtering Entry (12.7.7.1)

c) Delete Filtering Entry (12.7.7.2)

d) Read Filtering Entry (12.7.7.3)

e) Read Filtering Entry Range (12.7.7.4)

12.7.6.1 Read Permanent Database

12.7.6.1.1 Purpose

To obtain general information regarding the Permanent Database (8.8.11).

12.7.6.1.2 Inputs

None.

12.7.6.1.3 Outputs

a) Permanent Database Size—maximum number of entries that can be held in the Permanent Database.

b) Number of Static Filtering Entries—number of Static Filtering Entries (8.8.1) currently in the Permanent Database.

c) Number of Static VLAN Registration Entries—number of Static VLAN Registration Entries (8.8.2) currently in the Permanent Database.

12.7.7 General FDB operations

In these operations on the FDB, the operation parameters make use of VID values, even when operating on a Dynamic Filtering Entry (8.8.3) whose structure carries an FID rather than a VID. In this case, the value used in the VID parameter can be any VID that has been allocated to the FID concerned (8.8.8).

12.7.7.1 Create Filtering Entry

12.7.7.1.1 Purpose

To create or update a Static Filtering Entry (8.8.1) or Static VLAN Registration Entry (8.8.2) in the FDB or Permanent Database. Only static entries may be created in the FDB or Permanent Database.

12.7.7.1.2 Inputs

a) Identifier—FDB or Permanent Database.

b) Address—MAC address of the entry (not present in VLAN Registration Entries).

c) VID—VLAN Identifier of the entry.

d) Port Map—a set of control indicators, one for each Port, as specified in 8.8.1 and 8.8.2.

12.7.7.1.3 Outputs

a) Operation rejected because a Port identified by the Port Map includes a port already in the member set of a VID of a different type than the currently registered VID.

b) Operation rejected because the specified Static Filtering Entry is associated with and Infrastructure Protection Group (IPG) and is administered by IPS Control.

c) Operation rejected because the VID identifies an SPVID.

d) Operation accepted.

12.7.7.2 Delete Filtering Entry

12.7.7.2.1 Purpose

To delete a Filtering Entry or VLAN Registration Entry from the FDB or Permanent Database.

12.7.7.2.2 Inputs

a) Identifier—FDB or Permanent Database.

b) Address—MAC address of the desired entry (not present in VLAN Registration Entries).

c) VID—VLAN Identifier of the entry.

12.7.7.2.3 Outputs

None.

12.7.7.3 Read Filtering Entry

12.7.7.3.1 Purpose

To read a Filtering Entry, MAC Address Registration Entry, or VLAN Registration Entry from the Filtering or Permanent Databases.

12.7.7.3.2 Inputs

a) Identifier—FDB or Permanent Database.

b) Address—MAC address of the desired entry (not present in VLAN Registration Entries).

c) VID—VLAN Identifier of the entry.

d) Type—Static or Dynamic entry.

12.7.7.3.3 Outputs

a) Address—MAC address of the desired entry (not present in VLAN Registration Entries).

b) VID—VLAN Identifier of the entry.

c) Type—Static or Dynamic entry.

d) Port Map—a set of control indicators as appropriate for the entry (that may include a Connection Identifier), as specified in 8.8.1 through 8.8.5.

12.7.7.4 Read Filtering Entry range

12.7.7.4.1 Purpose

To read a range of FDB entries (of any type) from the Filtering or Permanent Databases.

Since the number of values to be returned in the requested range may have exceeded the capacity of the SDU conveying the management response, the returned entry range is identified. The indices that define the range take on values from zero up to Filtering Database Size minus one.

12.7.7.4.2 Inputs

a) Identifier—FDB or Permanent Database.

b) Start Index—inclusive starting index of the desired entry range.

c) Stop Index—inclusive ending index of the desired range.

12.7.7.4.3 Outputs

a) Start Index—inclusive starting index of the returned entry range.

b) Stop Index—inclusive ending index of the returned entry range.

c) For each index returned:

1) Address—MAC address of the desired entry (not present in VLAN Registration Entries).

2) VID—VLAN Identifier of the entry.

3) Type—Static or Dynamic entry.

4) Port Map—a set of control indicators as appropriate for the entry (that may include a Connection Identifier), as specified in 8.8.1 through 8.8.5.

12.8 Bridge Protocol Entity

The Bridge Protocol Entity is described in 8.10 and Clause 13.

The objects that comprise this managed resource are

a) The Protocol Entity

b) The Ports under its control

12.8.1 The Protocol Entity

The Protocol Entity object models the operations that can be performed on, or inquire about, the operation of STP. There is a single Protocol Entity per Bridge; it can therefore be identified as a single fixed component of the Protocol Entity resource.

The management operations that can be performed on the Protocol Entity are

a) Read CIST Bridge Protocol Parameters (12.8.1.1)

b) Read MSTI Bridge Protocol Parameters (12.8.1.2)

c) Set CIST Bridge Protocol Parameters (12.8.1.3)

d) Set MSTI Bridge Protocol Parameters (12.8.1.4)

12.8.1.1 Read CIST Bridge Protocol Parameters

12.8.1.1.1 Purpose

To obtain information regarding the Bridge’s Bridge Protocol Entity for the CIST.

12.8.1.1.2 Inputs

None.

12.8.1.1.3 Outputs

a) Bridge Identifier—as defined in 13.26.2. The Bridge Identifier for the CIST.

b) Time Since Topology Change—in an STP Bridge, the count in seconds of the time elapsed since the Topology Change flag parameter for the Bridge (8.5.3.12 of IEEE Std 802.1D, 1998 Edition [B9]) was last True, or in an RSTP or MSTP Bridge, the count in seconds since tcWhile timer (13.25) for any Port was nonzero.

c) Topology Change Count—in an STP Bridge, the count of the times the Topology Change flag parameter for the Bridge has been set (i.e., transitioned from False to True) since the Bridge was

powered on or initialized, or in an RSTP or MSTP Bridge, the count of times that there has been at least one nonzero tcWhile timer (13.25).

d) CIST Root Identifier (13.26.10).

e) CIST External Root Path Cost (13.26.10).

f) Root Port (13.26.9).

g) Max Age (13.26.11).

h) Forward Delay (13.26.11).

i) Bridge Max Age (13.26.4).

j) Bridge Hello Time (13.25). This parameter is present only if the Bridge supports STP or RSTP.

k) Bridge Forward Delay (13.26.4 ).

l) Hold Time (8.5.3.14 of IEEE Std 802.1D, 1998 Edition [B9]) or Transmission Limit (TxHoldCount in 13.26.12).

The following parameter is present only if the Bridge supports RSTP or MSTP:

m) forceVersion—the value of the Force Protocol Version parameter for the Bridge (13.7.2).

The following additional parameters are present only if the Bridge supports MSTP:

n) CIST Regional Root Identifier (13.26.10). The Bridge Identifier of the current CIST Regional Root.

o) CIST Path Cost (CIST Internal Root Path Cost, in 13.26.10). The CIST path cost from the transmitting Bridge to the CIST Regional Root.

p) MaxHops (13.26.4).

12.8.1.2 Read MSTI Bridge Protocol Parameters

12.8.1.2.1 Purpose

In an MST Bridge, to obtain information regarding the Bridge’s Bridge Protocol Entity for the specified spanning tree instance.

12.8.1.2.2 Inputs

a) MSTID—Identifies the set of parameters that will be returned. For Bridges that support MSTP, this parameter is the identifier of the spanning tree for which the operation is being performed. This parameter takes a value in the range 1 through 4094.

12.8.1.2.3 Outputs

a) MSTID—identifies the set of parameters that are being returned. This parameter is the identifier of the MST Instance for which the operation is being performed.

b) Bridge Identifier—as defined in 13.26.2. The Bridge Identifier for the spanning tree instance identified by the MSTID.

c) Time Since Topology Change—count in seconds of the time elapsed since tcWhile (13.25) was last nonzero for any Port for the given MSTI.

d) Topology Change Count—count of the times tcWhile (13.25) has been nonzero for any Port for the given MSTI since the Bridge was powered on or initialized.

e) Topology Change (tcWhile, 13.25). True if tcWhile is nonzero for any Port for the given MST.

f) Designated Root (MSTI Regional Root Identifier, 13.26.10). The Bridge Identifier of the Root Bridge for the spanning tree instance identified by the MSTID.

g) Root Path Cost (MSTI Internal Root Path Cost, 13.26.10). The path cost from the transmitting Bridge to the Root Bridge for the spanning tree instance identified by the MSTID.

h) Root Port (13.26.9). The Root Port for the spanning tree instance identified by the MSTID.

12.8.1.3 Set CIST Bridge Protocol Parameters

12.8.1.3.1 Purpose

To modify parameters in the Bridge’s Bridge Protocol Entity for the CIST, in order to force a configuration of the spanning tree and/or tune the reconfiguration time to suit a specific topology. In RSTP and MSTP implementations, this operation causes these values to be set for all Ports of the Bridge.

12.8.1.3.2 Inputs

a) Bridge Max Age—the new value (13.26.4).

b) Bridge Hello Time—the new value (13.25) This parameter is present only if the Bridge supports STP or RSTP.

c) Bridge Forward Delay—the new value (13.26.4).

d) Bridge Priority—the new value of the priority part of the Bridge Identifier (13.26.2) for the CIST.

The following parameters are present only if the Bridge supports RSTP or MSTP:

e) forceVersion—the new value of the Force Protocol Version parameter for the Bridge (13.7.2).

f) TxHoldCount—the new value of TxHoldCount (13.26.12).

The following parameter is present only if the Bridge supports MSTP:

g) MaxHops—the new value of MaxHops (13.26.4).

12.8.1.3.3 Outputs

a) Operation status. This takes one of the following values:

1) Operation rejected due to invalid Bridge Priority value (12.3); or

Operation rejected due to the specified Max Age, Hello Time, or Forward Delay values being outside the range specified for the parameter (see 12.8.1.3.4); or

3) Operation rejected due to the specified Max Age, Hello Time, or Forward Delay values not being in compliance with the requirements of this standard (see 12.8.1.3.4); or

4) Operation rejected due to the specified MaxHops value not being within the permitted range specified in Table 13-5; or

5) Operation accepted.

12.8.1.3.4 Procedure

In the following description, the references to Bridge Hello Time apply only to Bridges that support STP or RSTP.

The input parameter values are checked for compliance with their definitions in Clause 13. If they do not comply, or the value of Bridge Max Age or Bridge Forward Delay is less than the lower limit of the range specified in Table 13-5, then no action shall be taken for any of the supplied parameters. If the value of any of Bridge Max Age, Bridge Forward Delay, or Bridge Hello Time is outside the range specified in Table 13-5, then the Bridge need not take action.

Otherwise,

a) The Bridge’s Bridge Max Age, Bridge Hello Time, and Bridge Forward Delay parameters are set to the supplied values.

b) In STP Bridges, the Set Bridge Priority procedure (8.8.4 of IEEE Std 802.1D, 1998 Edition [B9]) is used to set the priority part of the Bridge Identifier to the supplied value.

c) In RSTP and MSTP Bridges, the priority component of the Bridge Identifier (13.26.2) is updated using the supplied value. For all Ports of the Bridge, the reselect for the CIST parameter (13.27) is set TRUE, and the selected parameter for the CIST (13.27) is set FALSE.

12.8.1.4 Set MSTI Bridge Protocol Parameters

12.8.1.4.1 Purpose

To modify parameters in the Bridge’s Bridge Protocol Entity for the specified spanning tree instance, in order to force a configuration of the spanning tree and/or tune the reconfiguration time to suit a specific topology.

12.8.1.4.2 Inputs

a) MSTID—identifies the set of parameters upon which the operation will be performed.

b) Bridge Priority—the new value of the priority part of the Bridge Identifier (13.26.2) for the spanning tree instance identified by the MSTID.

12.8.1.4.3 Outputs

a) Operation status. This takes one of the following values:

1) Operation rejected due to invalid Bridge Priority value (12.3); or

2) Operation rejected due to invalid MSTID (i.e, there is currently no MST Instance with that value of MSTID supported by the Bridge); or

3) Operation accepted.

12.8.1.4.4 Procedure

The Bridge Priority parameter value is checked for compliance with its definition in Clause 13. If it does not comply, then no action shall be taken.

Otherwise, the priority part of the Bridge Identifier is set to the supplied value for the specified spanning tree instance.

12.8.2 Bridge Port

A Bridge Port object models the operations related to an individual Bridge Port in relation to the operation of STP. There are a fixed set of Bridge Ports per Bridge; each can therefore be identified by a permanently allocated Port Number, as a fixed component of the Protocol Entity resource.

The management operations that can be performed on a Bridge Port are

a) Read CIST Port Parameters (12.8.2.1)

b) Read MSTI Port Parameters (12.8.2.2)

c) Set CIST Port Parameters (12.8.2.3)

d) Set MSTI Port Parameters (12.8.2.4)

e) Force BPDU Migration Check (12.8.2.5)

12.8.2.1 Read CIST Port Parameters

12.8.2.1.1 Purpose

To obtain information regarding a specific Port within the Bridge’s Bridge Protocol Entity, for the CIST.

12.8.2.1.2 Inputs

a) Port Number—the number of the Bridge Port.

12.8.2.1.3 Outputs

a) Uptime—count in seconds of the time elapsed since the Port was last reset or initialized (BEGIN, 13.26).

b) Port State—Discarding, Listening, Learning, or Forwarding (8.4).

c) Port Identifier—the unique Port identifier comprising two parts, the Port Number and the Port Priority field (13.27.46).

d) Path Cost (ExternalPortPathCost, 13.27.25).

e) Designated Root (CIST Root Identifier, 13.27.20).

f) Designated Cost (External Root Path Cost, 13.27.20).

g) Designated Bridge (13.27.20).

h) Designated Port (13.27.20).

i) Topology Change Acknowledge (13.27.72).

j) Hello Time (13.27.48).

k) adminEdgePort (13.27.1). Present in implementations that support the identification of edge ports.

l) operEdgePort (13.27.44). Present in implementations that support the identification of edge ports.

m) autoEdgePort (13.27.6). Optional and provided only in implementations that support the automatic identification of edge ports.

n) autoIsolatePort (13.27.19). Present in implementations that support detection of fragile Bridges.

o) isolatePort (13.27.27). Present in implementations that support detection of fragile Bridges.

p) MAC Enabled—the current state of the MAC Enabled parameter (IEEE Std 802.1AC). Present if the implementation supports the MAC Enabled parameter.

q) MAC Operational—the current state of the MAC Operational parameter (IEEE Std 802.1AC). Present if the implementation supports the MAC Operational parameter.

r) adminPointToPointMAC—the current state of the adminPointToPointMAC parameter (IEEE Std 802.1AC). Present if the implementation supports the adminPointToPointMAC parameter.

s) operPointToPointMAC—the current state of the operPointToPointMAC parameter (IEEE Std 802.1AC). Present if the implementation supports the operPointToPointMAC parameter.

t) restrictedRole—the current state of the restrictedRole parameter for the Port (13.27.63).

u) restrictedTcn—the current state of the restrictedTcn parameter for the Port (13.27.65).

v) Port Role—the current Port Role for the Port (i.e., Root, Alternate, Designated, or Backup)

w) Disputed—the current value of the disputed variable for the CIST for the Port (13.27.22).

x) enableBPDUrx—the value of enableBPDUrx (13.27.23).

y) enableBPDUtx—the value of enableBPDUtx (13.27.24).

z) pseudoRootId—the value of Bridge Identifier used by the L2 gateway protocol (13.27.51).

aa) isL2gp—the value of isL2gp (13.27.26).

The following additional parameters are present only if the Bridge supports MSTP:

ab) CIST Regional Root Identifier (13.26.10). The Bridge Identifier of the current CIST Regional Root.

ac) CIST Path Cost (CIST Internal Root Path Cost, in 13.26.10). The CIST path cost from the transmitting Bridge to the CIST Regional Root.

ad) Port Hello Time. The administrative value of Hello Time for the Port (13.27.48).

12.8.2.2 Read MSTI Port Parameters

12.8.2.2.1 Purpose

To obtain information regarding a specific Port within the Bridge’s Bridge Protocol Entity, for a given MSTI.

12.8.2.2.2 Inputs

a) Port Number—the number of the Bridge Port.

b) MSTID—identifies the set of parameters that will be returned, in the range 1 through 4094.

12.8.2.2.3 Outputs

a) MSTID—identifies the set of parameters that are being returned. This parameter is the identifier of the spanning tree for which the operation is being performed.

b) Uptime—count in seconds of the time elapsed since the Port was last reset or initialized (BEGIN).

c) State—the current state of the Port (i.e., Disabled, Listening, Learning, Forwarding, or Blocking) (8.4, 13.38).

d) Port Identifier—the unique Port identifier comprising two parts, the Port Number and the Port Priority field (13.27.46).

e) Path Cost (13.27.20).

f) Designated Root (13.27.20).

g) Designated Cost (13.27.20).

h) Designated Bridge (13.27.20).

i) Designated Port (13.27.20).

j) Port Role—the current Port Role for the Port (i.e., Root, Alternate, Designated, or Backup, 13.27.66)

k) Disputed—the current value of the disputed variable (13.27.22).

l) pseudoRootId—the new value of Bridge Identifier used by the L2 gateway protocol (13.27.51).

12.8.2.3 Set CIST port parameters

12.8.2.3.1 Purpose

To modify parameters for a Port in the Bridge’s Bridge Protocol Entity in order to force a configuration of the spanning tree for the CIST.

12.8.2.3.2 Inputs

a) Port Number—the number of the Bridge Port.

b) Path Cost—the new ExternalPortPathCost (13.27.25).

c) Port Priority—the new value of the priority field for the Port Identifier (13.27.46).

d) adminEdgePort—the new value of the adminEdgePort parameter (13.27.1). Present in implementations that support the identification of edge ports.

e) autoEdgePort—the new value of the autoEdgePort parameter (13.27.6). Optional and provided only in implementations that support the automatic identification of edge ports. .

f) autoIsolatePort—the new value of the autoIsolatePort parameter (13.27.19). Present in implmentations that suppport detection of fragile Bridges.

g) MAC Enabled—the new value of the MAC Enabled parameter (IEEE Std 802.1AC). May be present if the implementation supports the MAC Enabled parameter.

h) adminPointToPointMAC—the new value of the adminPointToPointMAC parameter (IEEE Std 802.1AC). May be present if the implementation supports the adminPointToPointMAC parameter.

i) restrictedRole—the new value of the restrictedRole parameter for the Port (13.27.63).

j) restrictedTcn—the new value of the restrictedTcn parameter for the Port (13.27.65).

k) enableBPDUrx—the new value of enableBPDUrx (13.27.23).

l) enableBPDUtx—the new value of enableBPDUtx (13.27.24).

m) pseudoRootId—the new value of Bridge Identifier used by the L2 gateway protocol (13.27.51).

n) isL2gp—the new value of isL2gp (13.27.26).

12.8.2.3.3 Outputs

a) Operation status. This takes one of the following values:

1) Operation rejected due to invalid Port Priority value (12.3); or

2) Operation accepted.

12.8.2.3.4 Procedure

In STP Bridges, the Set Path Cost procedure (8.8.6 of IEEE Std 802.1D, 1998 Edition [B9]) is used to set the Path Cost parameter for the specified Port for the specified spanning tree instance. The Set Port Priority procedure (8.8.5 of IEEE Std 802.1D, 1998 Edition [B9]) is used to set the priority part of the Port Identifier (8.5.5.1 of IEEE Std 802.1D, 1998 Edition [B9]) for the CIST to the supplied value.

In RSTP and MSTP Bridges, the Path Cost (13.27.25) and Port Priority (13.27.47) parameters for the Port are updated using the supplied values. The reselect parameter value for the CIST for the Port (13.27.62) is set TRUE, and the selected parameter for the CIST for the Port (13.27.67) is set FALSE.

12.8.2.4 Set MSTI port parameters

12.8.2.4.1 Purpose

To modify parameters for a Port in the Bridge’s Bridge Protocol Entity in order to force a configuration of the spanning tree for the specified spanning tree instance.

12.8.2.4.2 Inputs

a) MSTID—identifies the set of parameters upon which the operation will be performed. This parameter is the identifier of the spanning tree for which the operation is being performed.

b) Port Number—the number of the Bridge Port.

c) Path Cost—the new value (13.27.25).

d) Port Priority—the new value of the priority field for the Port Identifier (13.27.46).

e) pseudoRootId—the new value of Bridge Identifier used by the L2 gateway protocol (13.27.51).

12.8.2.4.3 Outputs

a) Operation status. This takes one of the following values:

1) Operation rejected due to invalid Port Priority value (12.3); or

2) Operation rejected due to invalid MSTID (i.e, there is currently no spanning tree instance with that value of MSTID supported by the Bridge); or

3) Operation accepted.

12.8.2.4.4 Procedure

The Path Cost (13.27.25) and Port Priority (13.27.47) parameters for the specified MSTI and Port are updated using the supplied values. The reselect parameter value for the MSTI for the Port (13.27.62) is set TRUE, and the selected parameter for the MSTI for the Port (13.27.67) is set FALSE.

12.8.2.5 Force BPDU Migration Check

This operation is available only in Bridges that support RSTP or MSTP, as specified in Clause 13.

12.8.2.5.1 Purpose

To force the specified Port to transmit Rapid Spanning Tree (RST) or MST BPDUs (see 13.32).

12.8.2.5.2 Inputs

a) Port Number—the number of the Bridge Port.

12.8.2.5.3 Outputs

None.

12.8.2.5.4 Procedure

The mcheck variable (13.27.38) for the specified Port is set to the value TRUE if the value of the forceVersion variable (13.7.2) is greater than or equal to 2.

12.9 MRP Entities

The operation of MRP is described in Clause 10.

The objects that comprise this managed resource are

a) The MRP Timer objects (12.9.1)

b) The MRP Attribute Type objects (12.9.2)

c) The Periodic State Machine objects (12.9.3)

12.9.1 The MRP Timer object

The MRP Timer object models the operations that can be performed on, or inquire about, the current settings of the timers used by MRP on a given Port. The management operations that can be performed on the MRP Participant are

a) Read MRP Timers (12.9.1.1)

b) Set MRP Timers (12.9.1.2)

NOTE—The MRP timer values modeled by this object are the values used to initialize timer instances that are used within the MRP state machines, not the timer instances themselves. Hence, there is a single MRP Timer object per Port, regardless of whether the Bridge supports single or multiple spanning trees.

12.9.1.1 Read MRP Timers

12.9.1.1.1 Purpose

To read the current MRP Timers for a given Port.

12.9.1.1.2 Inputs

a) The Port identifier.

12.9.1.1.3 Outputs

a) Current value of JoinTime—Centiseconds, Persistent. (10.7.4.1 and 10.7.11).

b) Current value of LeaveTime—Centiseconds, Persistent. (10.7.4.2 and 10.7.11).

c) Current value of LeaveAllTime—Centiseconds, Persistent. (10.7.4.3 and 10.7.11).

12.9.1.2 Set MRP Timers

12.9.1.2.1 Purpose

To set new values for the MRP Timers for a given Port.

12.9.1.2.2 Inputs

a) The Port identifier.

b) New value of JoinTime—Centiseconds (10.7.4.1 and 10.7.11).

c) New value of LeaveTime—Centiseconds (10.7.4.2 and 10.7.11).

d) New value of LeaveAllTime—Centiseconds (10.7.4.3 and 10.7.11).

12.9.1.2.3 Outputs

None.

12.9.2 The MRP Attribute Type object

The MRP Attribute Type object models the operations that can be performed on, or inquire about, the operation of MRP for a given Attribute Type (10.8.2.2). The management operations that can be performed on an MRP Attribute Type are

a) Read MRP Applicant Controls (12.9.2.1)

b) Set MRP Applicant Controls (12.9.2.2)

12.9.2.1 Read MRP Applicant Controls

12.9.2.1.1 Purpose

To read the current values of the MRP Applicant Administrative control parameters (10.7.3) and Transmit Zero parameters (11.2.3.1.7) associated with all MRP Participants for a given Port, MRP Application, and Attribute Type.

12.9.2.1.2 Inputs

a) The Port identifier.

b) The MRP Application.

c) The Attribute Type (10.8.2.2).

12.9.2.1.3 Outputs

a) The current Applicant Administrative Control Value, Persistent. (10.7.3);

b) Failed Registrations—count of the number of times that this MRP Application has failed to register an attribute of this type due to lack of space in the FDB, Persistent. (12.10.1.6).

c) Transmit zero enable—whether the transmission of 0 as an Attribute value is currently enabled (MVRP only). (11.2.3.1.7).

12.9.2.2 Set MRP Applicant Controls

12.9.2.2.1 Purpose

To set new values for the MRP Applicant Administrative control parameters (10.7.3) and Transmit Zero parameters (11.2.3.1.7) associated with all MRP Participants for a given Port, MRP Application, and Attribute Type.

12.9.2.2.2 Inputs

a) The Port identifier

b) The MRP Application

c) The Attribute Type (10.8.2.2) associated with the state machine

d) The desired Applicant Administrative Control Value (10.7.3)

e) The desired Transmit zero enable value (MVRP only) (11.2.3.1.7)

12.9.2.2.3 Outputs

None.

12.9.2.2.4 Procedures

A Bridge shall not allow both MIRP and MVRP to be enabled on the same VIP.

12.9.3 Periodic state machine objects

The Periodic state machine object models the operations that can be performed upon, or inquire about, the operation of the Periodic state machine for a given Port.

The management operations that can be performed on a Periodic state machine are Read Periodic state machine state and Set Periodic state machine state.

12.9.3.1 Read Periodic state machine state

12.9.3.1.1 Purpose

To inquire whether a particular Periodic state machine is enabled or disabled.

12.9.3.1.2 Inputs

a) The Port identifier.

12.9.3.1.3 Outputs

a) The Port identifier.

b) The state of the Periodic state machine. This can take either of the values “enabled” or “disabled.”

12.9.3.2 Set Periodic state machine state

12.9.3.2.1 Purpose

To enable or disable a particular Periodic state machine.

12.9.3.2.2 Inputs

a) The Port identifier.

b) The desired state of the Periodic state machine. This can take either of the values “enabled” or “disabled.”

12.9.3.2.3 Outputs

None.

12.10 Bridge VLAN managed objects

The following managed objects define the semantics of the management operations that can be performed on the VLAN aspects of a Bridge:

a) The Bridge VLAN Configuration managed object (12.10.1)

b) The VLAN Configuration managed object (12.10.2)

c) The VID to FID allocation managed object (12.10.3)

12.10.1 Bridge VLAN Configuration managed object

The Bridge VLAN Configuration managed object models operations that modify, or inquire about, the overall configuration of the Bridge’s VLAN resources. There is a single Bridge VLAN Configuration managed object per Bridge.

The management operations that can be performed on the Bridge VLAN Configuration managed object are

a) Read Bridge VLAN Configuration (12.10.1.1)

b) Configure PVID and VID Set values (12.10.1.2)

c) Configure Acceptable Frame Types parameters (12.10.1.3)

d) Configure Enable Ingress Filtering parameters (12.10.1.4)

e) Reset Bridge (12.10.1.5)

f) Configure Restricted_VLAN_Registration parameters (12.10.1.6)

g) Configure Protocol Group Database (12.10.1.7)

h) Configure VID to FID allocation (12.10.3)

i) Configure VID Translation Table (12.10.1.8)

j) Configure Egress VID Translation Table (12.10.1.9)

12.10.1.1 Read Bridge VLAN Configuration

12.10.1.1.1 Purpose

To obtain general VLAN information from a Bridge.

12.10.1.1.2 Inputs

None.

12.10.1.1.3 Outputs

a) The IEEE 802.1Q VLAN Version number. Reported as “1” by Bridges that support only SST operation, and reported as “2” by Bridges that support MST operation.

NOTE—No IEEE 802.1Q VLAN version numbers other than 1 and 2 are currently specified.

b) The optional VLAN features supported by the implementation:

1) The maximum number of VIDs supported;

2) Whether the implementation supports the ability to override the default PVID setting, and its egress status (VLAN-tagged or untagged) on each Port;

3) For a Bridge that supports Port-and-Protocol-based VLAN classification, which of the Protocol Template formats (6.12.1) are supported by the implementation.

4) For MST Bridges, the maximum number of MSTIs supported within an MST Region (i.e., the number of spanning tree instances that can be supported in addition to the CIST). For SST Bridges, this parameter may be either omitted or reported as “0.”

c) For each Port:

1) The Port number;

2) The PVID value (6.9) currently assigned to that Port;

3) For a Bridge that supports Port-and-Protocol-based VLAN classification, whether the implementation supports Port-and-Protocol-based VLAN classification on that Port;

4) For a Bridge that supports Port-and-Protocol-based VLAN classification on that Port, the maximum number of entries supported in the VID Set on that Port; the VID value and Protocol Group Identifier currently assigned to each entry in the VID Set (8.6.2) on that Port;

5) The state of the Acceptable Frame Types parameter (6.9). The permissible values for this parameter are

i) Admit Only VLAN-tagged frames;

ii) Admit Only Untagged and Priority Tagged frames;

iii) Admit All frames.

6) The state of the Enable Ingress Filtering parameter (6.9); Enabled or Disabled;

7) The state of the Restricted_VLAN_Registration parameter (11.2.3.2.3), TRUE or FALSE.

8) Whether the Bridge supports a VID Translation Table on that Port; whether the Bridge supports an Egress VID Translation Table on that Port;

For a Bridge that supports a VID Translation Table on that Port, a set of (Local VID, Relay VID) bindings (6.9);

10) For a Bridge that supports an Egress VID Translation Table on that Port, a set of (Relay VID, Local VID) bindings (6.9).

d) For a Bridge that supports Port-and-Protocol-based VLAN classification: the contents of the Protocol Group Database comprising a set of {Protocol Template, Protocol Group Identifier} bindings (6.12.1, 6.12.2, and 6.12.3); the maximum number of entries supported in the Protocol Group Database.

12.10.1.2 Configure PVID and VID Set values

12.10.1.2.1 Purpose

To configure the PVID and VID Set value(s) (6.9) associated with one or more Ports.

12.10.1.2.2 Inputs

a) For each Port to be configured, a Port number and the PVID value to be associated with that Port.

In addition, for a Bridge that supports Port-and-Protocol-based VLAN classification: for each Port to be configured, a Port number, a Protocol Group Identifier, and a VID value for the member of the Port’s VID Set that is to be configured.

12.10.1.2.3 Outputs

a) Operation status for each Port to be configured. This takes one of the following values:

1) Operation rejected due to there being no spare VID Set entries on this Port; or

2) Operation rejected due to the PVID or VID being out of the supported range for this Port; or

3) Operation accepted.

12.10.1.3 Configure Acceptable Frame Types parameters

12.10.1.3.1 Purpose

To configure the Acceptable Frame Types parameter (6.9) associated with one or more Ports.

12.10.1.3.2 Inputs

a) For each Port to be configured, a Port number and the value of the Acceptable Frame Types parameter to be associated with that Port. The permissible values of this parameter are (as defined in 6.9):

1) Admit Only VLAN-tagged frames

2) Admit Only Untagged and Priority Tagged frames

3) Admit All frames

12.10.1.3.3 Outputs

None.

12.10.1.4 Configure Enable Ingress Filtering parameters

12.10.1.4.1 Purpose

To configure the Enable Ingress Filtering parameter(s) (8.6.2) associated with one or more Ports.

12.10.1.4.2 Inputs

a) For each Port to be configured, a Port number and the value of the Enable Ingress Filtering parameter to be associated with that Port. The permissible values for the parameter are

1) Enabled

2) Disabled

12.10.1.4.3 Outputs

None.

12.10.1.5 Reset Bridge

12.10.1.5.1 Purpose

To reset all statically configured VLAN-related information in the Bridge to its default state. This operation

a) Deletes all VLAN Configuration managed objects.

b) Resets the PVID associated with each Bridge Port to the Default PVID value (Table 9-2).

c) Removes all entries in the Protocol Group Database and removes all members of the VID Set on each port, for a Bridge that supports Port-and-Protocol-based VLAN classification.

d) Resets the Acceptable Frame Types parameter value associated with each Port to the default value (6.9).

12.10.1.5.2 Inputs

None.

12.10.1.5.3 Outputs

None.

12.10.1.6 Configure Restricted_VLAN_Registration parameters

12.10.1.6.1 Purpose

To configure the Restricted_VLAN_Registration parameter (11.2.3.2.3) associated with one or more Ports.

12.10.1.6.2 Inputs

a) For each Port to be configured, a Port number and the value of the Restricted_VLAN_Registration parameter. The permissible values of this parameter are (as defined in 11.2.3.2.3) as follows:

1) TRUE

2) FALSE

12.10.1.6.3 Outputs

None.

12.10.1.7 Configure Protocol Group Database

To configure a Protocol Group Database (6.12.3) entry. This operation is not applicable to a Bridge that does not support Port-and-Protocol-based VLAN classification.

NOTE—Implementation of the Configure Protocol Group Database operation is not mandatory; conformant implementations may implement a fixed set of Protocol Group Database entries.

12.10.1.7.1 Inputs

a) A value representing the frame format to be matched: Ethernet, RFC_1042, SNAP_8021H, SNAP_Other or LLC_Other (6.12.1).

b) One of

1) An IEEE 802.3 EtherType value, for matching frame formats of Ethernet, RFC_1042, or SNAP_8021H;

2) A 40-bit Protocol Identifier (PID), for matching frame formats of SNAP_Other;

3) A pair of ISO/IEC 8802-2 DSAP and SSAP address field values, for matching frame formats of LLC_Other.

c) A Protocol Group Identifier (6.12.2).

NOTE—While the intent is to identify VID traffic, an ID of 0 may be used to indicate untagged traffic that needs prioritization.

12.10.1.7.2 Outputs

a) Operation status. This takes one of the following values:

1) Operation rejected due to there being no spare Protocol Group Database entries; or

2) Operation rejected due to an unsupported frame format; or

3) Operation rejected due to an unsupported value for an IEEE 802.3 EtherType value, PID, DSAP, or SSAP; or

4) Operation accepted.

12.10.1.8 VID Translation Configuration managed object

To configure the VID Translation Table (6.9) associated with a Port. This object is not applicable to Ports that do not support a VID Translation Table. The default configuration of the table has the value of the Relay VID equal to the value of the Local VID for all Local VID values. If the port supports an Egress VID translation table, the VID Translation Configuration object configures the Local VID to Relay VID mapping on ingress only. If an Egress VID translation is not supported, the VID Translation Configuration object defines a single bidirectional mapping.

The management operations that can be performed are as follows:

a) Read VID Translation Table Entry (12.10.1.8.1)

b) Configure VID Translation Table Entry (12.10.1.8.2)

12.10.1.8.1 Read VID Translation Table Entry

12.10.1.8.1.1 Purpose

To read the relay VID associated with the local VID.

12.10.1.8.1.2 Inputs

a) Port Number: the number of the port that is capable of performing VID translation.

b) Local VLAN Identifier: a 12-bit VID.

12.10.1.8.1.3 Outputs

a) Relay VLAN Identifier: a 12-bit VID.

12.10.1.8.2 Configure VID Translation Table Entry

12.10.1.8.2.1 Purpose

To modify an entry in the VID Translation Table.

12.10.1.8.2.2 Inputs

a) Port Number: the number of the port that is capable of performing VID translation. This port should be at the edge of an administrative or a control protocol domain (6.9).

b) Local VLAN Identifier: a 12-bit VID.

c) Relay VLAN Identifier: a 12-bit VID.

12.10.1.8.2.3 Outputs

a) Operation status. This takes one of the following values:

1) Operation rejected because the port does not have Egress VID translation capabilities.

2) Operation accepted.

12.10.1.9 Egress VID Translation Configuration managed object

To configure the Egress VID Translation Table (6.9) associated with a Port. This object is not applicable to Ports that do not support an Egress VID Translation Table. The default configuration of the table has the value of the Local VID equal to the value of the Relay VID for all Relay VID values.

The management operations that can be performed are as follows:

a) Read Egress VID Translation Table Entry (12.10.1.9.1)

b) Configure Egress VID Translation Table Entry (12.10.1.9.2)

12.10.1.9.1 Read Egress VID Translation Table Entry

12.10.1.9.1.1 Purpose

To read the local VID associated with the relay VID.

12.10.1.9.1.2 Inputs

a) Port Number: the number of the port that is capable of performing Egress VID translation.

b) Relay VLAN Identifier: a 12-bit VID.

12.10.1.9.1.3 Outputs

a) Local VLAN Identifier: a 12-bit VID.

12.10.1.9.2 Configure Egress VID Translation Table Entry

12.10.1.9.2.1 Purpose

To modify an entry in the Egress VID Translation Table.

12.10.1.9.2.2 Inputs

a) Port Number: the number of the port that is capable of performing Egress VID translation. This port should be at the edge of an administrative or a control protocol domain (6.9).

b) Relay VLAN Identifier: a 12-bit VID.

c) Local VLAN Identifier: a 12-bit VID.

12.10.1.9.2.3 Outputs

a) Operation rejected because the port does not have Egress VID translation capabilities.

b) Operation accepted.

12.10.2 VLAN Configuration managed object

The VLAN Configuration object models operations that modify, or inquire about, the configuration of a particular VID within a Bridge. There are multiple VLAN Configuration objects per Bridge; only one such object can exist for a given VID.

The management operations that can be performed on the VLAN Configuration are

a) Read VLAN Configuration (12.10.2.1)

b) Create VLAN Configuration (12.10.2.2)

c) Delete VLAN Configuration (12.10.2.3)

12.10.2.1 Read VLAN Configuration

12.10.2.1.1 Purpose

To obtain general information regarding a specific VLAN Configuration.

12.10.2.1.2 Inputs

a) VLAN Identifier: a 12-bit VID.

12.10.2.1.3 Outputs

a) VLAN Name: A text string of up to 32 characters of locally determined significance.

b) List of Untagged Ports: The set of Port numbers in the untagged set (8.8.2) for this VID.

c) List of Egress Ports: The set of Port numbers in the member set (8.8.10) for this VID.

NOTE—The values of the member set and the untagged set are determined by the values held in VLAN Registration Entries in the FDB (8.8.2, 8.8.5, and 8.8.10).

12.10.2.2 Create VLAN Configuration

12.10.2.2.1 Purpose

To create or update a VLAN Configuration managed object.

12.10.2.2.2 Inputs

a) VLAN Identifier: a 12-bit VID.

b) VLAN Name: a text string of up to 32 characters of locally determined significance.

NOTE—Static configuration of the member set and the Untagged set is achieved by means of the management operations for manipulation of VLAN Registration Entries (12.7.5).

12.10.2.2.3 Outputs

None.

12.10.2.3 Delete VLAN Configuration

12.10.2.3.1 Purpose

To delete a VLAN Configuration managed object.

12.10.2.3.2 Inputs

a) VLAN Identifier: a 12-bit VID.

12.10.2.3.3 Outputs

None.

12.10.3 The VID to FID allocation managed object

The VID to FID allocations managed object models operations that modify, or inquire about VID to FID allocations (8.8.8) that apply to the operation of the Learning Process and the FDB. The object is modeled as a fixed-length table, as follows:

a) A VID to FID allocation table (8.8.8) with an entry per VID supported by the implementation. Each table entry indicates, for that VID, that there is currently

1) No allocation defined; or

2) A fixed allocation to FID X; or

3) A dynamic allocation to FID X.

The management operations that can be performed on the VID to FID allocations managed object are

b) Read VID to FID allocations (12.10.3.1)

c) Read FID allocation for VID (12.10.3.2)

d) Read VIDs allocated to FID (12.10.3.3)

e) Set VID to FID allocation (12.10.3.4)

f) Delete VID to FID allocation (12.10.3.5)

12.10.3.1 Read VID to FID allocations

12.10.3.1.1 Purpose

To read the contents of a range of one or more entries in the VID to FID allocation table.

12.10.3.1.2 Inputs

a) First Entry—VID of first entry to be read.

b) Last Entry—VID of last entry to be read.

12.10.3.1.3 Outputs

a) List of Entries—For each entry that was read:

1) VID—the VLAN Identifier for this entry.

2) Allocation Type—the type of the allocation: Undefined, Fixed or Dynamic.

3) FID—the FID to which the VID is allocated (if not of type Undefined).

NOTE 1—Where this operation is implemented using a remote management protocol, PDU size constraints may restrict the number of entries that are actually read to fewer than was requested in the input parameters. In such cases, retrieving the remainder of the desired entry range can be achieved by repeating the operation with a modified entry range specification.

NOTE 2—The Allocation Type of Dynamic is applicable only for SPT Bridges and VIDs that have been reserved for use as SPVIDs.

12.10.3.2 Read FID allocation for VID

12.10.3.2.1 Purpose

To read the FID to which a specified VID is currently allocated.

12.10.3.2.2 Inputs

a) VID—the VLAN Identifier to which the read operation applies.

12.10.3.2.3 Outputs

a) VID—the VLAN Identifier to which the read operation applies.

b) Allocation Type—the type of the allocation: Undefined, Fixed or Dynamic.

c) FID—the FID to which the VID is allocated (if not of type Undefined).

NOTE—The Allocation Type of Dynamic is applicable only for SPT Bridges and VIDs that have been reserved for use as SPVIDs.

12.10.3.3 Read VIDs allocated to FID

12.10.3.3.1 Purpose

To read all VIDs currently allocated to a given FID.

12.10.3.3.2 Inputs

a) FID—the Filtering Identifier to which the read operation applies.

12.10.3.3.3 Outputs

a) FID—the Filtering Identifier to which the read operation applies

b) Allocation List—a list of allocations for this FID. For each element in the list:

1) Allocation Type—the type of the allocation: Fixed or Dynamic.

2) VID—the VID that is allocated.

NOTE—The Allocation Type of Dynamic is applicable only for SPT Bridges and VIDs that have been reserved for use as SPVIDs.

12.10.3.4 Set VID to FID allocation

12.10.3.4.1 Purpose

To establish a fixed allocation of a VID to an FID.

12.10.3.4.2 Inputs

a) VID—the VID of the entry to be set.

b) FID—the FID to which the VID is to be allocated.

12.10.3.4.3 Outputs

a) Operation status. This takes one of the following values:

1) Operation rejected due to VID exceeding the maximum VID supported by the allocation table; or

2) Operation rejected due to FID exceeding the maximum ID supported by the implementation; or

3) Operation accepted.

12.10.3.4.4 Procedure

In MST Bridges, the Configuration Digest element of the MCID is recalculated, in accordance with the definition in 13.8, following any change in the allocation of VIDs to FIDs that results in a change in the allocation of VIDs to spanning trees.

12.10.3.5 Delete VID to FID allocation

12.10.3.5.1 Purpose

To remove a fixed VID to FID allocation from the VID to FID allocation table. This operation has the effect of setting the value of the specified table entry to “Undefined.”

NOTE—If the VID concerned represents a currently active VID, then removal of a fixed allocation may result in the “Undefined” value in the table immediately being replaced by a dynamic allocation to an FID.

12.10.3.5.2 Inputs

a) VID—VID of the allocation to be deleted.

12.10.3.5.3 Outputs

a) Operation status. This takes one of the following values:

1) Operation rejected due to VID exceeding the maximum value supported by the allocation table; or

2) Operation accepted.

12.10.3.5.4 Procedure

In MST Bridges, the Configuration Digest element of the MCID is recalculated, in accordance with the definition in 13.8, and the MSTP state machine variables are reinitialized by asserting BEGIN, following any change in the allocation of VIDs to FIDs that results in a change in the allocation of VIDs to spanning trees.

12.11 MMRP entities

The following managed objects define the semantics of the management operations that can be performed on the operation of MMRP in a Bridge:

a) The MMRP Configuration managed object (12.11.1)

12.11.1 MMRP Configuration managed object

The MMRP Configuration managed object models operations that modify, or inquire about, the overall configuration of the operation of MMRP. There is a single MMRP Configuration managed object per Bridge.

The management operations that can be performed on the MMRP Configuration managed object are as follows:

a) Read MMRP Configuration (12.11.1.1)

b) Notify MAC address registration failure (12.11.1.2)

c) Configure Restricted_MAC_Address_Registration parameters (12.11.1.3)

12.11.1.1 Read MMRP Configuration

12.11.1.1.1 Purpose

To obtain general MMRP configuration information from a Bridge.

12.11.1.1.2 Inputs

None.

12.11.1.1.3 Outputs

a) For each Port:

1) The Port number.

2) The state of the Restricted_MAC_Address_Registration parameter, Persistent. (10.12.2.3), TRUE or FALSE.

12.11.1.2 Notify MAC address registration failure

12.11.1.2.1 Purpose

To notify a manager that MMRP has failed to register a given MAC address owing to lack of resources in the FDB for the creation of a MAC Address Registration Entry (8.8.4) or to the Restricted_MAC_Address_Registration parameter.

12.11.1.2.2 Inputs

None.

12.11.1.2.3 Outputs

a) The MAC address that MMRP failed to register;

b) The Port number of the Port on which the registration request was received.

c) The reason for the failure:

1) Lack of Resources; or

2) Registration Restricted.

12.11.1.3 Configure Restricted_MAC_Address_Registration parameters

12.11.1.3.1 Purpose

To configure the Restricted_MAC_Address_Registration parameter (10.12.2.3) associated with one or more Ports.

12.11.1.3.2 Inputs

a) For each Port to be configured, a Port number and the value of the Restricted_MAC_Address_Registration parameter. The permissible values of this parameter are (as defined in 10.12.2.3):

1) TRUE

2) FALSE

12.11.1.3.3 Outputs

None.

12.12 MST configuration entities

The following managed objects define the semantics of the management operations that can be performed on the MST configuration in a Bridge:

a) The MSTI List object (12.12.1)

b) The FID to MSTID Allocation Table object (12.12.2)

c) The MST Configuration Table object (12.12.3)

12.12.1 The MSTI List

For MST Bridges, the MSTI List object models the operations that modify, or inquire about, the list of MST spanning tree instances supported by the Bridge. The object is modeled as a list of MSTIDs corresponding to the MSTIs supported by the Bridge.

The MSTID List object supports the following operations:

a) Read MSTI List (12.12.1.1)

b) Create MSTI (12.12.1.2)

c) Delete MSTI (12.12.1.3)

12.12.1.1 Read MSTI List

12.12.1.1.1 Purpose

To read the list of MSTIDs that are currently supported by the Bridge.

12.12.1.1.2 Inputs

None.

12.12.1.1.3 Outputs

a) MSTID list. The list of MSTID values that are currently supported by the Bridge.

12.12.1.2 Create MSTI

12.12.1.2.1 Purpose

To create a new MSTI and its associated state machines and parameters, and to add its MSTID to the MSTI List.

12.12.1.2.2 Inputs

a) The MSTID of the MSTI to be created.

12.12.1.2.3 Outputs

a) Operation status. This takes one of the following values:

1) Operation rejected due to the number of MSTIs currently supported by the Bridge being equal to the maximum number of MSTIs that the Bridge is able to support.

2) Operation rejected as the MSTID value supplied in the input parameters is already present in the MSTI List.

3) Operation rejected as the MSTID value supplied in the input parameters is one of the reserved MSTID values (8.9.3).

4) Operation accepted.

12.12.1.3 Delete MSTI

12.12.1.3.1 Purpose

To delete an existing MSTI and its associated state machines and parameters, and to remove its MSTID from the MSTI List.

12.12.1.3.2 Inputs

a) The MSTID of the MSTI to be deleted.

12.12.1.3.3 Outputs

a) Operation status. This takes one of the following values:

1) Operation rejected as the MSTID value supplied in the input parameters is not present in the MSTI List.

2) Operation rejected as the MSTID value supplied in the input parameter currently has one or more FIDs allocated to it in the FID to MSTID Allocation Table.

3) Operation accepted.

12.12.2 The FID to MSTID Allocation Table

For MST Bridges, the FID to MSTID Allocation Table object models the operations that modify, or inquire about, the assignment of FIDs to spanning tree instances currently supported by the Bridge (8.9.3). The object is modeled as a fixed-length table in which each entry in the table corresponds to a FID, and the value of the entry specifies the MSTID of the spanning tree to which the set of VIDs supported by that FID are assigned. A value of zero in an entry specifies that the set of VIDs supported by that FID are assigned to the CST.

The MSTID Allocation Table object supports the following operations:

a) Read FID to MSTID allocations (12.12.2.1)

b) Set FID to MSTID allocation (12.12.2.2)

12.12.2.1 Read FID to MSTID allocations

12.12.2.1.1 Purpose

To read a range of one or more entries in the FID to MSTID Allocation Table.

12.12.2.1.2 Inputs

a) First FID—the FID of the first entry to be read.

b) Last FID—the FID of the last entry to be read.

If the value of Last FID is numerically equal to, or smaller than, the value of First FID, then a single table entry is read, corresponding to the value of First FID.

12.12.2.1.3 Outputs

a) List of entries—for each entry that was read:

1) The FID of the entry; and

2) The MSTID to which that FID is allocated.

12.12.2.2 Set FID to MSTID allocation

12.12.2.2.1 Purpose

To change the contents of an entry in the FID to MSTID Allocation Table.

12.12.2.2.2 Inputs

a) FID—the FID of the entry to be changed.

b) MSTID—the MSTID to which the FID is to be allocated.

12.12.2.2.3 Outputs

a) Operation status. This takes one of the following values:

1) Operation rejected as the MSTID value supplied in the input parameters is not present in the MSTI List.

2) Operation rejected as the FID value supplied in the input parameters is invalid or is not supported.

3) Operation accepted.

12.12.2.2.4 Procedure

The Configuration Digest element of the MCID is recalculated, in accordance with the definition in 13.8, following any change in the allocations of FIDs to MSTIDs.

12.12.3 The MST Configuration Table

The MST Configuration Table managed object models the operations that can be performed on the MST Configuration Table for the Bridge (3.141, 8.9.1, and 13.8). Associated with the table is the MCID for the Bridge (8.9.2, 13.8).

The MST Configuration Table is a read-only table, its elements derived from other configuration information held by the Bridge; specifically, the current state of the VID to FID allocation table (8.8.8, 12.10.3), and the FID to MSTID allocation table (8.9.3, 12.12.2). Hence, changes made to either of these tables can in turn affect the contents of the MST Configuration Table, and also affect the value of the “digest” element of the MCID. The MST Configuration Table is modeled as a fixed table of 4096 elements, as described in 13.8.

The MST Configuration Table managed object supports the following operations:

a) Read MST Configuration Table Element (12.12.3.1)

b) Read VIDs assigned to MSTID (12.12.3.2)

c) Read MST Configuration Identifier (12.12.3.3)

d) Set MST Configuration Identifier Elements (12.12.3.4)

12.12.3.1 Read MST Configuration Table Element

12.12.3.1.1 Purpose

To read a single element of the current MST Configuration Table for the Bridge (13.8).

12.12.3.1.2 Inputs

a) A VID value, in the range 0 through 4094.

12.12.3.1.3 Outputs

a) A VID value, in the range 0 through 4094.

b) The MSTID value corresponding to that VID.

12.12.3.2 Read VIDs assigned to MSTID

12.12.3.2.1 Purpose

To read the list of VIDs that are currently assigned to a given MSTID in the MST Configuration Table for the Bridge (13.8).

12.12.3.2.2 Inputs

a) An MSTID value, in the range 0 through 4095.

12.12.3.2.3 Outputs

a) A MSTID value, in the range 0 through 4095.

b) A 4096-bit vector in which bit N is set TRUE if VID N is assigned to the given MSTID and is otherwise set FALSE.

12.12.3.3 Read MST Configuration Identifier

12.12.3.3.1 Purpose

To read the current value of the MCID for the Bridge (13.8).

12.12.3.3.2 Inputs

None.

12.12.3.3.3 Outputs

a) The MCID (13.8), consisting of

1) The Configuration Identifier Format Selector in use by the Bridge. This has a value of 0 to indicate the format specified in this standard.

2) The Configuration Name.

3) The Revision Level.

4) The Configuration Digest.

12.12.3.4 Set MST Configuration Identifier Elements

12.12.3.4.1 Purpose

To change the current values of the modifiable elements of the MCID for the Bridge (13.8).

NOTE—The Configuration Digest element of the MCID is read-only; its value is recalculated whenever configuration changes occur that result in a change in the allocation of VIDs to MSTIs.

12.12.3.4.2 Inputs

a) The MCID (13.8) Format Selector in use by the Bridge. This has a value of 0 to indicate the format specified in this standard.

b) The Configuration Name.

c) The Revision Level.

12.12.3.4.3 Outputs

a) Operation Status. This can take the following values:

1) Operation rejected due to unsupported Configuration Identifier Format Selector value.

2) Operation accepted.

12.13 Provider Bridge management

The conformance requirements of Provider Bridges are specified in 5.10. The S-VLAN component and the externally accessible ports of all Provider Bridges, including Provider Edge Bridges, are managed using the managed objects defined in 12.4 through 12.12. This subclause defines additional managed objects specific to the operation of Provider Bridges.

The internal ports, LANs, C-VLAN components, and Port-mapping S-VLAN components of a Provider Edge Bridge are not managed directly using the managed objects defined in 12.4 through 12.12. Their operation is controlled and monitored through managed objects defined in this subclause.

Each externally accessible Bridge Port on a Provider Bridge is designated as a PNP, CNP, CEP, or RCAP. Designating a port as a CEP implies Provider Edge Bridge functionality and, specifically, the existence of a C-VLAN component associated with that port. This C-VLAN component is uniquely identified within the Bridge by the port number of the associated CEP. The management of the forwarding process, filtering data base, and C-VLANs of the C-VLAN component and the internal connections are achieved through the Customer Edge Port Configuration managed object defined here (12.13.2).

Designating a port as a RCAP implies the existence of a Port-mapping S-VLAN component associated with that port. The Port-mapping S-VLAN component is uniquely identified within the Bridge by the port number of the associated RCAP. Designating an internal port on the Port-mapping S-VLAN component as a C-tagged RCSI implies a C-VLAN component with a CEP connected via an internal LAN to that internal port (PAP). This C-VLAN component and internal connection are uniquely identified by the port number of the RCAP and the S-VID associated with the PAP or by the port number of the internal CEP. Designating an internal port on the Port-mapping S-VLAN component as a Port-based RCSI or a PNP implies an internal LAN connecting this port with a CNP or PNP, respectively. These ports and internal connections are uniquely identified by the port number of the RCAP and the S-VID associated with the PAP or by the port number of the CNP or PNP. The management of the forwarding process, filtering data base, and S-VLANs of Port-mapping S-VLAN components and their internal connections are achieved through the Remote Customer Access Port Configuration managed object defined here (12.13.3).

An internal connection between a CNP on the S-VLAN component and a PEP on the C-VLAN component is instantiated for each service instance. The CNP is identified by the CEP identifier and the S-VID value used for the PVID of the CNP. The PEP is identified by the CEP identifier and the C-VLAN Identifier (C-VID) value used for the PVID of the PEP. These PVID values and the connection between the CNP and PEP are established by reciprocal entries in the C-VID Registration Table (12.13.2.2) and the PEP Configuration Table (12.13.2.4) as follows:

a) An entry in the C-VID Registration Table is created for each C-VLAN supported in the C-VLAN component associated with a CEP. The CEP identifier and C-VID combination identify a PEP. The entry contains (among other parameters) an S-VID value corresponding to the PVID of the CNP, which associates the PEP with a specific CNP. Note that the CEP/C-VID combination identifies a single PEP; however, multiple CEP/C-VID combinations can identify the same PEP if the entries for those CEP/C-VID combinations contain the same S-VID value. This many-to-one mapping of CEP/ C-VID to PEP permits "bundling", i.e., mapping multiple C-VLANs to the same service instance.

b) An entry in the PEP Configuration Table is created for each S-VID corresponding to a service instance accessed by the C-VLAN component. The CEP identifier and S-VID combination identify a CNP. The entry contains (among other parameters) a C-VID value corresponding to the PVID of the PEP, which associates the CNP with a specific PEP. Note that the CEP/S-VID combination identifies a single CNP; however, multiple CEP/S-VID combinations can identify the same CNP if the entries for those CEP/S-VID combinations contain the same C-VID value. This many-to-one mapping of CEP/S-VID to CNP permits configuration of asymmetric VLANs and can be used to establish rooted-multipoint connectivity (F.1.3.2).

Management control of the member sets and untagged sets for C-VIDs in the C-VLAN component is provided in C-VID Registration Table entries rather than through Static VLAN Registration Entries (thus eliminating the need for Filtering Database managed objects for the C-VLAN component). Management control of the member sets and untagged sets for S-VIDs in the S-VLAN component is provided through Static VLAN Registration Entries in the FDB. Creating an entry for an S-VID in the PEP Configuration Table does not automatically modify the Static VLAN Registration Entries for the corresponding S-VLAN. A CNP is added to the member set and untagged set of an S-VLAN by including the CEP identifier (since the CEP identifier and S-VID combination identifies the CNP) in the Port Map of a Static VLAN Registration Entry for that S-VLAN (12.7.7.1, 8.8.2).

A C-VLAN component with more than one PEP (i.e., supporting more than one service instance) participates in the customer network spanning tree protocol by running an instance of RSTP with the enhancements specified in 13.41. This protocol instance is managed using the managed objects defined in 12.8 and 12.12. All BPDUs generated by this protocol instance use the MAC address of the CEP as a source address and as the Bridge address portion of Bridge Identifier. For each PEP, the protocol uses the S-VID value that is the PVID of the associated CNP as the port number. For the CEP, the protocol uses the value 0xFFF as the port number.

The following managed objects define the semantics of the management operations specific to Provider Bridges:

c) The Provider Bridge Port Type managed object (12.13.1)

d) The Customer Edge Port Configuration managed object (12.13.2)

e) The Remote Customer Access Port Configuration managed object (12.13.3)

12.13.1 Provider Bridge Port Type managed object

The management operations that can be performed on the Provider Bridge Port Type managed object are as follows:

a) Read Provider Bridge Port Type (12.13.1.1)

b) Configure Provider Bridge Port Type (12.13.1.2)

12.13.1.1 Read Provider Bridge Port Type

12.13.1.1.1 Purpose

To obtain information regarding the designated type of an externally accessible port on a Provider Bridge.

12.13.1.1.2 Inputs

a) Port Number: the number of the Bridge Port.

12.13.1.1.3 Outputs

a) Port Type: this takes one of the following values:

1) PNP

2) CNP

3) CEP

4) RCAP

12.13.1.2 Configure Provider Bridge Port Type

12.13.1.2.1 Purpose

To designate the type of an externally accessible port on a Provider Bridge.

12.13.1.2.2 Inputs

a) Port Number: the number of the Bridge Port.

b) Port Type: this takes one of the following values:

1) PNP

2) CNP

3) CEP

4) RCAP

12.13.1.2.3 Outputs

None.

12.13.2 Customer Edge Port Configuration managed object

The Customer Edge Port Configuration managed object applies to each externally accessible CEP on a Provider Edge Bridge. It includes

a) The C-VID Registration Table, which provides a mapping between a C-VID and the service instance represented by an S-VID selected for that C-VLAN. This table provides the equivalent functionality of

1) configuring the PVID of the internal CNP on the S-VLAN component;

2) adding the corresponding PEP on the C-VLAN component to the member set of the C-VLAN;

3) adding the PEP and/or CEP to the untagged set of the C-VLAN (if it is desired that frames forwarded to that port are transmitted untagged for this C-VLAN).

b) The PEP configuration parameters, which provide the subset of the Bridge VLAN Configuration managed object (12.10.1) that is relevant for the internal ports of the C-VLAN component associated with the CEP.

c) The Service Priority Regeneration Table, which provides the Priority Regeneration Table (12.6.2) for each internal CNP connected to the C-VLAN component associated with the CEP.

The management operations that can be performed are as follows:

d) Read C-VID Registration Table Entry (12.13.2.1)

e) Configure C-VID Registration Table Entry (12.13.2.2)

f) Read Provider Edge Port Configuration (12.13.2.3)

g) Set Provider Edge Port Configuration (12.13.2.4)

h) Read Service Priority Regeneration Table (12.13.2.5)

i) Set Service Priority Regeneration Table (12.13.2.6)

12.13.2.1 Read C-VID Registration Table Entry

12.13.2.1.1 Purpose

To read the VID of the service associated with a specific Customer VLAN in the C-VLAN component of a Provider Edge Bridge.

12.13.2.1.2 Inputs

a) Port Number: the number of the CEP.

b) Customer VLAN Identifier: a 12-bit C-VID.

12.13.2.1.3 Outputs

a) Service VLAN Identifier: a 12-bit S-VID.

b) Untagged PEP: a boolean indicating frames for this C-VLAN should be forwarded untagged through the Provider Edge Port.

c) Untagged CEP: a boolean indicating frames for this C-VLAN should be forwarded untagged through the Customer Edge Port.

12.13.2.2 Configure C-VID Registration Table Entry

12.13.2.2.1 Purpose

To modify an entry in the C-VID Registration Table.

12.13.2.2.2 Inputs

a) Port Number: the number of the CEP.

b) Customer VLAN Identifier: a 12-bit C-VID.

c) Service VLAN Identifier: a 12-bit S-VID.

d) Untagged PEP: a boolean indicating frames for this C-VLAN should be forwarded untagged through the Provider Edge Port.

e) Untagged CEP: a boolean indicating frames for this C-VLAN should be forwarded untagged through the Customer Edge Port.

12.13.2.2.3 Outputs

None.

12.13.2.3 Read Provider Edge Port Configuration

12.13.2.3.1 Purpose

To read the current configuration of an internal PEP in the C-VLAN component of a Provider Edge Bridge.

12.13.2.3.2 Inputs

a) Port Number: the number of the CEP.

b) Service VLAN Identifier: a 12-bit S-VID.

12.13.2.3.3 Outputs

a) PVID: a 12-bit C-VID to be used for untagged frames received at the PEP;

b) Default priority: an integer range 0-7 to be used for untagged frames received at the PEP;

c) Acceptable Frame Types: the Acceptable Frame Types (8.6.2) for frames received at the PEP. The permissible values for the parameter are as follows:

1) Admit only VLAN-tagged frames

2) Admit only Untagged and Priority-tagged frames

3) Admit all frames

d) Enable Ingress Filtering: the Enable Ingress Filtering parameter for frames received at the PEP. The permissible values for the parameter are as follows:

1) Enabled

2) Disabled

12.13.2.4 Set Provider Edge Port Configuration

12.13.2.4.1 Purpose

To modify the configuration of a PEP in the C-VLAN component of a Provider Edge Bridge.

12.13.2.4.2 Inputs

a) Port Number: the number of the CEP.

b) Service VLAN Identifier: a 12-bit S-VID.

c) PVID: a 12-bit C-VID to be used for untagged frames received at the PEP.

d) Default priority: an integer range 0-7 to be used for untagged frames received at the PEP.

e) Acceptable Frame Types: the Acceptable Frame Types (8.6.2) for frames received at the PEP. The permissible values for the parameter are as follows:

1) Admit only VLAN-tagged frames

2) Admit only Untagged and Priority-tagged frames

3) Admit all frames

f) Enable Ingress Filtering: the Enable Ingress Filtering parameter for frames received at the PEP. The permissible values for the parameter are as follows:

1) Enabled

2) Disabled

12.13.2.4.3 Outputs

None.

12.13.2.5 Read Service Priority Regeneration Table

12.13.2.5.1 Purpose

To read the current contents of the Priority Regeneration Table (6.9.3) for an internal CNP connected to the C-VLAN component associated with a CEP.

12.13.2.5.2 Inputs

a) Port Number: the number of the CEP.

b) Service VLAN Identifier: a 12-bit S-VID.

12.13.2.5.3 Outputs

a) Regenerated Priority value for Received Priority 0: Integer in range 0–7.

b) Regenerated Priority value for Received Priority 1: Integer in range 0–7.

c) Regenerated Priority value for Received Priority 2: Integer in range 0–7.

d) Regenerated Priority value for Received Priority 3: Integer in range 0–7.

e) Regenerated Priority value for Received Priority 4: Integer in range 0–7.

f) Regenerated Priority value for Received Priority 5: Integer in range 0–7.

g) Regenerated Priority value for Received Priority 6: Integer in range 0–7.

h) Regenerated Priority value for Received Priority 7: Integer in range 0–7.

12.13.2.6 Set Service Priority Regeneration Table

12.13.2.6.1 Purpose

To modify the contents of the Priority Regeneration Table (6.9.3) for an internal CNP connected to the C-VLAN component associated with a CEP.

12.13.2.6.2 Inputs

a) Port Number: the number of the CEP.

b) Service VLAN Identifier: a 12-bit S-VID.

c) Regenerated Priority value for Received Priority 0: Integer in range 0–7.

d) Regenerated Priority value for Received Priority 1: Integer in range 0–7.

e) Regenerated Priority value for Received Priority 2: Integer in range 0–7.

f) Regenerated Priority value for Received Priority 3: Integer in range 0–7.

g) Regenerated Priority value for Received Priority 4: Integer in range 0–7.

h) Regenerated Priority value for Received Priority 5: Integer in range 0–7.

i) Regenerated Priority value for Received Priority 6: Integer in range 0–7.

j) Regenerated Priority value for Received Priority 7: Integer in range 0–7.

12.13.2.6.3 Outputs

None.

12.13.3 Remote Customer Access Port Configuration managed object

Designating an external port as a RCAP automatically creates a Port-mapping S-VLAN component associated with that port. This Port-mapping S-VLAN component includes one internal PNP.

The Remote Customer Access Port Configuration managed object applies to each externally accessible RCAP on a Provider Edge Bridge. It includes

a) The Internal Interface Table, which configures the internal interfaces between the Port-mapping S-VLAN component and the S-VLAN or C-VLAN components. This table provides the equivalent functionality of

1) for an RCSI supporting a Port-based service interface:

i) creating an internal PAP connected to a CNP on the S-VLAN component;

ii) configuring both the PAP and CNP to accept only untagged frames;

iii) setting the member set for the external S-VID to include the PAP and RCAP;

iv) setting the PAP’s PVID to the external S-VID and adding that port to that S-VID’s untagged set;

v) setting the CNP’s PVID to the internal S-VID for the Port-based service instance and adding the port to that S-VID’s untagged set;

2) for an RCSI supporting a C-tagged service interface:

i) creating a PAP connected to a CEP on a C-VLAN component;

ii) setting the member set for the external S-VID to include the PAP and RCAP;

iii) configuring the PAP’s PVID to the external S-VID and adding the port to that S-VID’s untagged set;

3) for a PNP:

i) setting the member set for the external S-VID to include the PNP and RCAP;

adding the associated primary S-VLAN component PNP to the member set of the internal S-VLAN;

iii) configuring the associated primary S-VLAN component PNP’s VID translation table to translate between the external S-VID and the internal S-VID for the selected service instance.

Note that in the case of an RCSI supporting a C-tagged service interface the C-VLAN component can be further configured using the Customer Edge Port Configuration managed object. This configuration includes

The parameters to set the C-VID Registration Table entries (12.13.2.2);

— The PEP configuration parameters (12.13.2.4)

The Service Priority Regeneration Table entries (12.13.2.6)

all associated with the configuration of the internal CEP, which is directly connected to the internal PAP identified by the external S-VID and the RCAP.

The management operations that can be performed on the Remote Customer Access Port Configuration managed object are as follows:

b) Read Internal Interface Table Entry (12.13.3.1)

c) Configure Internal Interface Table Entry (12.13.3.2)

Further configuration related to a C-VLAN component associated with an RCSI supporting a C-tagged service interface is accomplished using the Customer Edge Port Configuration managed object (12.13.2).

12.13.3.1 Read Internal Interface Table Entry

12.13.3.1.1 Purpose

To read the Internal Interface Table entry associated with a specific external S-VID in a Port-mapping S-VLAN component of a RCAP.

12.13.3.1.2 Inputs

a) External Port Number: the number of the RCAP.

b) External S-VLAN Identifier: a 12-bit S-VID.

12.13.3.1.3 Outputs

a) Internal Port Number: the port number used to reference the internal interface;

b) A value indicating the type of internal interface associated with the external S-VID, one of

1) Port-based RCSI

2) C-tagged RCSI

3) PNP

4) Discard (external S-VID is not associated with an internal port)

c) Internal S-VLAN Identifier: a 12-bit S-VID (not applicable for a C-tagged RCSI).

12.13.3.2 Configure Internal Interface Table Entry

12.13.3.2.1 Purpose

To add or delete an entry in the Internal Interface Table.

12.13.3.2.2 Inputs

a) External Port Number: the number of the RCAP.

b) External S-VLAN Identifier: a 12-bit S-VID.

c) Internal Port Number (optional): the port number used to reference the internal interface;

d) A value indicating the type of internal interface associated with the external S-VID, one of

1) Port-based RCSI

2) C-tagged RCSI

3) PNP

4) Discard (delete entry for the external S-VID)

e) Internal S-VLAN Identifier: a 12-bit S-VID (not applicable for a C-tagged RCSI).

12.13.3.2.3 Outputs

None

12.14 CFM entities

The CFM managed objects model operations that modify, or inquire about, the configuration and the operation of CFM. Figure 12-1 illustrates the simple hierarchical relationships among the various CFM managed objects, including the control of access to those objects. See 17.4.9 for an explanation of methods available to distinguish between an Owner and a Maintenance Domain administrator. See Clause 18 for an explanation of the use of Maintenance Domains and Maintenance Associations (MAs).The following are the CFM managed objects in a Bridge:

a) Maintenance Domain list managed object (12.14.1)

b) CFM Stack managed object (12.14.2)

c) Default MD Level managed object (12.14.3)

d) Configuration Error List managed object (12.14.4)

e) Maintenance Domain managed objects (12.14.5)

f) Maintenance Association managed objects (12.14.6)

g) Maintenance association Endpoint managed objects (12.14.7)

!image

Figure 12-1—Relationships among CFM managed objects

12.14.1 Maintenance Domain list managed object

There is one Maintenance Domain list managed object per Bridge. It contains a list of the Maintenance Domains that have been configured on the Bridge.

The management operations that can be performed on the Maintenance Domain list managed object are as follows:

a) Read Maintenance Domain list (12.14.1.1)

b) Create Maintenance Domain managed object (12.14.1.2)

c) Delete Maintenance Domain managed object (12.14.1.3)

NOTE—In Provider Bridge applications, each Maintenance Domain, and thus each Maintenance Domain managed object, can be controlled by a different administrative organization. Some or all of these administrative organizations can be different from that which controls the Maintenance Domain list managed object or the managed objects in Clause 12 other than those in 12.14. See 17.3.9 for a discussion of the means by which control of and access to different instances of the Maintenance Domain managed object are allocated to these different administrative organizations.

12.14.1.1 Read Maintenance Domain list

12.14.1.1.1 Purpose

To obtain information about all of the Maintenance Domains in a Bridge.

12.14.1.1.2 Inputs

None.

12.14.1.1.3 Outputs

a) A list, perhaps empty, of the Maintenance Domain managed objects configured on the Bridge. For each item in the list, the Read Maintenance Domain list command returns:

1) A Maintenance Domain Name, including the format specifier from Table 21-19 (21.6.5.1)

2) A reference to that Maintenance Domain’s Maintenance Domain managed object (12.14.5)

12.14.1.2 Create Maintenance Domain managed object

12.14.1.2.1 Purpose

To create a new Maintenance Domain managed object in a Bridge, and add it to the Bridge’s Maintenance Domain list managed object.

12.14.1.2.2 Inputs

a) A Maintenance Domain Name, including the format specifier from Table 21-19 (21.6.5.1); default value is the character string (format 4) “DEFAULT.”

b) The MD Level at which the Maintenance Domain is to be created; default value is 0.

12.14.1.2.3 Outputs

a) Operation status. This takes one of the following values:

1) Operation rejected due to invalid Maintenance Domain Name (21.6.5.1);

2) Operation rejected because Maintenance Domain Name already exists;

3) Operation rejected due to invalid MD Level; or

4) Operation accepted.

12.14.1.3 Delete Maintenance Domain managed object

12.14.1.3.1 Purpose

To delete a specific Maintenance Domain managed object from a Bridge and from the Bridge’s Maintenance Domain list managed object.

12.14.1.3.2 Inputs

a) A reference to a particular Maintenance Domain managed object (12.14.5).

12.14.1.3.3 Outputs

a) Operation status. This takes one of the following values:

1) Operation rejected due to invalid or nonexistent Maintenance Domain; or

2) Operation accepted.

12.14.2 CFM Stack managed object

There is one CFM Stack managed object per Bridge. It permits retrieval of information about the MPs configured on a particular Bridge Port or aggregated port. The management operation that can be performed is

a) Read CFM Stack managed object (12.14.2.1)

12.14.2.1 Read CFM Stack managed object

12.14.2.1.1 Purpose

To obtain the contents of the CFM Stack managed object, which allows a network administrator to discover the relationships among MEPs and MHFs configured on a particular Bridge Port or aggregated port.

12.14.2.1.2 Inputs

a) An interface, either a Bridge Port, or an aggregated IEEE 802.3 port within a Bridge Port, on which MPs might be configured.

b) An MD Level.

c) A value indicating the direction in which any reported MP faces, either

1) Down (Active SAP is further away from the Frame filtering entity); or

2) Up (Active SAP is closer to the Frame filtering entity).

d) A specific VID, I-SID, Traffic Engineering service instance Identifier (TE-SID), or Segment Identifier (SEG-ID) associated with an MP, or 0, in the case that the MP is associated with no VID, I-SID, TE-SID, or SEG-ID.

12.14.2.1.3 Outputs

a) Operation status. This takes one of the following values:

1) Operation rejected due to illegal inputs;

2) No MP is configured on the indicated Bridge Port or aggregated port at the indicated MD Level and direction;

3) A MEP is configured; or

4) An MHF is configured.

b) Either the Maintenance Domain managed object (12.14.5) to which the MP’s MA is associated, or an indication that there is no Maintenance Domain associated with the MP.

c) Either the Maintenance Association managed object (12.14.6) to which the MP is associated, or an indication that there is no MA associated with the MP.

d) If a MEP is configured, its MA Endpoint Identifier (MEPID), else 0.

e) The MAC address of the MP.

12.14.3 Default MD Level managed object

There is a single Default MD Level managed object per Bridge component. It controls MIP Half Function (MHF) creation for VIDs or I-SIDs of I- or B-components that are not contained in the list of VIDs attached to any specific Maintenance Association managed object [item c) in 12.14.5.3.2], and the transmission of the Sender ID TLV (21.5.3) by those MHFs.

The management commands that can be performed on the Default MD Level managed object are as follows:

a) Read Default MD Level managed object (12.14.3.1).

b) Write Default MD Level managed object (12.14.3.2).

12.14.3.1 Read Default MD Level managed object

12.14.3.1.1 Purpose

To read the table of default parameters for controlling MHFs not associated with any MA configured on the Bridge component.

12.14.3.1.2 Input

a) A VID or I-SID in an I- or B-component.

12.14.3.1.3 Output

a) A list of VIDs associated with any MHF on the VID named in item a) in 12.14.3.1.2, always including that VID, or the Backbone-SID of the B-component or VIP-SID of the I-component associated with any MHF on the I-SID named in item a) in 12.14.3.1.2. The first VID is the MAs’ Primary VID. List is empty if no VID specified in 12.14.3.1.2.

b) A Boolean value indicating whether this entry is in effect or has been overridden by the existence of a Maintenance Association managed object associated with the same VID or I-SID of I- or Bcomponents and MD Level, and on which is configured an Up MEP. True if this Maintenance Domain managed object is in effect.

c) (writable) The MD Level at which MHFs are to be created.

d) (writable) An enumerated value indicating whether the management entity can create MHFs for this VID(s) or I-SID(s) of I- or B-components: defMHFnone: (n, the default), defMHFdefault (o), or defMHFexplicit (p) (22.2.3).

e) (writable) An enumerated value indicating what, if anything, is to be included in the Sender ID TLV (21.5.3) transmitted by MPs configured in the Default Maintenance Domain: sendIdNone (1, the default value), sendIdChassis (2), sendIdManage (3), or sendIdChassisManage (4).

12.14.3.2 Write Default MD Level managed object

12.14.3.2.1 Purpose

To write entries in the table of default parameters for controlling MHFs on VIDs or on I-SIDs used in an Ior B-component not associated with any MA.

12.14.3.2.2 Inputs

a) A list of VIDs or the VIP-SIDs used in the I-component or Backbone-SID used in the B-component, or 0, indicating no VID or I-SID. The first VID in the list is the Primary VID.

b) One of the writable managed object in 12.14.3.1.3.

12.14.3.2.3 Outputs

a) Operation status. This takes one of the following values:

1) Operation rejected because creating or assigning these VIDs or I-SIDs to this MD Level would exceed the number of MD Levels supported by some Bridge Port (item c) in 22.2.4);

2) Operation rejected because the VID list provided [item a) in 12.14.3.2.2] specifies a different Primary VID, or contains one or more but not all of the VIDs, in the definition of an MA or some other entry in the Default MD Level managed object; or

3) Operation accepted.

12.14.4 Configuration Error List managed object

The Configuration Error List managed object is a list of {identifier, port} pairs configured in error together with the identity of the configuration error. The identifier is a VID, I-SID, TE-SID, or SEG-ID and the port is a simple Bridge Port or aggregated Bridge Port.

12.14.4.1 Read Configuration Error List managed object

12.14.4.1.1 Purpose

To list the entries in the Configuration Error List where each entry describes the identifier and port pair that identifies the entry, together with a description of the particular configuration error.

12.14.4.1.2 Inputs

a) A VID, I-SID, or TE-SID, specifying which service instance to check for ports in error or a SEG-ID specifying which Infrastructure Segment to checkfor ports in error.

b) An interface, either a Bridge Port or an aggregated IEEE 802.3 port within a Bridge Port.

12.14.4.1.3 Outputs

a) An indication of the result of the operation:

1) Operation rejected due to illegal vlan_identifier;

2) Operation rejected due to illegal or nonexistent Bridge Port or aggregated port; or

3) Operation accepted.

b) If the operation was accepted, a vector of Boolean error conditions from 22.2.4, any of which may be true:

1) CFMleak

2) ConflictingVIDs

3) ExcessiveLevels and/or

4) OverlappedLevels

12.14.5 Maintenance Domain managed object

There can be any number of Maintenance Domain managed objects per Bridge. A Maintenance Domain managed object is required in order to create an MA with a Maintenance Association Identifier (MAID) that includes that Maintenance Domain’s Name. From this Maintenance Domain managed object, all Maintenance Association managed objects associated with that Maintenance Domain managed object can be accessed, and thus controlled.

The management operations that can be performed on the Maintenance Domain managed object are as follows:

a) Read Maintenance Domain managed object (12.14.5.1)

b) Write Maintenance Domain managed object (12.14.5.2)

c) Create Maintenance Association managed object (12.14.5.3)

d) Delete Maintenance Association managed object (12.14.5.4)

NOTE 1—The Maintenance Domain managed object is defined in such a manner that it can be configured identically in all of the Bridges in that Bridged Network. All of the information local to a particular MA or a particular Bridge is contained in other managed objects, e.g., the Maintenance Association managed object (12.14.6) or the Maintenance association Endpoint managed object (12.14.7).

NOTE 2—A single Maintenance Domain managed object can be used to manage any number of separate Maintenance Domains, as Maintenance Domains are defined in 18.1. For example, the Maintenance Association managed object for all of the physical links in a Bridged Network that are protected by MAs can be grouped together under a single Maintenance Domain managed object for the convenience of the network administrator.

NOTE 3—Multiple Maintenance Domain managed objects can be used to manage a single Maintenance Domain, as Maintenance Domains are defined in 18.1. For example, a PBN’s Domain Service Access Points (DoSAPs) could be split among two Maintenance Domain managed objects, one for point-to-point services and one for multipoint services.

12.14.5.1 Read Maintenance Domain managed object

12.14.5.1.1 Purpose

To obtain information from a Bridge about a specific Maintenance Domain managed object.

12.14.5.1.2 Inputs

a) A reference to a particular Maintenance Domain managed object (12.14.5).

12.14.5.1.3 Outputs

a) Operation status. This takes one of the following values:

1) Operation rejected due to nonexistent Maintenance Domain; or 2) Operation accepted.

b) The MD Level of the specific Maintenance Domain identified by the Input.

c) (writable) An enumerated value indicating whether the management entity can create MHFs for this Maintenance Domain: defMHFnone: (n, the default value), defMHFdefault (o), or defMHFexplicit (p) (22.2.3).

d) (writable) An enumerated value indicating what, if anything, is to be included in the Sender ID TLV (21.5.3) transmitted by MPs configured in this Maintenance Domain: sendIdNone (1, the default value), sendIdChassis (2), sendIdManage (3), or sendIdChassisManage (4) [item d) in 12.14.6.1.3].

e) (writable) The network address to which Fault Alarms (12.14.7.7) are to be transmitted, or a value indicating “Fault Alarms are not to be transmitted.” Default value is “not transmitted.”

NOTE—The variables c) through e) could be writable by the organization operating the Maintenance Domain.

f) A list of references to the Maintenance Association managed objects (12.14.6) attached to the indicated Maintenance Domain managed object.

12.14.5.2 Write Maintenance Domain managed object

12.14.5.2.1 Purpose

To alter a value of a specific Maintenance Domain managed object.

12.14.5.2.2 Inputs

a) A reference to a particular Maintenance Domain managed object (12.14.5).

b) A reference to a writable managed object in 12.14.5.1.3 to be altered.

c) A new value for the managed object.

12.14.5.2.3 Outputs

a) Operation status. This takes one of the following values:

1) Operation rejected due to nonexistent Maintenance Domain;

2) Operation rejected due to the selected managed object being Read-Only;

3) Operation rejected due to invalid value for the selected managed object; or

4) Operation accepted.

12.14.5.3 Create Maintenance Association managed object

12.14.5.3.1 Purpose

To create a new Maintenance Association managed object within a Maintenance Domain managed object.

12.14.5.3.2 Inputs

a) A reference to a particular Maintenance Domain managed object (12.14.5).

b) The Short MA Name of an MA within that Maintenance Domain, including the format specifier from Table 21-20 (21.6.5.4). In the case of a PBB-TE, VID-based, or Infrastructure Segment MA, the default value is a 2-octet integer (format 3) containing the primary VID, or 0, if the MA is not attached to a VID.

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.

12.14.5.3.3 Outputs

a) Operation status. This takes one of the following values:

1) Operation rejected due to nonexistent Maintenance Domain;

2) Operation rejected due to invalid Short MA Name (21.6.5.4);

Operation rejected due to the existence of another MA in the same Maintenance Domain with the same Short MA Name;

4) Operation rejected because creation of this MA would exceed the number of MD Levels supported by some Bridge Port [item c) in 22.2.4];

5) Operation rejected because the VID list provided [item c) in 12.14.5.3.2] specifies a different Primary VID, or contains one or more, but not all, of the VIDs, in the definition of another MA or an entry in the Default MD Level managed object;

6) Operation rejected because the I-SID value specified does not correspond to a valid backbone service instance;

Operation rejected because the TE-SID value specified does not correspond to a valid TESI or set of SPBM path endpoints;

8) Operation rejected because the SEG-ID value specified does not correspond to a valid Infrastructure Segment; or

9) Operation accepted.

12.14.5.4 Delete Maintenance Association managed object

12.14.5.4.1 Purpose

To delete a specific Maintenance Association managed object from a Maintenance Domain managed object.

12.14.5.4.2 Inputs

a) A reference to a particular Maintenance Association managed object (12.14.6).

12.14.5.4.3 Outputs

a) Operation status. This takes one of the following values:

1) Operation rejected due to nonexistent MA; or

2) Operation accepted.

12.14.6 Maintenance Association managed object

There can be any number of Maintenance Association managed objects per Bridge, one for each service instance for which an MP is defined on that Bridge. From this Maintenance Association managed object, all Maintenance association Endpoint managed objects associated with that Maintenance Association managed object can be accessed, and thus controlled.

The management operations that can be performed on the Maintenance Association managed object are as follows:

a) Read Maintenance Association managed object (12.14.6.1)

b) Write Maintenance Association managed object (12.14.6.2)

c) Create Maintenance association Endpoint managed object (12.14.6.3)

d) Delete Maintenance association Endpoint managed object (12.14.6.4)

NOTE 1—The Maintenance Association managed object is defined in such a manner that it can be configured identically in all of the Bridges in its Maintenance Domain. All information local to a particular Bridge is contained in other managed objects, e.g., the Maintenance association Endpoint managed object (12.14.7).

NOTE 2—Although MHFs are created via the Maintenance Domain managed object, the Default MD Level managed object, and the Maintenance Association managed object, and although there is a Maintenance association Endpoint managed object, there is no “MIP Half Function managed object.” One reason for this omission is that no controls over the behavior of the MHF beyond its existence is required. Another is that the burden of implementing, providing access to, and providing the maintenance capabilities to access the counters and similar managed objects appropriate to an MHF Managed Object seemed to the developers of this standard to outweigh the benefits of having that information available.

12.14.6.1 Read Maintenance Association managed object

12.14.6.1.1 Purpose

To obtain information from a Bridge about a specific Maintenance Association managed object.

12.14.6.1.2 Inputs

a) A reference to a particular Maintenance Association managed object (12.14.6).

12.14.6.1.3 Outputs

a) Operation status. This takes one of the following values:

1) Operation rejected due to nonexistent MA; or 2) Operation accepted.

The VID(s), I-SID, TE-SID, or 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 of a list of VIDs, the first VID returned is the MA’s Primary VID.

c) (writable) An enumerated value indicating whether the management entity can create MHFs for this MA: defMHFnone: (n), defMHFdefault (o), defMHFexplicit (p), or defMHFdefer (q), (22.2.3), default value is defMHFdefer.

d) (writable) An enumerated value indicating what, if anything, is to be included in the Sender ID TLV (21.5.3) transmitted by MPs configured in this MA:

1) sendIdNone: The Sender ID TLV is not to be sent; 2) sendIdChassis: The Chassis ID Length, Chassis ID Subtype, and Chassis ID fields of the Sender ID TLV are to be sent, but not the Management Address Length or Management Address fields;

3) sendIdManage: The Management Address Length and Management Address of the Sender ID TLV are to be sent, but the Chassis ID Length is to be transmitted with a 0 value, and the Chassis ID Subtype and Chassis ID fields not sent;

4) sendIdChassisManage: The Chassis ID Length, Chassis ID Subtype, Chassis ID, Management Address Length, and Management Address fields are all to be sent; or

5) sendIdDefer: (the default value) The contents of the Sender ID TLV are determined by the Maintenance Domain managed object, item d) in 12.14.5.1.3.

e) (writable) An enumerated value, other than 0, indicating the interval between CCM transmissions to be used by all MEPs in the MA (20.8.1, 21.6.1.3) (default 1 s).

f) (writable) The network address to which Fault Alarms (12.14.7.7) are to be transmitted, a value indicating “not specified,” or a value indicating “Fault Alarms are not to be transmitted.” If “not specified,” the address used is that from the Maintenance Domain managed object [item e) in 12.14.5.1.3].

g) (writable) A list of the MEPIDs of the MEPs in the MA.

12.14.6.2 Write Maintenance Association managed object

12.14.6.2.1 Purpose

To alter a value of a specific Maintenance Association managed object.

12.14.6.2.2 Inputs

a) A reference to a particular Maintenance Association managed object (12.14.6).

b) A reference to one of the writable managed objects in 12.14.6.1.3 is to be altered.

c) A new value for the managed object.

12.14.6.2.3 Outputs

a) Operation status. This takes one of the following values:

1) Operation rejected due to nonexistent MA;

2) Operation rejected due to the selected managed object being Read-Only;

3) Operation rejected due to lack of authority to set this variable;

4) Operation rejected due to invalid value for the selected managed object; or

5) Operation accepted.

12.14.6.3 Create Maintenance association Endpoint managed object

12.14.6.3.1 Purpose

To create a new Maintenance association Endpoint managed object within a Maintenance Association managed object on a specific Bridge Port or aggregated port.

12.14.6.3.2 Inputs

a) A reference to a particular Maintenance Association managed object (12.14.6).

b) A MEPID for the created MEP.

c) A value indicating the direction in which the MEP faces on the Bridge Port or aggregated port, either 1) Down (Active SAP is further away from the Frame filtering entity) (the default); or 2) Up (Active SAP is closer to the Frame filtering entity).

d) An interface, either a Bridge Port or an aggregated IEEE 802.3 port within a Bridge Port.

12.14.6.3.3 Outputs

a) Operation status. This takes one of the following values:

1) Operation rejected due to nonexistent MA;

2) Operation rejected because the specified MEPID already exists in this MA in this Bridge;

3) Operation rejected because MEPID is not in the MA’s list of MEPIDs [item g) in 12.14.6.1.3];

4) Operation rejected due to the existence of a MEP in the same direction (Up or Down) at that same MD Level, for the same VID(s), I-SID, TE-SID, or SEG-ID as this MEP (or for no VID, I-SID, TE-SID, or SEG-ID, if this MEP’s MA has no VID, I-SID, TE-SID, or SEG-ID), on that Bridge Port or aggregated port;

5) Operation failed because one or more of the listed VIDs, I-SID, or TE-SID in this MA are assigned to some other MA on which Up MEPs are configured on any Bridge Port;

6) Operation rejected because the Bridge is incapable of instantiating a MEP on that Bridge Port or aggregated IEEE 802.3 port;

7) Operation rejected because an Up MEP cannot be configured for an MA that has no VID, I-SID, or TE-SID;

8) Operation rejected because a MEP exists on this MA that has a different value for its Up/Down parameter [item c) in 12.14.6.3.2]; or

9) Operation accepted.

12.14.6.4 Delete Maintenance association Endpoint managed object

12.14.6.4.1 Purpose

To delete an existing Maintenance association Endpoint managed object from a Maintenance Association managed object.

12.14.6.4.2 Inputs

a) A reference to a particular Maintenance association Endpoint managed object (12.14.7).

12.14.6.4.3 Outputs

a) Operation status. This takes one of the following values:

1) Operation rejected due to nonexistent MEP; or

2) Operation accepted.

12.14.7 Maintenance association Endpoint managed object

There can be any number of Maintenance association Endpoint managed objects per Bridge, one for each MEP defined within that Bridge. From this Maintenance association Endpoint managed object, all management objects related to that MEP can be controlled.

The management operations that can be performed on the Maintenance association Endpoint managed object are as follows:

a) Read Maintenance association Endpoint managed object (12.14.7.1)

b) Write Maintenance association Endpoint managed object (12.14.7.2)

c) Transmit Loopback Messages (12.14.7.3)

d) Transmit Linktrace Message (12.14.7.4)

e) Read Linktrace Reply (12.14.7.5)

f) Read MEP Database (12.14.7.6)

g) Transmit MEP Fault Alarm (12.14.7.7)

12.14.7.1 Read Maintenance association Endpoint managed object

12.14.7.1.1 Purpose

To obtain information from a Bridge about a specific Maintenance association Endpoint managed object.

12.14.7.1.2 Inputs

a) A reference to a particular Maintenance association Endpoint managed object (12.14.7).

12.14.7.1.3 Outputs

a) Operation status. This takes one of the following values:

1) Operation rejected due to nonexistent MEP; or 2) Operation accepted.

b) An interface, either a Bridge Port or an aggregated IEEE 802.3 port within a Bridge Port, to which the MEP is attached.

c) A value indicating the direction in which the MEP faces on the interface, either

1) Down (Active SAP is further away from Frame filtering entity); or 2) Up (Active SAP is closer to the Frame filtering entity).

d) (writable) An integer indicating the Primary VID of the MEP, always one of the VIDs assigned to the MEP’s MA. The value 0 indicates either that the Primary VID is that of the MEP’s MA or that the MEP’s MA is associated with no VID. In the case of a PBB-TE associated MEP, the Primary VID is not writable but is always associated with the value of the ESP-VID parameter identifying the MA’s ESP that has the MEP’s MAC address in its ESP-SA field (MEPprimaryVID, 20.9.7). In the case of an Infrastructure Segment associated MEP, the Primary VID (MEPprimaryVID, 20.9.7) is not writable but is always associated with the value of the SMP-VID parameter identifying the MA’s SMP that has the MEP’s MAC address in its SMP-SA field. 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).

e) (writable) A Boolean flag indicating the administrative state of the MEP (20.9.1) (default FALSE).

f) A value indicating the current state of the MEP Fault Notification Generator state machine (20.37).

g) (writable) A Boolean flag indicating whether the MEP is or is not to generate CCMs (CCIenabled, 20.10.1) (default FALSE, no CCMs).

h) (writable) The priority parameter for CCMs and LTMs transmitted by the MEP (default value: the highest priority, i.e., that with the highest numerical value, allowed to pass through the Bridge Port for any of this MEP’s VIDs, I-SID, TE-SID, or SEG-ID).

NOTE—The management entity can obtain the default value for this variable from the Priority regeneration table in 6.9.3 by extracting the highest priority value in the table on this MEP’s Bridge Port (1 is lowest, then 2, then 0, then 3–7), appropriate to the direction in which frames are emitted from the MEP’s Active SAP.

i) The MAC address of the MEP (19.4). In the case of a MEP that is associated with a TESI, the MAC address of the CBP upon which the MEP is operating. In the case of a MEP that is associated with an Infrastructure Segment, the MAC address of the PNP upon which the MEP is operating.

j) (writable) The network address to which Fault Alarms (12.14.7.7) are to be transmitted, a value indicating “not specified,” or a value indicating “Fault Alarms are not to be transmitted.” If “not specified,” the address used is that from the Maintenance Association managed object [item f) in 12.14.6.1.3].

k) (writable) An integer value specifying the lowest priority defect that is allowed to generate a Fault Alarm (20.9.5):

1) All defects: DefRDICCM, DefMACstatus, DefRemoteCCM, DefErrorCCM, and DefXconCCM;

2) Only DefMACstatus, DefRemoteCCM, DefErrorCCM, and DefXconCCM (the default);

3) Only DefRemoteCCM, DefErrorCCM, and DefXconCCM;

4) Only DefErrorCCM and DefXconCCM;

5) Only DefXconCCM; or

6) No defects are to be reported.

l) (writable) The time that defects must be present before a Fault Alarm is issued (20.35.3) (default 2.5 s).

m) (writable) The time that defects must be absent before resetting a Fault Alarm (20.35.4) (default 10 s).

n) An enumerated value indicating the highest priority defect that has been present since the MEP Fault Notification Generator state machine was last in the FNG_RESET state (20.35.9):

1) DefNone: No defect has been present since the last FNG_RESET state;

2) DefRDICCM: The last CCM received by this MEP from some remote MEP contained the RDI bit, so variable item o) in 12.14.7.1.3 is set;

3) DefMACstatus: The last CCM received by this MEP from some remote MEP indicated that the transmitting MEP’s associated MAC is reporting an error status via the Port Status TLV (21.5.4) or Interface Status TLV (21.5.5), so variable item p) in 12.14.7.1.3 is set;

4) DefRemoteCCM: This MEP is not receiving CCMs from some other MEP in its configured list [item g) in 12.14.6.1.3], so variable item q) in 12.14.7.1.3 is set;

5) DefErrorCCM: This MEP is receiving invalid CCMs, so variable item r) in 12.14.7.1.3, is set; or

6) DefXconCCM: This MEP is receiving CCMs that could be from some other MA, so variable item s) in 12.14.7.1.3 is set.

o) A Boolean flag (20.35.7) indicating that some other MEP in this MEP’s MA is transmitting the RDI bit (can trigger DefRDICCM).

p) A Boolean flag (20.35.6) indicating that a Port Status TLV (21.5.4) or Interface Status TLV (21.5.5) is indicating an error condition (can trigger DefMACstatus).

q) A Boolean flag (20.35.5) indicating that CCMs are not being received from at least one of the configured remote MEPs (can trigger DefRemoteCCM).

r) A Boolean flag (20.21.3) indicating that erroneous CCMs are being received from some MEP in this MEP’s MA (can trigger DefErrorCCM).

s) A Boolean flag (20.23.3) indicating that CCMs are being received from a MEP that could be in some other MA (can trigger DefXconCCM).

t) The last-received CCM (20.21.2) that triggered a DefErrorCCM fault (20.21.3).

u) The last-received CCM (20.23.2) that triggered a DefXconCCM fault (20.23.3).

v) (optional) The total number of out-of-sequence CCMs received (20.16.12).

w) The total number of CCMs transmitted (20.10.2).

x) The next Loopback Transaction Identifier to be sent in an LBM (20.30.2).

y) The total number of valid, in-order LBRs received (20.33.1).

z) The total number of valid, out-of-order LBRs received (20.33.1).

aa) (optional) The total number of LBRs received whose mac_service_data_unit did not match (except for the OpCode) that of the corresponding LBM (20.2.3).

ab) The next LTM Transaction Identifier to be sent in an LTM (20.41.1).

ac) The total number of unexpected LTRs received (20.44.1).

ad) The total number of LBRs transmitted (20.28.2).

(writable) A list indicating which of the remote MEPs in the same MA are active. The Remote MEP state machines (20.20) are instantiated only for the active remote MEPs. By default, all configured remote MEPs in the same MA are active.

af) (writable) Only applicable for PBB-TE MEPs supporting the Traffic field (21.6.1.4), a Boolean flag indicating that the capability to report the presence of traffic is enabled. The default value is FALSE.

ag) (writable) Only applicable for PBB-TE MEPs supporting the Traffic field (21.6.1.4), a Boolean flag indicating that the mismatch defect is allowed to generate a Fault Alarm. The default value is FALSE.

ah) Only applicable for PBB-TE MEPs supporting the Traffic field (21.6.1.4), a Boolean flag indicating the presence of a traffic field mismatch defect (20.25.2) (can trigger DefMmCCM).

ai) Only applicable for PBB-TE MEPs supporting the Traffic field (21.6.1.4), a Boolean flag indicating the presence of a local mismatch defect (20.25.5) (can trigger DefMmCCM).

aj) Only applicable for PBB-TE MEPs supporting the Traffic field (21.6.1.4), an enumerated value indicating if the mismatch defect that has been present since the MEP Mismatch Fault Notification Generator state machine (20.40) was last in the MFNG_RESET state, either

1) DefNone: No defect has been present since the last MFNG_RESET state; or

2) DefMmCCM: This MEP is receiving CCMs that have different value in their Traffic field than the CCMs transmitted by this MEP or is transmitting CCMs with both the RDI and the Traffic field bit set to 1 and the disableLocdefect (20.25.4) variable is cleared, so variable item ah) in 12.14.7.1.3 is set.

ak) Only applicable for PBB-TE MEPs supporting the Traffic field (21.6.1.4), a value indicating the current state of the MEP Mismatch Fault Notification Generator state machine (20.40).

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).

12.14.7.2 Write Maintenance association Endpoint managed object

12.14.7.2.1 Purpose

To alter a value in a specific managed object within a specific Maintenance association Endpoint managed object.

12.14.7.2.2 Inputs

a) A reference to a particular Maintenance association Endpoint managed object (12.14.7).

b) A reference to one of the writable managed objects in 12.14.7.1.3 is to be altered.

c) A new value for the managed object.

12.14.7.2.3 Outputs

a) Operation status. This takes one of the following values:

1) Operation rejected due to nonexistent MEP;

2) Operation rejected due to the selected managed object being Read-Only;

3) Operation rejected due to invalid value for the selected managed object; or

4) Operation accepted.

12.14.7.3 Transmit Loopback Messages

12.14.7.3.1 Purpose

To signal to the MEP to transmit some number of LBMs.

NOTE—The Maintenance association Endpoint managed object (12.14.7) can be examined to determine whether the corresponding LBRs have been received by the MEP.

12.14.7.3.2 Inputs

a) A reference to a particular Maintenance association Endpoint managed object (12.14.7).

b) An indication of the target 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).

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

h) In the case of ECMP with flow filtering, a flow hash value if the destination address is an individual address.

12.14.7.3.3 Outputs

a) An indication of whether the command was accepted by the MEP:

1) Operation rejected due to nonexistent MEP;

2) Operation rejected due to invalid number of LBMs to be transmitted;

3) Operation rejected due to too much data to be transmitted;

4) Operation rejected due to invalid priority or drop_eligible parameters to be transmitted;

5) Operation rejected due to invalid ESP-VID;

6) The LBM(s) will be (or have been) sent; or

7) The LBM(s) will not be sent (e.g., because the Bridge is busy with another LBM transmit operation).

b) The Loopback Transaction Identifier (20.30.2) of the first LBM (to be) sent. The value returned is undefined if the Transmit Loopback Messages command was not accepted.

12.14.7.4 Transmit Linktrace Message

12.14.7.4.1 Purpose

To signal to the MEP to transmit an LTM and to create an LTM entry in the MEP’s Linktrace Database.

NOTE—The Maintenance association Endpoint managed object (12.14.7) can be examined to determine whether the corresponding LTRs have been received by the MEP.

12.14.7.4.2 Inputs

a) A reference to a particular Maintenance association Endpoint 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 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.

12.14.7.4.3 Outputs

a) An indication of whether the command was accepted by the MEP:

1) Operation rejected due to nonexistent MEP;

2) Operation rejected due to invalid Flags field to be transmitted;

3) Operation rejected due to invalid Target MAC Address to be transmitted;

4) Operation rejected due to invalid LTM TTL field to be transmitted;

5) Operation rejected due to invalid ESP-VID;

6) The command was accepted and the LTM has (or will be) transmitted; or

7) The command was rejected and no LTM will be sent (e.g., because the Bridge is busy with another LTM transmit operation).

b) The LTM Transaction Identifier (20.41.1) of the LTM sent. The value returned is undefined if the Transmit Linktrace Message command was not accepted.

c) The LTM Egress Identifier TLV value transmitted in the LTM. The value returned is undefined if the Transmit Linktrace Message command was not accepted.

12.14.7.5 Read Linktrace Reply

12.14.7.5.1 Purpose

To obtain from the MEP’s Linktrace database (20.41.2) the LTM entry for a previously transmitted LTM with a specific LTM Transaction Identifier. An LTM entry consists of a list of LTR entries, each corresponding to a Linktrace Reply (LTR) PDU received in response to that LTM. The LTM Transaction Identifier returned by successful Transmit Linktrace Message command [item b) in 12.14.7.4.3] is used in the Read Linktrace Reply command [item b) in 12.14.7.5.2] to select the LTM entry.

See J.5 for a discussion of how to interpret the output from the Read Linktrace Reply command.

12.14.7.5.2 Inputs

a) A reference to a particular Maintenance association Endpoint managed object (12.14.7).

b) The LTM Transaction Identifier returned from a previous Transmit Linktrace Message command, indicating the LTM entry to which the LTR entries will be attached.

c) An index to distinguish among multiple LTRs with the same LTR Transaction Identifier field value.

12.14.7.5.3 Outputs

A list of LTR entries returned corresponding to the selected LTM Transaction Identifier (20.41.2). Each LTR entry in the list returns:

a) An indication of whether the command was accepted by the MEP:

1) Operation rejected due to nonexistent MEP;

2) Operation rejected due to LTM Transaction Identifier not found;

3) Operation rejected due to LTR entry has been discarded because too many LTRs have been returned corresponding to that LTM Transaction Identifier;

4) Operation rejected due to LTR entry with that index has not yet been returned; or

5) Operation accepted.

b) The integer Reply TTL field value returned in the LTR (20.41.2.2).

c) A Boolean value stating whether an LTM was forwarded by the responding MP, as returned in the FwdYes flag of the Flags field (20.41.2.1).

d) A Boolean value stating whether the forwarded LTM reached a MEP enclosing its MA, as returned in the TerminalMEP flag of the Flags field (20.41.2.1).

e) An octet string holding the Last Egress Identifier field returned in the LTR Egress Identifier TLV of the LTR (20.41.2.3).

f) An octet string holding the Next Egress Identifier field returned in the LTR Egress Identifier TLV of the LTR (20.41.2.4).

g) An enumerated value indicating the value returned in the Relay Action field (20.41.2.5): RlyHit, RlyFDB, or RlyMPDB.

h) (if returned in the LTR) An enumerated value indicating the format of the Chassis ID (21.5.3.2).

i) (if returned in the LTR) The Chassis ID (21.5.3.3).

j) (if returned in the LTR) The Management Address information of the Bridge transmitting the LTR (21.5.3.7).

k) (if returned in the LTR) An enumerated value indicating the value returned in the Ingress Action field (20.41.2.6) of the LTR: IngOK, IngDown, IngBlocked, or IngVID.

l) (if returned in the LTR) The MAC address returned in the Ingress MAC Address field (20.41.2.7).

m) (if returned in the LTR) An enumerated value indicating the format of the Ingress Port ID field (20.41.2.8).

n) (if returned in the LTR) The Ingress Port ID (20.41.2.9).

o) (if returned in the LTR) An enumerated value indicating the value returned in the Egress Action field (20.41.2.10) of the LTR: EgrOK, EgrDown, EgrBlocked, or EgrVID.

p) (if returned in the LTR) The MAC address returned in the Egress MAC Address field (20.41.2.11).

q) (if returned in the LTR) An enumerated value indicating the format of the Egress Port ID (20.41.2.12).

r) (if returned in the LTR) The Egress Port ID (20.41.2.13).

s) (if returned in the LTR) The OUI or CID and contents of any Organization-Specific TLVs (21.5.2) returned in the LTR.

12.14.7.6 Read MEP Database

12.14.7.6.1 Purpose

To obtain from the MEP the contents of one element in the MEP CCM Database.

12.14.7.6.2 Inputs

a) A reference to a particular Maintenance association Endpoint managed object (12.14.7).

b) The MEPID of a remote MEP whose information from the selected database is to be returned.

12.14.7.6.3 Outputs

a) An indication of whether the command was accepted by the MEP:

1)2) Operation rejected due to nonexistent MEP; Operation rejected due remote MEPID not configured in MA; or 3) Operation accepted.

b) An enumerated value indicating the operational state of the Remote MEP state machine (20.20) for this remote MEP:

1) RMEP_IDLE; 2) RMEP_START; 3) RMEP_FAILED; or 4) RMEP_OK.

c) The time (SysUpTime, IETF RFC 3418) at which the Remote MEP state machine last entered either the RMEP_FAILED or RMEP_OK state, or 0 if it has not yet entered either of those states.

d) The MAC address of the remote MEP (the source_address of the last received CCM) or 0 if no CCM has been received (20.19.7).

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).

f) (optional) The enumerated value from the Port Status TLV (20.19.3) from the last CCM received from the remote MEP, or the default value:

1) psNoPortStateTLV: Indicates either that no CCM has been received, or that no Port Status TLV was present in the last CCM received.

g) (optional) The enumerated value from the Interface Status TLV (20.19.4) from the last CCM received from the remote MEP, or the default value:

1) isNoInterfaceStatusTLV: Indicates either that no CCM has been received or that no Interface Status TLV was present in the last CCM received.

h) (optional) The Sender ID TLV (20.19.5) from the last CCM received from the remote MEP or the default value:

1) isNoSenderIdTLV: Indicates either that no CCM has been received, or that no Sender ID TLV was present in the last CCM received.

12.14.7.7 Transmit MEP Fault Alarm

12.14.7.7.1 Purpose

To alert the Manager to the existence of a fault in a monitored MA by issuing a Fault Alarm. Transmit MEP Fault Alarm is not a command; it is an unsolicited notification from the xmitFaultAlarm() procedure, issued upon detection of the Fault Alarm condition by the MEP Fault Notification Generator state machine (20.37), or by the MEP Mismatch Fault Notification Generator state machine (20.40). The Fault Alarm is sent to the address specified in item j) in 12.14.7.1.3.

12.14.7.7.2 Outputs

a) An indication of which Bridge is reporting the Fault Alarm.

b) A reference, in a suitable format for the method of delivering the Fault Alarm, to the reporting MEP.

c) An enumerated value, equal to the contents of the variable highestDefect (20.35.9), and to the corresponding MEP managed object [item n) in 12.14.7.1.3] or indicating the presence of a mismatch defect [item aj) in 12.14.7.1.3].

12.15 Backbone Core Bridge (BCB) management

Each BCB is a conformant S-VLAN Bridge (5.10.1) that is managed by the managed objects summarized in 12.2 and specified in detail in 12.4 through 12.14.

12.16 Backbone Edge Bridge (BEB) management

The conformance requirements for BEBs are specified in 5.12. Each of the I-components and (or) the Bcomponent of a BEB are managed using the managed objects defined in 12.2, while this subclause adds managed objects used in conjunction with those of 12.2 to manage the overall configuration and the VIPs, PIPs, and CBPs of a BEB. This subclause specifies the additional managed objects specific to the operation of BEBs, which

a) Support a BEB configuration managed object identifying all the BEB components (12.16.1);

b) Identify BEB port types (12.16.2);

c) Provide additional managed objects for management of the VIPs, PIPs, and CBPs (12.16.3, 12.16.4, 12.16.5).

Only a single view of the BEB managed objects exists. This view may only contain the objects needed for the type of BEB under management. If the BEB contains only a single I-component then the view will have only the BEB configuration, BEB port configuration, VIP configuration, and PIP configuration managed objects. If the BEB has only a B-component, then the view will have only the BEB configuration, BEB port configuration, and CBP configuration managed objects.

An instance of a managed object associated with a BEB is referenced by a unique identifier. Rules associated with the selection of this identifier are specified within this subclause. Each BEB has a single BEB configuration managed object, which is described in this subclause and illustrated in Figure 12-2. This managed object is accessed at only one of the components within a given BEB, the B-component if that is present, and the single I-component otherwise, and is referenced by that component’s MAC address.

!image

Figure 12-2—Relationship among BEB managed objects

Each VLAN Bridge component relays frames between Bridge Ports. In a BEB, these Bridge Ports can provide external connectivity directly, or can connect to other Bridge components through internal LANs. Each component contained within a BEB is associated with the BEB configuration managed object representing that BEB. The component is uniquely identified within the PBBN by the combination of a componentID unique within the BEB and by the MAC address of the BEB within that the component is contained. Each component may also be identified by the MAC address of the component that is unique within the PBBN. Within a BEB, a B-component uses two types of Bridge Ports—PNPs and CBPs—and an I-component uses two types of Bridge Ports—VIPs and CNPs. Each Bridge Port is represented by a Bridge Port managed object (12.4.2), a Provider Bridge Port Type managed object (12.13.1), and a BEB port configuration managed object (12.16.2). Each such managed object is uniquely identified, within the BEB, by the combination of the ComponentID and Port Number (12.3) of the associated Bridge Port.

Each VIP associated with an I-component is mapped to a PIP associated with that I-component. In general, multiple VIPs are associated with a single PIP. PIPs are not Bridge Ports, though they are ports on BEBs, as they are not used directly by the MAC Relay Entity (see Clause 8) of a Bridge component. Each VIP is supported by one and only one PIP. Each PIP is therefore identified uniquely by the ComponentID and Port Number of any of the VIPs that it supports and by convention is referenced by the smallest Port Number supported by the PIP. Each PIP is managed using the PIP configuration managed object (12.16.4), and each VIP is managed using the VIP configuration managed object of (12.16.3).

PIPs and CBPs of a BEB may be internal or external. Each externally accessible port on a BEB is designated as a PNP, CBP, PIP, or CNP.

The following managed objects define the semantics of the management operations specific to BEBs:

d) The BEB configuration managed object (12.16.1)

e) The BEB/PB/VLAN Bridge Port configuration managed object (12.16.2)

f) The VIP configuration managed object (12.16.3)

g) The PIP configuration managed object (12.16.4)

h) The CBP configuration managed object (12.16.5)

NOTE—All objects specified in 12.16 are persistent over power-up/down and system reboot unless otherwise specified.

12.16.1 BEB configuration managed object

The BEB configuration managed object identifies a BEB and all the managed objects that manage the BEB. The management operations that can be performed on the BEB configuration managed object are as follows:

a) Read BEB configuration (12.16.1.1)

b) Set BEB configuration (12.16.1.2)

c) Create BEB component (12.16.1.3)

d) Delete BEB component (12.16.1.4)

e) Create BEB Bridge Port (12.16.1.5)

f) Create BEB PIP (12.16.1.6)

g) Delete BEB Bridge Port (12.16.1.7)

h) Delete BEB PIP (12.16.1.8)

Items marked “(MIRP only)” shall be supported if the B-component supports the Multiple I-SID Registration Protocol (MIRP) (Clause 39).

12.16.1.1 Read BEB configuration

12.16.1.1.1 Purpose

All BEBs shall implement the read BEB configuration function to obtain information regarding the type of components and ports within a BEB. Items marked “(MIRP only)” shall be supported if the B-component supports the Multiple I-SID Registration Protocol (MIRP) (Clause 39).

12.16.1.1.2 Inputs

None.

12.16.1.1.3 Outputs

a) BEB address—the MAC address for the BEB used to access the BEB configuration managed object (8.13.8). Each BEB has a single BEB address even if the BEB has many components.

b) BEB name—a text string of up to 32 characters, of locally determined significance.

c) Number of I-components—in the BEB, which may range from 0 to many.

d) I-component addresses—a list specifying the following for each I-component or a NULL list value for no I-components:

1) ComponentID—the number of the I-component.

2) A Bridge address that is the MAC address for the I-Component (8.13.8).

e) Number of B-components—in the BEB, which may be 0 or 1.

f) B-component address—a list specifying the following for the B-component or a NULL list value for no B-component.

1) ComponentID—the number of the B-component.

2) A Bridge address that is the MAC address for the B-component (8.13.8).

g) Number of BEB ports (MAC Entities).

h) Port addresses—a list specifying the following for each port:

1) ComponentID—the number identifying the Bridge component associated with this port.

2) An interface—either that component’s Port Number for the Bridge Port, or in the case of a PIP, the PIP Index.

3) Port address—the specific MAC address associated with the port (8.13.2).

4) External port—a Boolean indicating that the port is an external port.

i) (MIRP only) A Boolean value specifying whether MIRP is (TRUE) or is not (FALSE) enabled in this B-component (Clause 39).

j) (MIRP only) The MIRP B-VID to which MIRPDUs transmitted from a PNP are to be assigned if item (k) contains the value cbpMirpGroup (1). The value 0 (the default value) indicates that the CBP PVID is to be used (39.2.1.6).

k) (MIRP only) An enumerated value specifying what destination_address and vlan_identifier are to be used when the MIRP Participant transmits an MIRPDU from a PNP:

1) cbpMirpGroup: Use the Nearest Customer Bridge group address from Table 8-1 with the MIRP B-VID (this is the default value) [item (a) in 39.2.1.6];

2) cbpMirpVlan: Use the Nearest Customer Bridge group address from Table 8-1 with the B-VID field from the Backbone Service Instance table [item (b) in 39.2.1.6]; or

3) cbpMirpTable: Use the Default Backbone Destination and B-VID fields from the Backbone Service Instance table [item (c) in 39.2.1.6].

l) (MIRP only) A Boolean value specifying the administrative status requested by management for attaching a MIRP Participant to a PNP or management Port. If TRUE, the BEB is to attach a MIRP Participant to exactly one PNP or management Port, and if FALSE, no MIRP Participant is to be present on any PNP or management Port. Default value is TRUE (39.1.2).

m) (MIRP only) The read-only Bridge Port Number (or 0, if none) of the PNP to which the MIRP Participant is attached (39.1.2).

12.16.1.2 Set BEB configuration

12.16.1.2.1 Purpose

All BEBs shall implement the set BEB configuration function to set the BEB Name. Items marked “(MIRP only)” shall be supported if the B-component supports the Multiple I-SID Registration Protocol (MIRP) (Clause 39). All items are persistent over power up or reboot.

12.16.1.2.2 Inputs

a) BEB Name—a text string of up to 32 characters, of locally determined significance.

b) (MIRP only) A Boolean value specifying whether MIRP is (TRUE) or is not (FALSE) enabled in this B-component (Clause 39).

c) (MIRP only) The MIRP B-VID to which received MIRPDUs are to be assigned if item (d) contains the value cbpMirpGroup (1). The value 0 (the default) indicates that the CBP PVID is to be used (39.2.1.6).

d) (MIRP only) An enumerated value specifying what destination_address and vlan_identifier are to be used when the MIRP Participant transmits an MIRPDU towards the MAC relay entity, either cbpMirpGroup (1), cbpMirpVlan (2), or cbpMirpTable (3) (39.2.1.6).

e) (MIRP only) A Boolean value specifying the administrative status requested by management for attaching a MIRP Participant to a PNP or management Port. If TRUE, the BEB is to attach a MIRP Participant to exactly one PNP or management Port, and if FALSE, no MIRP Participant is to be present on any PNP or management Port (39.1.2).

12.16.1.2.3 Outputs

None.

12.16.1.3 Create BEB component (optional)

12.16.1.3.1 Purpose

A BEB may implement the create BEB component function to allow the dynamic creation of new components. Components created by this command are persistent over power-up or reboot.

12.16.1.3.2 Inputs

a) ComponentType: this takes one of the following values:

1) I-Comp

2) B-Comp

12.16.1.3.3 Outputs

None.

12.16.1.4 Delete BEB component (optional)

12.16.1.4.1 Purpose

A BEB may implement the delete BEB component function to allow deletion of components. Component deletion using this command is persistent over power-up or reboot.

12.16.1.4.2 Inputs

a) ComponentID—indicates the component being deleted.

12.16.1.4.3 Outputs

None.

12.16.1.5 Create BEB Bridge Port (optional)

12.16.1.5.1 Purpose

A BEB may implement the create BEB Bridge Port function to allow dynamic creation of Bridge Ports. Bridge Ports created by this command are persistent over power-up or reboot.

12.16.1.5.2 Inputs

a) Port Index—indicates the port where the new Bridge Port will be created.

b) ComponentID—indicates the component where the new Bridge Port will be created.

c) Port type—this takes one of the following values:

1) CNP

2) PNP

3) CBP

4) VIP

12.16.1.5.3 Outputs

None.

12.16.1.6 Create BEB PIP (optional)

12.16.1.6.1 Purpose

A BEB may implement the create BEB PIP function to allow dynamic creation of PIPs. PIPs created by this command are persistent over power-up or reboot.

12.16.1.6.2 Inputs

a) Port Index—indicates the port where the new PIP will be created.

b) ComponentID—indicates the component where the new PIP will be created.

12.16.1.6.3 Outputs

None.

12.16.1.7 Delete BEB Bridge Port (optional)

12.16.1.7.1 Purpose

A BEB may implement the delete BEB Bridge Port function to allow deletion of Bridge Ports. Bridge Port deletion using this command is persistent over power-up or reboot.

12.16.1.7.2 Inputs

a) ComponentID—the component for the Bridge Port.

b) Port Number—the Port Number for the Bridge Port.

12.16.1.7.3 Outputs

None.

12.16.1.8 Delete BEB PIP (optional)

12.16.1.8.1 Purpose

A BEB may implement the delete BEB PIP function to allow deletion of PIPs. PIP deletion using this command is persistent over power-up or reboot.

12.16.1.8.2 Inputs

a) PIP Index—identifies the PIP within the BEB.

12.16.1.8.3 Outputs

None.

12.16.2 BEB/PB/VLAN Bridge Port configuration managed object

The management operations that can be performed on the BEB/PB/VLAN Bridge Port configuration managed object are as follows:

a) Read BEB/PB/VLAN Bridge port configuration (12.16.2.1).

12.16.2.1 Read BEB/PB/VLAN Bridge port configuration

12.16.2.1.1 Purpose

All BEBs shall implement the read BEB/PB/VLAN Bridge port configuration function to obtain information regarding the port type of a Bridge Port on the BEB.

12.16.2.1.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.

12.16.2.1.3 Outputs

a) Port Type—this takes one of the following values:

1) C-VLAN Port

2) PNP (identical to the PNP Bridge Port type specified by 12.13.1)

3) CNP (identical to the CNP Bridge Port type specified by 12.13.1)

4) CEP (identical to the CEP Bridge Port type specified by 12.13.1)

5) CBP (5.12, 6.11, 12.13.1 will indicate PNP)

6) VIP (5.12, 6.10, 12.13.1 will indicate PNP)

NOTE—Support for C-VLAN ports requires equipment with VLAN Bridge (5.9) functions in addition to BEB (5.12) functions. Support for CEP ports requires equipment with Provider Bridge (5.10) functions in addition to BEB functions.

12.16.3 VIP configuration managed object

The VIP configuration managed object applies to each VIP (6.10) on a BEB whether its associated PIP is externally or internally accessible.

It includes

a) The VIP configuration parameters, which provide the subset of the Bridge VLAN Configuration managed object (12.10.1) that is relevant for the configuration of the backbone service instance.

The management operations that can be performed are as follows:

b) Read VIP configuration (12.16.3.1).

c) Set VIP configuration (12.16.3.2).

12.16.3.1 Read VIP configuration

12.16.3.1.1 Purpose

All BEBs with I-components shall implement the read VIP configuration function to allow reading the current configuration of the VIPs (6.10) in an I-component of a BEB. Each VIP is configured by 12.8, 12.10, 12.16.3.2. The adminPointToPointMAC parameter is configured by 12.8.2.3.2 while the PVID and Acceptable Frame Types parameters are supplied by the Bridge Port configuration of 12.10.1.2 and 12.10.1.3.

12.16.3.1.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.

12.16.3.1.3 Outputs

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) PIP Name—a text string of up to 32 characters that identifies the PIP within a BEB with which this VIP is associated.

d) VIP-ISID—the I-SID associated with this VIP (6.10).

e) Default Backbone Destination—an EUI-48 DA (6.10.2).

g) enableConnectionIdentifier—A Boolean to indicate if the connection_identifier parameter is allowed to learn associations between a B-MAC address and a C-MAC address (6.10).

12.16.3.2 Set VIP configuration

12.16.3.2.1 Purpose

All BEBs with I-components shall implement the set VIP configuration function to allow setting the configuration of the internal VIP in the I-component of a BEB.

12.16.3.2.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) VIP-ISID—the I-SID associated with this VIP (6.10).

e) enableConnectionIdentifier—A Boolean that determines if the connection_identifier parameter is allowed to learn associations between a B-MAC address and a C-MAC address (6.10). The default value is TRUE. This parameter should be configured to FALSE at the root node of a point-tomultipoint TESI.

12.16.3.2.3 Outputs

a) Operation status. This takes one of the following values:

1) Operation rejected because the Bridge Port identified by the ComponentID and Port Number is not a VIP;

2) Operation accepted.

12.16.4 PIP configuration managed object

The PIP Configuration managed object applies to each PIP (6.10) on a BEB.

It includes the following:

a) The VIP mapping, which provides the set of VIPs multiplexed on this PIP

b) The PIP MAC address, which is used as the B-SA for all encapsulated frames

The management operations that can be performed are as follows:

c) Read PIP Configuration (12.16.4.1)

d) Optionally, Set PIP Configuration (12.16.4.2)

e) Read VIP to PIP mapping (12.16.4.3)

f) Optionally, Set VIP to PIP mapping (12.16.4.4)

g) Read PIP Priority Code Point Selection (12.16.4.5)

h) Set PIP Priority Code Point Selection (12.16.4.6)

i) Read PIP Priority Code Point Decoding Table (12.16.4.7)

j) Optionally, Set PIP Priority Code Point Decoding Table (12.16.4.8)

k) Read PIP Priority Code Point Encoding Table (12.16.4.9)

l) Optionally, Set PIP Priority Code Point Encoding Table (12.16.4.10)

m) Read PIP Use_DEI parameter (12.16.4.11)

n) Optionally, Set PIP Use_DEI parameter (12.16.4.12)

o) Read PIP Require Drop Encoding parameter (12.16.4.13)

p) Optionally, Set PIP Require Drop Encoding parameter (12.16.4.14)

12.16.4.1 Read PIP configuration

12.16.4.1.1 Purpose

All BEBs with I-components shall implement the read PIP configuration function to allow reading the current configuration of the PIP in the I-component of a BEB.

12.16.4.1.2 Inputs

a) PIP Index—an identifier for the PIP within this BEB.

12.16.4.1.3 Outputs

a) PIP B-MAC address—identifies the PIP (6.10.2).

b) PIP Name—a text string of up to 32 characters used to identify a PIP within a BEB.

c) ComponentID—the number identifying the I-component with this PIP.

d) VIP map—a bit array of 4094 bits indicating all the VIPs associated with this port.

12.16.4.2 Set PIP configuration (optional)

12.16.4.2.1 Purpose

All BEBs with I-components may implement the set PIP configuration function to set the current configuration of the PIP in the I-component of a BEB.

12.16.4.2.2 Inputs

a) PIP Index—an identifier for the PIP within this BEB.

b) PIP B-MAC address—the B-MAC address used by this PIP in the B-SA field of transmitted frames.

c) PIP Name—a text string of up to 32 characters used to identify the PIP within a BEB.

d) VIP map—a bit array of 4094 bits indicating all the VIPs associated with this PIP.

12.16.4.2.3 Outputs

a) Operation status. This takes one of the following values:

1) Operation rejected because the PIP Index is invalid.

2) Operation rejected because the VIP map identifies a port that is not a VIP.

3) Operation accepted.

12.16.4.3 Read VIP to PIP mapping

12.16.4.3.1 Purpose

All BEBs with I-components shall implement the read VIP to PIP mapping function to allow reading the VIP to PIP map information from the PIP configuration managed object.

12.16.4.3.2 Inputs

a) ComponentID—the number identifying a Bridge component with a VIP.

b) Port Number—that component's Port Number for this VIP.

12.16.4.3.3 Outputs

a) ComponentID—the number identifying a Bridge component with a VIP.

b) Port Number—that component’s Port Number for this VIP.

c) PIP Index—identifies the PIP supporting this VIP.

d) PIP B-MAC address—the B-MAC address used by this PIP supporting this VIP (6.10.2).

e) PIP Name—a text string of up to 32 characters identifying the PIP supporting this VIP.

12.16.4.4 Set VIP to PIP mapping (optional)

12.16.4.4.1 Purpose

All BEBs with I-components may implement the set VIP to PIP mapping function to allow binding individual VIPs to PIPs. The set VIP to PIP mapping function allows setting map entries for individual VIPs while the set PIP configuration function sets the entire VIP to PIP map.

12.16.4.4.2 Inputs

a) ComponentID—the number identifying a Bridge component with a VIP.

b) Port Number—that component’s Port Number for this VIP.

c) PIP Index—an identifier for this PIP within this component of the BEB.

12.16.4.4.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 VIP.

2) Operation rejected because the PIP Index does not identify a PIP within the specified component.

3) Operation accepted.

12.16.4.5 Read PIP Priority Code Point Selection

12.16.4.5.1 Purpose

To read which row of the Priority Code Point Encoding Table and Priority Code Point Decoding Table (6.10.3) is currently selected for use on this PIP.

12.16.4.5.2 Inputs

a) PIP Index—an identifier for this PIP within this component of the BEB.

12.16.4.5.3 Outputs

a) Priority Code Point Selection: this takes one of the following values:

1) 8P0D

2) 7P1D

3) 6P2D

4) 5P3D

12.16.4.6 Set PIP Priority Code Point Selection

12.16.4.6.1 Purpose

To set which row of the Priority Code Point Encoding Table and Priority Code Point Decoding Table (6.10.3) will be selected for use on this PIP.

12.16.4.6.2 Inputs

a) PIP Index—an identifier for this PIP within this component of the BEB.

b) Priority Code Point Selection—this takes one of the following values:

1) 8P0D

2) 7P1D

3) 6P2D

4) 5P3D

12.16.4.6.3 Outputs

None.

12.16.4.7 Read PIP Priority Code Point Decoding Table

12.16.4.7.1 Purpose

To read the current contents of a row in the Priority Code Point Decoding Table (6.10.3) for a PIP.

12.16.4.7.2 Inputs

a) PIP Index—an identifier for this PIP.

b) Priority Code Point Row—this takes one of the following values:

1) 8P0D

2) 7P1D

3) 6P2D

4) 5P3D

12.16.4.7.3 Outputs

a) Priority value for Priority Code Point 0: Integer in range 0–7.

b) Drop_eligible value for Priority Code Point 0: Boolean.

c) Priority value for Priority Code Point 1: Integer in range 0–7.

d) Drop_eligible value for Priority Code Point 1: Boolean.

e) Priority value for Priority Code Point 2: Integer in range 0–7.

f) Drop_eligible value for Priority Code Point 2: Boolean.

g) Priority value for Priority Code Point 3: Integer in range 0–7.

h) Drop_eligible value for Priority Code Point 3: Boolean.

i) Priority value for Priority Code Point 4: Integer in range 0–7.

j) Drop_eligible value for Priority Code Point 4: Boolean.

k) Priority value for Priority Code Point 5: Integer in range 0–7.

l) Drop_eligible value for Priority Code Point 5: Boolean.

m) Priority value for Priority Code Point 6: Integer in range 0–7.

n) Drop_eligible value for Priority Code Point 6: Boolean.

o) Priority value for Priority Code Point 7: Integer in range 0–7.

p) Drop_eligible value for Priority Code Point 7: Boolean.

12.16.4.8 Set PIP Priority Code Point Decoding Table (optional)

12.16.4.8.1 Purpose

To modify the contents of a row in the Priority Code Point Decoding Table (6.10.3) for a PIP.

12.16.4.8.2 Inputs

a) PIP Index—an identifier for this PIP.

b) b) Priority Code Point Row—this takes one of the following values:

1) 8P0D

2) 7P1D

3) 6P2D

4) 5P3D

c) Priority value for Priority Code Point 0: Integer in range 0–7.

d) Drop_eligible value for Priority Code Point 0: Boolean.

e) Priority value for Priority Code Point 1: Integer in range 0–7.

f) Drop_eligible value for Priority Code Point 1: Boolean.

g) Priority value for Priority Code Point 2: Integer in range 0–7.

h) Drop_eligible value for Priority Code Point 2: Boolean.

i) Priority value for Priority Code Point 3: Integer in range 0–7.

j) Drop_eligible value for Priority Code Point 3: Boolean.

k) Priority value for Priority Code Point 4: Integer in range 0–7.

l) Drop_eligible value for Priority Code Point 4: Boolean.

m) Priority value for Priority Code Point 5: Integer in range 0–7.

n) Drop_eligible value for Priority Code Point 5: Boolean.

o) Priority value for Priority Code Point 6: Integer in range 0–7.

p) Drop_eligible value for Priority Code Point 6: Boolean.

q) Priority value for Priority Code Point 7: Integer in range 0–7.

r) Drop_eligible value for Priority Code Point 7: Boolean.

12.16.4.8.3 Outputs

None.

12.16.4.9 Read PIP Priority Code Point Encoding Table

12.16.4.9.1 Purpose

To read the current contents of a row in the Priority Code Point Encoding Table (6.10.3) for a Port.

12.16.4.9.2 Inputs

a) PIP Index—an identifier for this PIP.

b) Priority Code Point Row: this takes one of the following values:

1) 8P0D

2) 7P1D

3) 6P2D

4) 5P3D

12.16.4.9.3 Outputs