802.1Qaw-2009

8/8/2019 802.1Qaw-2009

http://slidepdf.com/reader/full/8021qaw-2009 1/90

IEEE Std 802.1Qaw™-200(Amendment to

IEEE Std 802.1Q™-2005)

IEEE Standard forLocal and metropolitan area networks—

Virtual Bridged Local Area Networks

Amendment 9: Management of Data

Driven and Data Dependent

Connectivity Faults

IEEE3 Park AvenueNew York, NY 10016-5997, USA

25 July 2009

IEEE Computer Society

Sponsored by theLAN/MAN Standards Committee

8 0

2 . 1

Q a w

T M

8/8/2019 802.1Qaw-2009


8/8/2019 802.1Qaw-2009


IEEE Std 802.1Qaw™-2009(Amendment to

IEEE Std 802.1Q™-2005)

IEEE Standard for

Local and metropolitan area networks—


Amendment 9: Management of DataDriven and Data DependentConnectivity Faults

Sponsor

LAN/MAN Standards Committeeof theIEEE Computer Society

Approved 17 June 2009

IEEE-SA Standards Board

8/8/2019 802.1Qaw-2009


Abstract: This amendment extends the connectivity fault management capabilities introduced in

IEEE Std 802.1ag-2007 to include tools to facilitate diagnosis and isolation of faults sensitive to, or

caused by, particular data patterns in frames transmitted by a service user.

Keywords: fault management, LANs, local area networks, MAC Bridges, MANs, metropolitan areanetworks, OAM, transparent bridging, VLANS

The Institute of Electrical and Electronics Engineers, Inc.

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

Copyright © 2009 by the Institute of Electrical and Electronics Engineers, Inc.

All rights reserved. Published 25 July 2009. Printed in the United States of America.

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

PDF: ISBN 978-0-7381-5990-4 STD95940

Print: ISBN 978-0-7381-5991-1 STDPD95940

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.

8/8/2019 802.1Qaw-2009


IEEE Standards documents are developed within the IEEE Societies and the Standards Coordinating Committees of

theIEEE Standards Association (IEEE-SA) Standards Board. The IEEE develops its standards through a

consensusdevelopment process, approved by the American National Standards Institute, which brings together

volunteersrepresenting varied viewpoints and interests to achieve the final product. Volunteers are not necessarily members

of theInstitute and serve without compensation. While the IEEE administers the process and establishes rules to promote

fairnessin the consensus development process, the IEEE does not independently evaluate, test, or verify the accuracy of any

of theinformation or the soundness of any judgments contained in its standards.

Use of an IEEE Standard is wholly voluntary. The IEEE disclaims liability for any personal injury, property or otherdamage,

of any nature whatsoever, whether special, indirect, consequential, or compensatory, directly or indirectly resultingfrom the

publication, use of, or reliance upon this, or any other IEEE Standard document.

The IEEE does not warrant or represent the accuracy or content of the material contained herein, and expressly disclaimsany

express or implied warranty, including any implied warranty of merchantability or fitness for a specific purpose, or thatthe

use of the material contained herein is free from patent infringement. IEEE Standards documents are supplied “AS IS.”

The existence of an IEEE Standard does not imply that there are no other ways to produce, test, measure, purchase,

market,or provide other goods and services related to the scope of the IEEE Standard. Furthermore, the viewpoint expressed

at thetime a standard is approved and issued is subject to change brought about through developments in the state of the art

andcomments received from users of the standard. Every IEEE Standard is subjected to review at least every five years

forrevision or reaffirmation, or every ten years for stabilization. When a document is more than five years old and has not

beenreaffirmed, or more than ten years old and has not been stabilized, it is reasonable to conclude that its contents,

although stillof some value, do not wholly reflect the present state of the art. Users are cautioned to check to determine that

they have thelatest edition of any IEEE Standard.

In publishing and making this document available, the IEEE is not suggesting or rendering professional or other servicesfor,

or on behalf of, any person or entity. Nor is the IEEE undertaking to perform any duty owed by any other person orentity to

another. Any person utilizing this, and any other IEEE Standards document, should rely upon the advice of acompetent

professional in determining the exercise of reasonable care in any given circumstances.

Interpretations: Occasionally questions may arise regarding the meaning of portions of standards as they relate to

specificapplications. When the need for interpretations is brought to the attention of IEEE, the Institute will initiateaction to

prepareappropriate responses. Since IEEE Standards represent a consensus of concerned interests, it is important to ensure

that anyinterpretation has also received the concurrence of a balance of interests.For this reason, IEEE and the members of

itssocieties and Standards Coordinating Committees are not able to provide an instant response to interpretation requests

exceptin those cases where the matter has previouslyreceived formal consideration. A statement, written or oral, that is

notprocessed in accordance with theIEEE-SA Standards Board Operations Manual shall not be considered the official

positionof IEEE or any of its committees and shall not be considered to be, nor be relied upon as, a formal interpretation of

the IEEE.At lectures, symposia, seminars, or educational courses, an individual presenting information on IEEE standards

shallmakeit clear that his or her views should be considered the personal views of that individual rather than the formal

position,explanation, or interpretation of the IEEE. Comments for revision of IEEE Standards are welcome from any

interested party, regardless of membership affiliation withIEEE. Suggestions for changes in documents should be in the

form of a proposed change of text, together with appropriatesupporting comments. Recommendations to change the status

of a stabilized standard should include a rationale as to why arevision or withdrawal is required.

Comments and recommendations on standards, and requests for interpretations should beaddressed to:

Secretary, IEEE-SA Standards Board

445 Hoes Lane

Piscataway, NJ 08854USA

Authorization to photocopy portions of any individual standard for internal or personal use is granted by the Institute

ofElectrical and Electronics Engineers, Inc., provided that the appropriate fee is paid to Copyright Clearance Center.

Toarrange for payment of licensing fee, please contact Copyright Clearance Center, Customer Service, 222 Rosewood

Drive,Danvers, MA 01923 USA; +1 978 750 8400. Permission to photocopy portions of any individual standard for

educationalclassroom use can also be obtained through the Copyright Clearance Center.

8/8/2019 802.1Qaw-2009


iv Copyright © 2009 IEEE. All rights reserved.

Introduction

IEEE Std 802.1Qaw provides additional capability to Connectivity Fault Management (Clause 18 through

Clause 22) to achieve data driven and data dependent connectivity fault management.

Notice to users

Laws and regulations

Users of these documents should consult all applicable laws and regulations. Compliance with the

provisions of this standard does not imply compliance to any applicable regulatory requirements.

Implementers of the standard are responsible for observing or referring to the applicable regulatory

requirements. IEEE does not, by the publication of its standards, intend to urge action that is not in

compliance with applicable laws, and these documents may not be construed as doing so.

Copyrights

This document is copyrighted by the IEEE. It is made available for a wide variety of both public and private

uses. These include both use, by reference, in laws and regulations, and use in private self-regulation,

standardization, and the promotion of engineering practices and methods. By making this document

available for use and adoption by public authorities and private users, the IEEE does not waive any rights in

copyright to this document.

Updating of IEEE documents

Users of IEEE standards should be aware that these documents may be superseded at any time by the

issuance of new editions or may be amended from time to time through the issuance of amendments,

corrigenda, or errata. An official IEEE document at any point in time consists of the current edition of the

document together with any amendments, corrigenda, or errata then in effect. In order to determine whether

a given document is the current edition and whether it has been amended through the issuance of

amendments, corrigenda, or errata, visit the IEEE Standards Association website at

http://ieeexplore.ieee.org/xpl/standards.jsp, or contact the IEEE at the address listed previously.

For more information about the IEEE Standards Association or the IEEE standards development process,

visit the IEEE-SA website at http://standards.ieee.org.

Errata

Errata, if any, for this and all other standards can be accessed at the following URL: http://

standards.ieee.org/reading/ieee/updates/errata/index.html. Users are encouraged to check this URL for

errata periodically.

This introduction is not part of IEEE Std 802.1Qaw-2009, IEEE Standards for Local and Metropolitan Area

Networks—Virtual Bridged Local Area Networks—Amendment 9: Management of Data Driven and Data Dependent

Connectivity Faults.

http://standards.ieee.org/

http://standards.ieee.org/reading/ieee/updates/errata/index.html





http://standards.ieee.org/

8/8/2019 802.1Qaw-2009


Copyright © 2009 IEEE. All rights reserved. v

Interpretations

Current interpretations can be accessed at the following URL: http://standards.ieee.org/reading/ieee/interp/

index.html.

Patents

Attention is called to the possibility that implementation of this amendment may require use of subject

matter covered by patent rights. By publication of this amendment, no position is taken with respect to the

existence or validity of any patent rights in connection therewith. 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 amendment 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.

http://standards.ieee.org/reading/ieee/interp/index.html





8/8/2019 802.1Qaw-2009


vi Copyright © 2009 IEEE. All rights reserved.

Participants

At the time this amendment was submitted to the IEEE-SA Standards Board for approval, the IEEE 802.1

Working Group had the following membership:

Tony Jeffree, Chair

Paul Congdon, Vice Chair

Stephen Haddock, Chair, Interworking Task GroupLinda Dunbar, Editor

Osama Aboul-MagdZehavit AlonCaitlin Bestler Jan BialkowskiRob BoatrightJean-Michel BonnamyPaul Bottorff Rudolf Brandner Craig W. CarlsonWeiying ChengRao Cherukuri

Diego Crupnicoff Claudio DesantiZhemin DingHesham M. ElbakouryDavid Elie-Dit-CosaqueJanos FarkasDonald Fedyk

Norman FinnRobert Frazier John Fuller Geoffrey Garner Anoop GhanwaniFranz GoetzEric GrayKaranvir GrewalCraig Gunther Mitch GusatAsif HazarikaCharles HudsonRomain Insler Michael Johas Teener Abhay Karandikar

Prakash KashyapHal KeenKeti KilcreaseYongbum KimPhilippe KleinMike KoVinod Kumar Bruce KwanKari LaihonenYannick Le Goff Michael Lerer

Gael MaceBen Mack-CraneDavid MartinRiccardo MartinottiAlan McGuireJames McIntoshMenucher MenucheryJohn Messenger Matthew MoraEric MultanenKevin NolishHiroshi OhtaDavid OlsenDonald PannellGlenn ParsonsJoseph Pelissier David PetersonHayim PoratMax PritikinAnanda RajagopalKaren RandallGuenter Roeck

Josef Roese

Derek J. Rohde

Dan Romascanu

Moran Roth

Jessy V. Rouyer

Hyunsurk Ryu

Jonathan Sadler

Ali Sajassi

Joseph Salowey

Panagiotis Saltsidis

Satish Sathe

John Sauer Michael Seaman

Koichiro Seto

Himanshu Shah

Nurit Sprecher

Kevin B. Stanton

Robert A. Sultan

Muneyoshi Suzuki

George Swallow

Attila Takacs

Patricia Thaler

Oliver Thorp

Manoj Wadekar

Yuehua Wei

Brian WeisBert Wijnen

Michael D. Wright

Chien-Hsien Wu

Ken Young

Glen Zorn

8/8/2019 802.1Qaw-2009


Copyright © 2009 IEEE. All rights reserved. vii

The following members of the individual balloting committee voted on this standard. Balloters may have

voted for approval, disapproval, or abstention.

When the IEEE-SA Standards Board approved this standard on 17 June 2009, it had the following

membership:

Robert M. Grow, Chair

Thomas Prevost, Vice Chair

Steve M. Mills, Past Chair

Judith Gorman, Secretary

*Member Emeritus

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

Howard L. Wolfman, TAB RepresentativeMichael Janezic, NIST RepresentativeSatish Aggarwal, NRC Representative

Michelle D. Turner IEEE Standards Program Manager, Document Development

Kathryn Cush IEEE Standards Program Manager, Technical Program Development

Thomas Alexander Butch AntonDanilo AntonelliEdward CarleyJames Carlo

Juan CarreonKeith ChowCharles Cook Russell DietzThomas DineenLinda Dunbar Sourav DuttaDavid Elie-Dit-CosaqueDonald Fedyk Yukihiro FujimotoDevon GayleReinhard Gloger Sergiu GomaRandall GrovesC. Guy

John HawkinsAtsushi ItoRaj JainTony JeffreeShinkyo Kaku

Piotr KarockiStuart J. KerryYongbum KimJohn LemonMichael Lerer Li LiWilliam LumpkinsBen Mack-CraneDavid MartinJonathon MclendonRichard MellitzGary MichelWade Midkiff Michael S. Newman

Nick S. A. Nikjoo

Paul Nikolich

Kevin NolishSatoshi ObaraGlenn ParsonsMaximilian RiegelRobert Robinson

Jessy V. Rouyer Randall Safier Behcet SarikayaBartien SayogoMichael SeamanKapil Sood

Nurit Sprecher Thomas StaraiWalter Struppler Robert A. SultanWilliam Taylor Michael Johas Teener Prabodh VarshneyMaarten VissersOren Yuen

John Barr Karen BartlesonVictor Berman

Ted BurseRichard DeBlasioAndy DrozdMark Epstein

Alexander GelmanJim HughesRichard H. Hulett

Young Kyun KimJoseph L. Koepfinger*John Kulick

David J. Law

Ted OlsenGlenn Parsons

Ronald C. Petersen Narayanan RamachandranJon Walter RosdahlSam Sciacca

8/8/2019 802.1Qaw-2009


8/8/2019 802.1Qaw-2009


8/8/2019 802.1Qaw-2009


8/8/2019 802.1Qaw-2009


Copyright © 2009 IEEE. All rights reserved. xi

List of figures

Figure 19-2 Maintenance association End Point (MEP) ..................................................................... 44

Figure 19-3 MIP Half Function ........................................................................................................... 46

Figure 29-1 Forward path test (FPT) ................................................................................................... 52Figure 29-2 Return path test ................................................................................................................ 53

Figure 29-3 Combination of forward path test and return path test..................................................... 54

Figure 29-4 Detailed Functions of Reflection Responder ................................................................... 55

Figure 29-5 RFM Receiver on an non-MP.......................................................................................... 58

Figure 29-6 Return Path Decapsulator Responder .............................................................................. 59

Figure 29-7 RR Filter state machine.................................................................................................... 64

Figure 29-8 RR Encapsulation state machine...................................................................................... 65

Figure 29-9 RR Transmit state machine .............................................................................................. 65

Figure 29-10 RFM Receiver state machine ........................................................................................... 67

Figure 29-11 Decapsulator Responder state machine............................................................................ 69

8/8/2019 802.1Qaw-2009


8/8/2019 802.1Qaw-2009


Copyright © 2009 IEEE. All rights reserved. xiii

List of tables

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

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

Table 17-16 Sensitive managed objects (of DDCFM) for read............................................................. 26

Table 17-15 Sensitive managed objects (of DDCFM): tables and notifications................................... 26

Table 19-1 Actions taken by MP OpCode Demultiplexers ................................................................. 45

Table 21-4 OpCode Field range assignments...................................................................................... 49

Table 21-6 Type Field values .............................................................................................................. 49

Table 29-1 RFM format....................................................................................................................... 70

Table 29-2 SFM format ....................................................................................................................... 71

8/8/2019 802.1Qaw-2009


8/8/2019 802.1Qaw-2009


Copyright © 2009 IEEE. All rights reserved. 1

IEEE Standard for

Local and metropolitan area networks—


Amendment 9: Management of DataDriven and Data DependentConnectivity Faults

IMPORTANT NOTICE: This standard is not intended to ensure safety, security, health, or

environmental protection in all circumstances. Implementers of the standard are responsible for determining appropriate safety, security, environmental, and health practices or regulatory requirements.

This IEEE document is made available for use subject to important notices and legal disclaimers. Thesenotices and disclaimers appear in all publications containing this document and may be found under theheading “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.

Editorial Note

This amendment specifies changes to be applied to the base text of IEEE Std 802.1Q-2005 as amended by

IEEE Std 802.1adTM-2005, IEEE Std 802.1agTM-2007, IEEE802.1ak TM-2007, IEEE Std 802.1ahTM-2008, and

IEEE Std 802.1apTM-2008. Text shown in bold italics in this amendment defines the editing instructions

necessary to changes to this base text. Three editing instructions are used: change, delete, and insert .

Change is used to make a change to existing material. The editing instruction specifies the location of the

change and describes what is being changed. Changes to existing text may be clarified using strikeout

markings to indicate removal of old material, and underscore markings to indicate addition of new material).

Delete removes existing material. Insert adds new material without changing the existing material.

Insertions may require renumbering. If so, renumbering instructions are given in the editing instruction.

Editorial notes will not be carried over into future editions of IEEE Std 802.1Q.

http://standards.ieee.org/IPR/disclaimers.html




8/8/2019 802.1Qaw-2009


IEEE IEEE STANDARD FOR LOCAL AND METROPOLITAN AREA NETWORKSStd 802.1Qaw-2009

2 Copyright © 2009 IEEE. All rights reserved.

1. Overview

Insert the following after the initial paragraphs of Clause 1:

The data driven and data dependent connectivity fault management capabilities include tools to facilitate

diagnosis and isolation of faults sensitive to, or caused by, particular data patterns in transmitted frames.

1.1 Scope

Insert the following at end of subclause 1.1, relettering the bullet points so that they follow in order from

those in the existing text.

This standard specifies connectivity fault management 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 maintenance points 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

a) Defines the extensions to connectivity fault management 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;

b) Describes the protocols and procedures for data driven and data dependent connectivity fault

management (DDCFM).

8/8/2019 802.1Qaw-2009


AMENDMENT 9: MANAGEMENT OF DATA DRIVEN AND DATA DEPENDENT CONNECTIVITY FAULTS IEEEStd 802.1Qaw-2009


3. Definitions

Insert the following definitions, renumbering to place them in the appropriate collating order.

3.1 data driven and data dependent connectivity fault management (DDCFM): DDCFM comprises

capabilities to facilitate detecting and isolating data driven and data dependent faults in Virtual Bridged

Local Area Networks.

3.2 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.3 Decapsulator Responder (DR): An entity for decapsulating Send Frame Messages and sending the

decapsulated frames towards destinations specified by their own destination_address field.

3.4 forward path test (FPT): A test to determine if a data frame that matches the specified filter

condition can reach a specific location within a network.

3.5 Reflected Frame Message (RFM): A CFM PDU transmitted by a Reflection Responder in order to

perform forward path test.

3.6 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.7 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.8 Reflected Frame Message (RFM) Receiver: A function on a bridge port, an end station, or a test

equipment to receive Reflected Frame Message(s) and pass them to the corresponding, non-standardized,

RFM analyzer.

3.9 Send Frame Message (SFM):A CFM PDU destined to a Decapsulator Responder in order to perform

return path test.

3.10 Send Frame Message (SFM) Originator:A function on a bridge interface, an end station, or a test

equipment to send SFM encapsulated data frames.

8/8/2019 802.1Qaw-2009


8/8/2019 802.1Qaw-2009




4. Abbreviations

Insert the following definitions, placing them in the appropriate collating order (alphabetically):

DDCFM data driven and data dependent connectivity fault management

DDF data driven and data dependent fault

DR Decapsulator Responder

FPT forward path test

LAG Link Aggregation Group

RFM Reflected Frame Message

RPT return path test

RR Reflection Responder

SFM Send Frame Message

8/8/2019 802.1Qaw-2009


8/8/2019 802.1Qaw-2009




5. Conformance

5.4.1.4 Connectivity Fault Management (optional)

In subclause 5.4.1.4, insert the following additional items after current item o) and reletter remaining lettered items:

p) Support the creation and operation of Reflection Responder and RFM Receiver for the forward path

test.q) Support the creation and operation of Decapsulator Responder and SFM Originator for the return

path test.

8/8/2019 802.1Qaw-2009


8/8/2019 802.1Qaw-2009




12. Bridge management

12.1.1 Configuration management

Insert the following bullet item, relettered if necessary:

h) The ability to create and delete the functional elements of DDCFM and to control their operations.

12.1.2 Fault management

Insert the following points immediately following point 4) of IEEE Std 802.1ag-2007:

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.

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.2 Managed objects

Insert the following bullet item, relettered if necessary after the last item of IEEE Std 802.1ag-2007/IEEE

Std 802.1ah-2008/IEEE Std 802.1ap-2008:

l) The DDCFM Entities (12.18)

Insert a new subclause 12.18 as follows:

12.18 DDCFM entities

The following are the DDCFM managed objects in a Bridge:

a) DDCFM Stack managed object (12.18.1)

b) Reflection Responder managed object (12.18.2)

c) RFM Receiver managed object (12.18.3)d) Decapsulator Responder managed object (12.18.4)

e) SFM Originator managed object (12.18.5)

12.18.1 DDCFM Stack managed object

There is one DDCFM Stack managed object per Bridge. It allows the network administrator to retrieve

DDCFM entities configured on a particular Bridge Port or an aggregated IEEE802.3 port within a Bridge

Port. The management operation that can be performed is

a) Read DDCFM Stack managed object (12.18.1.1)

12.18.1.1 Read DDCFM Stack managed object

12.18.1.1.1 Purpose

To retrieve DDCFM entities configured on a particular Bridge Port or an aggregated IEEE802.3 port within

a Bridge Port.

12.18.1.1.2 Input

a) An interface, either a Bridge Port, or an aggregated IEEE802.3 port within a Bridge Port

8/8/2019 802.1Qaw-2009




12.18.1.1.3 Outputs

a) Operation status. This takes one of the following values:

1) Operation rejected because of invalid reference to an interface;

2) Operation accepted, but there is no DDCFM entity configured on the specified interface; or

3) Operation accepted, there are (is a) DDCFM entities (entity) configured on the specified

interface, and b) If there are DDCFM entities configured on the specified interface, the following attributes should be

returned:

1) An RR is configured, its associated maintenance domain, and the value indicating its direction;

and/or

2) An RFM Receiver is configured, its associated maintenance domain; and/or

3) A DR is configured, its associated maintenance domain, and its associated maintenance

association; and/or

4) An SFM Originator is configured, its associated maintenance domain, its associated

maintenance association, and the value indicating its direction.

12.18.2 Reflection Responder managed object

The management operations that can be performed on the Reflection Responder managed object are asfollows:

a) Create Reflection Responder managed object (12.18.2.1)

b) Write Reflection Responder managed object’s attributes (12.18.2.2)

c) Read Reflection Responder managed object’s attributes (12.18.2.3)

d) Delete Reflection Responder managed object (12.18.2.4)

e) Activate Reflection Responder (12.18.2.5)

f) Deactivate Reflection Responder (12.18.2.6)

12.18.2.1 Create Reflection Responder managed object

12.18.2.1.1 Purpose

To create a Reflection Responder. After the creation, all the writable attributes have their default values

unless being configured differently by the Write Reflection Responder managed object operation

(12.18.2.2). The Reflection Responder is in the inactive state after the creation and remains so until activated

by a subsequent Activate Reflection Responder operation (12.18.2.5).

12.18.2.1.2 Inputs

a) A reference to a particular RR managed object, which includes the following:

1) An interface (either a Bridge Port or an aggregated IEEE802.3 port within a Bridge Port) on

which the Reflection Responder is defined. The interface identifier could be MAC address or

port identifier.

2) A reference to a particular Maintenance Domain managed object (12.14.5).

3) A value indicating the direction in which the RR faces, which can be either Down [Active SAP

is further away from the Frame filtering entity (default)], or Up (Active SAP is closer to the

Frame filtering entity).

12.18.2.1.3 Outputs


1) Operation rejected because of invalid interface reference or invalid Maintenance Domain

level; or

8/8/2019 802.1Qaw-2009




2) Operation accepted.

12.18.2.2 Write Reflection Responder managed object

12.18.2.2.1 Purpose

To configure and alter the value of one or more writable attribute(s) of an RR managed object. The attributes

of an RR managed object cannot be modified when the RR is active.

12.18.2.2.2 Inputs

a) Reference to a RR managed object [12.18.2.1.2, item a)].

b) Writable attributes are as follows:

1) Reference to a Maintenance Association managed object (12.14.6) within the RR’s

Maintenance Domain. If set to 0, the MA associated with the filtered frame shall be used for the

RFM emitted by the RR.

2) Reflection Filter definition(s), which is to specify what data frames are selected to be reflected.

Multiple filters can be combined together by “&& (and)”, “|| (or)”, or “! (negation)” operationswith precedence association being determined by “( )”. DDCFM-capable bridges shall support

each of the following filter primitives. Implementers may support additional filters, such as

length of data frame being equal, larger or smaller than a particular value.

— All;

— VID== vid; This primitive uses SVID if the RR is defined on a S component, and

CVID if the RR is defined on a C component. Untagged frame shall not be

selected by this filter primitive;

— DA == xx.xx.xx.xx.xx.xx;

— SA == xx.xx.xx.xx.xx.xx;

— The first 2 bytes of the EtherType field ==xx;

3) Sampling Interval (29.2.3.4).

4) Reflection Target Address, which is a MAC address to which the reflected frames are targeted.

Only individual address is allowed for the Reflection Target Address. The default is the

source_address of the selected data frame being used for Reflection Target Address.

5) Continue option, indicating whether or not the selected data frames are to be continued towards

the destination_address specified in the data frame. The default is true to allow data frames to

be forwarded to their destinations.

6) Boolean variable indicating if the duration is in seconds or in number of data frames.

7) Duration in seconds for the Reflection Responder to remain active after being activated.

Minimum 1 and maximum is implementation dependent.

8) The number data frames for the Refection Responder to reflect after being activated. Once this

frame count is reached, the Refection Responder shall be de-activated automatically. Default is

0, which means the duration is limited by RR’s timer.

9) The priority and drop_eligible parameters to be used in the transmitted encapsulated frames

(default value: the highest priority, i.e. that with the highest numerical value, allowed to pass

through the Bridge Port for any of the VID. Default value for drop_eligible is false).

10) FloodingEnabled Flag indicating if flooding is allowed or not if Egress port cannot be

identified for RFM by the Filtering Database.

11) Truncation flag indicating if the received data frame should be truncated to keep the length of

RFM encapsulated frame not exceeding the Maximum Service Data Unit Size (6.5.8). If the

Truncation flag is not set and the RFM encapsulated frame exceeds the Maximum Service Data

Unit Size (6.5.8), the filtered data frame is fragmented to two smaller frames and encapsulated

in two separate RFMs.

8/8/2019 802.1Qaw-2009




12.18.2.2.3 Outputs


1) Operation rejected because the referenced RR managed object does not exist;

2) Operation rejected because of one or more invalid writable attribute(s);

3) Operation rejected because the referenced RR is active; or


12.18.2.3 Read Reflection Responder managed object

12.18.2.3.1 Purpose

To retrieve values of attributes in a Reflection Responder managed object.

12.18.2.3.2 Input

a) Reference to a particular RR managed object [12.18.2.1.2 item a)]

12.18.2.3.3 Outputs


1) Operation rejected because of invalid reference to the RR managed object;

2) Operation rejected because there is no Reflection Responder with the given reference; or


b) If the operation is accepted, the following attributes for the Responder should be returned:

1) Reference to the RR managed object;

2) Reference to a Maintenance Association managed object (12.14.6) for the RFMs generated by

the RR (writable);

3) Reflection Filter definition(s) (writable);

4) Sampling Interval (writable);

5) The Reflection Target Address (writable);6) Continue option (writable);

7) Duration for Reflection Responder to stay active after being activated (writable);

8) DurationInTimeFlag (writable);

9) The priority and drop_eligible parameters to be used in the transmitted RFMs (writable);

10) FloodingFlag (writable);

11) Truncation flag (writable);

12) Activation status (true or false);

13) Remaining time or count left for the RR to be active; and

14) nextRFMtransID (29.3.1.16) value.

12.18.2.4 Delete Reflection Responder managed object

12.18.2.4.1 Purpose

To delete a Reflection Responder managed object. If the corresponding Reflection Responder is still active,

the deletion will de-activate the Reflection Responder and then delete the corresponding managed object.

12.18.2.4.2 Input

a) Reference to a RR managed object [12.18.2.1.2, item a)]

8/8/2019 802.1Qaw-2009




12.18.2.4.3 Outputs

a) Operation status: this takes one of the following values:

1) Operation rejected because of invalid reference to RR;

2) Operation rejected because the referenced RR managed does not exist; or


12.18.2.5 Activate Reflection Responder

12.18.2.5.1 Purpose

To activate a Reflection Responder.

Depending on the filter conditions specified for each RR, some RRs can potentially reflect large amount of

data frames into the network, which could cause excessive extra traffic injected into the network and impact

network performance. For those RRs, it is recommended that no more than one instance of the Reflection

Responder (RR) managed object be activated per MD for an RR associated with an MP and that no more

than one instance of the RR managed object be activated per VLAN for an RR not associated with an MP

(e.g., for an RR created on a bridge port).

12.18.2.5.2 Inputs

a) Reference to a RR managed object [12.18.2.1.2 a)].

12.18.2.5.3 Outputs


1) Operation rejected because invalid reference or the referenced RR does not exist;

2) Operation rejected because of the referenced RR already being activated; or


12.18.2.6 De-Activate Reflection Responder

12.18.2.6.1 Purpose

To de-activate an active Reflection Responder before its duration expires.

12.18.2.6.2 Input

a) Reference to a RR managed object [12.18.2.1.2, item a)].

12.18.2.6.3 Outputs


1) Operation rejected because invalid reference or the referenced RR does not exist;

2) Operation rejected because of the referenced RR not being activated; or


12.18.3 RFM Receiver managed object

The management operations that can be performed on the RFM Receiver managed object are as follows:

a) Create RFM Receiver managed object (12.18.3.1)

b) Delete RFM Receiver managed object (12.18.3.2)

8/8/2019 802.1Qaw-2009




An RFM Receiver is active when the corresponding RFM Receiver managed object is created. Therefore,

there is no “Activate and De-activate” operations for the RFM Receiver managed object.

12.18.3.1 Create RFM Receiver managed object

12.18.3.1.1 Purpose

To create an RFM Receiver managed object. Once an RFM Receiver managed object is created, the

corresponding RFM Receiver is able to receive RFMs.

12.18.3.1.2 Inputs

a) Reference to an RFM Receiver managed object, which could be either

1) Reference to an MP; or

2) An interface (either a Bridge Port or an aggregated IEEE802.3 port within a Bridge Port) on

which RFM Receiver is created and a reference to the corresponding RR’s Maintenance

Domain managed object.

12.18.3.1.3 Outputs


1) Operation rejected because of invalid reference to the RFM Receiver managed object;

2) Operation rejected because the referenced RFM Receiver managed object already exists; or


12.18.3.2 Delete RFM Receiver managed object

12.18.3.2.1 Purpose

To delete an RFM Receiver managed object.

12.18.3.2.2 Input

a) Reference to an RFM Receiver managed object [12.18.3.1.2, item a)]

12.18.3.2.3 Outputs


1) Operation rejected because of invalid reference to the RFM Receiver managed object;

2) Operation rejected because the referenced RFM Receiver managed object does not exist; or


12.18.4 Decapsulator Responder managed object

The management operations that can be performed on the Decapsulator Responder managed object are as

follows:

a) Create Decapsulator Responder managed object (12.18.4.1)

b) Read Decapsulator Responder managed object (12.18.4.2)

c) Write to Decapsulator Responder managed object’s attributes (12.18.4.3)

d) Delete Decapsulator Responder managed object (12.18.4.4)

e) Activate Decapsulator Responder (12.18.4.5)

f) De-activate Decapsulator Responder (12.18.4.6)

8/8/2019 802.1Qaw-2009




12.18.4.1 Create Decapsulator Responder managed object

12.18.4.1.1 Purpose

To create a Decapsulator Responder managed object and corresponding Decapsulator Responder.

12.18.4.1.2 Inputs

a) Reference to a Decapsulator Responder, which could be either


2) A triple consisting of an interface (either a Bridge Port or an aggregated IEEE802.3 port within

a Bridge Port), a reference to a Maintenance Domain managed object, and a reference to a

Maintenance Association managed object.

12.18.4.1.3 Outputs


1) Operation rejected because of invalid reference to a Decapsulator Responder managed object;

2) Operation rejected because the referenced Decapsulator Responder managed object alreadyexists; or


12.18.4.2 Read Decapsulator Responder managed object

12.18.4.2.1 Purpose

To retrieve the attributes of a Decapsulator Responder managed object.

12.18.4.2.2 Input

a) Reference to a Decapsulator Responder managed object [12.18.4.1.2, item a)].

12.18.4.2.3 Outputs



2) Operation rejected because the referenced Decapsulator Responder managed object does not

exist; or


b) If the operation is accepted, the following attributes for the Decapsulator Responder should be

returned:

1) Reference to the Decapsulator Responder managed object;

2) MAC address of the SFM Originator (writable);

3) The value of SourceAddressStayFlag (writable);

4) The value of FloodingEnabled flag (writable);

5) The specified duration in seconds, for Decapsulator Responder to remain active once activated

(writable);

6) Activation status;

7) Remaining time left for Decapsulator Responder to be active; and

8) The total number of out-of-sequence SFMs received (29.3.8.7).

8/8/2019 802.1Qaw-2009




12.18.4.3 Write Decapsulator Responder managed object’s attributes

12.18.4.3.1 Purpose

To alter the value of one or more attributes of a Decapsulator Responder managed object when the

corresponding Decapsulator Responder is not active.

12.18.4.3.2 Inputs

a) Reference to a Decapsulator Responder managed object [12.18.4.1.2, item a)];

b) Reference to the attribute whose value is to be changed;

1) Boolean flag, SourceAddressStayFlag, to enforce the DR not to replace the source_address

field of the decapsulated frame with the DR’s own MAC address. Default is false;

2) MAC address of the SFM Originator, which is optional;

3) Boolean FloodingEnabled flag indicating if flooding is allowed (true) or not (false) if the

Egress port cannot be identified by the Filtering Database; and

4) Duration in seconds, for Decapsulator Responder to remain active once activated.

12.18.4.3.3 Outputs




exist;

3) Operation rejected because of invalid attribute reference or invalid value;

4) Operation rejected because the referenced Decapsulator Responder is active; or


12.18.4.4 Delete Decapsulator Responder managed object

12.18.4.4.1 Purpose

To delete a Decapsulator Responder managed object. If the Decapsulator Responder is still active, the

deletion will de-activate the Decapsulator Responder first and then delete the corresponding managed

object.

12.18.4.4.2 Input

a) Reference to a Decapsulator Responder managed object [12.18.4.1.2, item a)].

12.18.4.4.3 Outputs

a) Operation status: this takes one of the following values:



exist; or


12.18.4.5 Activate a Decapsulator Responder

12.18.4.5.1 Purpose

To activate a Decapsulator Responder.

8/8/2019 802.1Qaw-2009




12.18.4.5.2 Input

a) Reference to the Decapsulator Responder managed object [12.18.4.1.2, item a)].

12.18.4.5.3 Outputs

a) Operation status. This takes one of the following values:1) Operation rejected because of invalid reference;


exist;

3) Operation rejected because the referenced Decapsulator Responder has already been activated;

or


12.18.4.6 De-activate a Decapsulator Responder

12.18.4.6.1 Purpose

To de-activate a Decapsulator Responder.

12.18.4.6.2 Input

a) Reference to the Decapsulator Responder managed object [12.18.4.1.2, item a)].

12.18.4.6.3 Outputs


1) Operation rejected because of invalid reference;


exist;

3) Operation rejected because the referenced Decapsulator Responder is not active; or


12.18.5 SFM Originator managed object

The management operations that can be performed on the SFM Originator managed object are as follows:

a) Create SFM Originator managed object (12.18.5.1)

b) Read SFM Originator managed object (12.18.5.2)

c) Delete SFM Originator managed object (12.18.5.3)

d) Write SFM Originator managed object attribute (12.18.5.4)

e) Activate SFM Originator (12.18.5.5)

f) De-activate SFM Originator (12.18.5.6)

12.18.5.1 Create SFM Originator managed object

12.18.5.1.1 Purpose

To create a SFM Originator managed object.

12.18.5.1.2 Inputs

a) Reference to a SFM Originator managed object, which could be either


8/8/2019 802.1Qaw-2009




2) An interface (either a Bridge Port, or an aggregated IEEE802.3 port within a Bridge Port), a

reference to a Maintenance Domain managed object, a reference to a Maintenance Association

managed object, and a value indicating the direction in which the SFM Originator faces on the

interface.

12.18.5.1.3 Outputs



2) Operation rejected because the referenced SFM Originator managed object already exists; or


12.18.5.2 Read SFM Originator managed object

12.18.5.2.1 Purpose

To retrieve attributes of SFM Originator managed object.

12.18.5.2.2 Inputs

a) Reference to a SFM Originator managed object [12.18.5.1.2, item a)].

12.18.5.2.3 Outputs



2) Operation rejected because the referenced SFM Originator managed object does not exist; or


b) If the operation is accepted, following attributes for the SFM Originator should be returned:

1) MAC address of the SFM Originator;

2) MAC address of the corresponding Decapsulator Responder (writable);3) Duration (writable);

4) Activation status: true/false; and

5) The remaining time left for the SFM Originator to remain active.

12.18.5.3 Delete SFM Originator managed object

12.18.5.3.1 Purpose

To delete a SFM Originator managed object, and the corresponding SFM Originator.

12.18.5.3.2 Inputs

a) The reference to a SFM Originator managed object [12.18.5.1.2, item a)].

12.18.5.3.3 Outputs





8/8/2019 802.1Qaw-2009




12.18.5.4 Write SFM Originator managed object’s attribute

12.18.5.4.1 Purpose

To change an attribute of a SFM Originator managed object.

12.18.5.4.2 Inputs

a) Reference to a SFM Originator managed object [12.18.5.1.2, item a)];

b) MAC address of the corresponding Decapsulator Responder; and

c) Duration in seconds, for SFM Originator to stay active once activated.

12.18.5.4.3 Outputs


1) Operation rejected because of invalid reference of SFM Originator managed object or the

attributes;



12.18.5.5 Activate SFM Originator

12.18.5.5.1 Purpose

To activate a SFM Originator.

12.18.5.5.2 Input

a) Reference to the SFM Originator managed object [12.18.5.1.2, item a)].

12.18.5.5.3 Outputs

a) Operation status. This takes one of the following values:1) Operation rejected because of invalid reference;

2) Operation rejected because the referenced SFM Originator managed object does not exist;

3) Operation rejected because the referenced SFM Originator has already been activated; or


12.18.5.6 De-activate SFM Originator

12.18.5.6.1 Purpose

To de-activate a SFM Originator.

12.18.5.6.2 Input

a) Reference to a SFM Originator managed object [12.18.5.1.2, item a)].

12.18.5.6.3 Output



2) Operation rejected because the referenced SFM Originator managed object does not exist;

3) Operation rejected because the referenced SFM Originator is not active; or


8/8/2019 802.1Qaw-2009


8/8/2019 802.1Qaw-2009




15. Support of the MAC Service by Provider Bridged Networks

Insert a new subclause after 15.10 as follows:

15.11 Data driven and data dependent connectivity fault management (DDCFM)

Data driven and data dependent connectivity fault management (DDCFM), described in Clause 29, provides

tools for network operators to detect and isolate data driven and data dependent faults in Virtual Bridged

Local Area Networks.

8/8/2019 802.1Qaw-2009


8/8/2019 802.1Qaw-2009




17. Management Information Base (MIB)

17.2 Structure of the MIB

Add the following row to Table 17-1:

Insert a new subclause 17.2.9 as follows:

17.2.9 Structure of the IEEE8021-DDCFM MIBs

The IEEE8021-DDCFM MIB provides objects to configure and manage the DDCFM capabilities.

Objects in this MIB module are arranged into subtrees. Each subtree is organized as a set of related objects

as follows:

a) Reflection Responder subtree: this subtree contains the objects that are applicable to bridges that

support DDCFM’s RR function.

b) RFM Receiver subtree: this subtree contains the objects that are applicable to bridges or end stations

that support DDCFM’s RFM Receiver function.

c) Decapsulator Responder subtree: this subtree contains the objects that are applicable to bridges that

support DDCFM’s DR function.

d) SFM Originator subtree: this subtree contains the objects that are applicable to bridges or endstations that support DDCFM’s SFM Originator function.

Table 17-14 indicates the structure of the IEEE8021-DDCFM MIB module.

Table 17-1—Structure of the MIB modules

Module SubclauseDefining IEEE

standardReference Notes

IEEE8021-DDCFM MIB 17.7.9 802.1Qaw 29 Initial version of IEEE Std802.1Qaw

Table 17-14—IEEE8021-DDCFM MIB structure and relationship

to this standard

Variable Clause 17 MIB Table/Group Reference

ieee8021DdcfmStackTable DDCFM Stack managedobject (12.18.1)

ieee8021DdcfmStackIfIndex 12.18.1.1.2 a)

ieee8021DdcfmStackRrMdLevel 12.18.1.1.3 b1)

ieee8021DdcfmStackRrDirection

ieee8021DdcfmStackRFMreceiverMdLevel 12.18.1.1.3 b2)

ieee8021DdcfmStackDrMdLevel 12.18.1.1.3 b3)

ieee8021DdcfmStackDrVlanIdOrNone

8/8/2019 802.1Qaw-2009




ieee8021DdcfmStackSFMOriginatorMdLevel 12.18.1.1.3 b4)

ieee8021DdcfmStackSFMOriginatorVlanIdOrNone

ieee8021DdcfmStackSFMOriginatorDirection

ieee8021DdcfmRrTable Reflection Respondermanaged object (12.18.2)

ieee8021DdcfmRr

ieee8021DdcfmRrIfIndex 12.18.2.1.2 a1)

ieee8021DdcfmRrMdIndex 12.18.2.1.2 a2)

ieee8021DdcfmRrDirection 12.18.2.1.2 a3)

ieee8021DdcfmRrPrimaryVlanIdOrNone 12.18.2.2.2 b1)

ieee8021DdcfmRrFilter 12.18.2.2.2 b2)

ieee8021DdcfmRrSamplingInterval 12.18.2.2.2 b3)

ieee8021DdcfmRrTargetAddress 12.18.2.2.2 b4)

ieee8021DdcfmRrContinueFlag 12.18.2.2.2 b5)

ieee8021DdcfmRrDuration 12.18.2.2.2 b7)

ieee8021DdcfmRrDurationInTimeFlag 12.18.2.2.2 b6)

ieee8021DdcfmRrVlanPriorityieee8021DdcfmRrVlanDropEligible

12.18.2.2.2 b9)

ieee8021DdcfmRrFloodingFlag 12.18.2.2.2 b10)

ieee8021DdcfmRrTruncationFlag 12.18.2.2.2 b.11

ReflectionRequest(29.3.1.15)

ieee8021DdcfmRrActivationStatus 12.18.1.2.3 b12)

RRwhile (29.3.1.9) ieee8021DdcfmRrRemainDuration 12.18.2.3.3 b13)

nextRFMtransID(29.3.1.16)

ieee8021DdcfmRrNextRfmTransID 12.18.2.3.3 b14)

ieee8021DdcfmRFMReceiverTable RFM Receiver managedobject (12.18.3)

ieee8021DdcfmRFMReceiver

ieee8021DdcfmRfmReceiverIfIndex

ieee8021DdcfmRfmReceiverMdIndex

12.18.2.1.2 a2)

ieee8021DdcfmDrTable Decapsulator Respondermanaged object (12.18.4)

ieee8021DdcfmDr

ieee8021DdcfmDrIfIndexieee8021DdcfmDrMdIndexieee8021DdcfmDrVlanIdOrNone

12.18.3.1.2 a2)


to this standard (continued )


8/8/2019 802.1Qaw-2009





17.3.9 Relationship of the IEEE8021-DDCFM to other MIB modules

Subclause 17.7.9 defines the DDCFM MIB module that supports 12.18. A system implementing the

DDCFM MIB module in 17.7.9 shall also implement at least the System Group of the SNMPv2-MIB

defined in IETF RFC 3418 and Interfaces Group (the Interfaces MIB module, or IF-MIB) defined in IETF

RFC 2863.


17.4.9 Security considerations of the IEEE8021-DDCFM MIB

There are a number of management objects defined in DDCFM MIB module with a MAX-ACCESS clause

of read-write and/or read-create. Such objects may be considered sensitive or vulnerable in some network

environments. The support for SET operations in a non-secure environment without proper protection can

have a negative effect on network operations. Table 17-15 lists the MIB tables and objects and their

sensitivity/vulnerability.

ieee8021DdcfmDrSourceAddressStayFlag 12.18.4.3.2 b1)

ieee8021DdcfmDrSfmOriginator 12.18.4.3.2 b2)

ieee8021DdcfmDrFloodingFlag 12.18.4.3.2 b3)

DRtime (29.3.8.2) ieee8021DdcfmDrDuration 12.18.4.3.2 b4)

DRactive(29.3.8.4)

ieee8021DdcfmDrActivationStatus 12.18.3.2.3 b6)

DRwhile (29.3.8.1) ieee8021DdcfmDrRemainDuration 12.18.3.2.3 b7)

SFMsequenceEr-rors (29.3.8.7)

ieee8021DdcfmDrSFMsequenceErrors 12.18.4.2.3 b8)

ieee8021DdcfmSoTable SFM Originator managedobject (12.18.5)

ieee8021DdcfmSFMOriginator

ieee8021DdcfmSfmIfIndexieee8021DdcfmSoMdIndexieee8021DdcfmSoVlanIdOrNoneieee8021DdcfmSoDirection

12.18.4.1.2 a2)

ieee8021DdcfmSoDrMacAddress 12.18.5.4.3 b2)

ieee8021DdcfmSoDuration 12.18.5.4.3 b3)

ieee8021DdcfmSoActivationStatus 12.18.4.2.3 b4)

ieee8021DdcfmSoRemainDuration 12.18.4.2.3 b5)


to this standard (continued )


8/8/2019 802.1Qaw-2009




Some of the readable objects in this MIB module (i.e., objects with a MAX-ACCESS other than not-accessible) may be considered sensitive or vulnerable in some network environments. It is thus important to

control even GET and/or NOTIFY access to these objects and possibly to even encrypt the values of these

objects when sending them over the network via SNMP. Table 17-16 lists the MIB tables and objects that are

sensitive to read.

SNMP versions prior to SNMPv3 did not include adequate security. Even if the network itself is secure (for

example by using IPsec), even then, there is no control as to who on the secure network is allowed to access

and GET/SET (read/change/create/delete) the objects in this MIB module. It is RECOMMENDED that

implementers consider the security features as provided by the SNMPv3 framework (see IETF RFC 3410,

section 8), including full support for the SNMPv3 cryptographic mechanisms (for authentication and

privacy).

Further, deployment of SNMP versions prior to SNMPv3 is NOT RECOMMENDED. Instead, it is

RECOMMENDED to deploy SNMPv3 and to enable cryptographic security. It is then a customer/operator

responsibility to ensure that the SNMP entity giving access to an instance of this MIB module is properly

configured to give access to the objects only to those principals (users) that have legitimate rights to indeed

GET or SET (change/create/delete) them.


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

Table or object Reason for sensitivity to security considerations

ieee8021DdcfmRr Once created and activated, ieee8021DdcfmRr can interceptselected data frames traversing through a bridge interface, andsend its copy encapsulated in RFM header to a specific destination

within the maintenance domain. The action can create extra trafficwithin the maintenance domain.

ieee8021DdcfmDr Once created and activated, ieee8021DdcfmDr will decapsulatereceived SFM and send the decapsulated data frame to locationspecified by the data frame’s destination_address. This action

practically injects specific traffic into the network.

ieee8021DdcfmSFMOriginator Once created and activated, ieee8021DdcfmSFMOriginator injectsSFMs into the maintenance domain. However, if the correspondingieee8021DdcfmDr is not activated, the received SFMs aredropped. Therefore, ieee8021DdcfmSFMOriginator is less sensi-tive than the corresponding ieee8021DdcfmDr.

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

Table or object Reason for sensitivity to security considerations

ieee8021DdcfmRFMReceiver Once created, ieee8021DdcfmRFMReceiver can receive theRFM, which encapsulate actual data frame that could be sensi-

tive and need to be protected. It is very important to control theGET operation on this object.

8/8/2019 802.1Qaw-2009




17.7.9 Definitions for the DDCFM MIBs

This subclause defines the DDCFM MIBs.

IEEE8021-DDCFM-MIB DEFINITIONS ::= BEGIN

-- ******************************************************************

-- IEEE802.1Qaw DDCFM MIB-- ******************************************************************IMPORTS

MODULE-IDENTITY,OBJECT-TYPE,Integer32,Unsigned32 FROM SNMPv2-SMI -- [RFC2578]TruthValue, RowStatus,MacAddress FROM SNMPv2-TC -- [RFC2579]MODULE-COMPLIANCE, OBJECT-GROUP FROM SNMPv2-CONF -- [RFC2580]InterfaceIndex FROM IF-MIB -- [RFC2863]VlanIdOrNone FROM Q-BRIDGE-MIB -- [RFC4363]Dot1agCfmMDLevel, Dot1agCfmMpDirection FROM IEEE8021-CFM-MIBieee802dot1mibs FROM IEEE8021-TC-MIB;

ieee8021DdcfmMIB MODULE-IDENTITYLAST-UPDATED "200904060000Z" -- 04/06/2009 00:00GMTORGANIZATION "IEEE 802.1 Working Group"CONTACT-INFO

"WG-URL: http://grouper.ieee.org/groups/802/1/index.htmlWG-EMail: [email protected]: Linda DunbarHuawei Technologies Inc.(USA)1700 Alma Dr., Suite 100Plano, TX 75075USAEmail: [email protected]"

DESCRIPTION"module for managing Data Dependent and Data Driven ConnectivityFault Management"

REVISION "200904060000Z" -- 04/06/2009 00:00GMTDESCRIPTION

"Included in IEEE802.1Qaw D5.0Copyright (c) IEEE"

::= {ieee802dot1mibs 11}

ieee8021MIBObjects OBJECT IDENTIFIER ::= { ieee8021DdcfmMIB 1 }ieee8021DdcfmConformance OBJECT IDENTIFIER ::= { ieee8021DdcfmMIB 2 }

-- ******************************************************************-- Groups in the DDCFM MIB Module-- ******************************************************************

ieee8021DdcfmStack OBJECT IDENTIFIER ::={ieee8021MIBObjects 1}ieee8021DdcfmRr OBJECT IDENTIFIER ::={ieee8021MIBObjects 2}ieee8021DdcfmRFMReceiver OBJECT IDENTIFIER ::={ieee8021MIBObjects 3}ieee8021DdcfmDr OBJECT IDENTIFIER ::={ieee8021MIBObjects 4}ieee8021DdcfmSFMOriginator OBJECT IDENTIFIER ::={ieee8021MIBObjects 5}

-- ******************************************************************-- The DDCFM Stack Table-- ******************************************************************ieee8021DdcfmStackTable OBJECT-TYPE

SYNTAX SEQUENCE OF Ieee8021DdcfmStackEntry

8/8/2019 802.1Qaw-2009




MAX-ACCESS not-accessibleSTATUS currentDESCRIPTION

"The DDCFM Stack MIB object table. This table is for operator toretrieve all the DDCFM entities defined on a specified interface.This table is created by default."

REFERENCE"clauses 12.18.1"

::= { ieee8021DdcfmStack 1 }

ieee8021DdcfmStackEntry OBJECT-TYPESYNTAX Ieee8021DdcfmStackEntryMAX-ACCESS not-accessibleSTATUS currentDESCRIPTION

"The DDCFM Stack Table. "INDEX { ieee8021DdcfmStackIfIndex}::= { ieee8021DdcfmStackTable 1 }

Ieee8021DdcfmStackEntry ::= SEQUENCE {ieee8021DdcfmStackIfIndex InterfaceIndex,ieee8021DdcfmStackRrMdLevel Dot1agCfmMDLevel,ieee8021DdcfmStackRrDirection Dot1agCfmMpDirection,ieee8021DdcfmStackRFMreceiverMdLevel Dot1agCfmMDLevel,ieee8021DdcfmStackDrMdLevel Dot1agCfmMDLevel,ieee8021DdcfmStackDrVlanIdOrNone VlanIdOrNone,ieee8021DdcfmStackSFMOriginatorMdLevel Dot1agCfmMDLevel,ieee8021DdcfmStackSFMOriginatorVlanIdOrNone VlanIdOrNone,ieee8021DdcfmStackSFMOriginatorDirection Dot1agCfmMpDirection}

ieee8021DdcfmStackIfIndex OBJECT-TYPESYNTAX InterfaceIndexMAX-ACCESS not-accessibleSTATUS currentDESCRIPTION

"This object is the interface index of the interface either abridge port, or an aggregated IEEE802.3 port within a Bridge

Port. When the ifIndex value corresponds to the ifIndex of aBridge Port, the value in this column must match the value in theieee8021BridgeBasePortIfIndex column for the bridge port."

REFERENCE"clause 12.18.1.1.2 a.1"

::= { ieee8021DdcfmStackEntry 1 }

ieee8021DdcfmStackRrMdLevel OBJECT-TYPESYNTAX Dot1agCfmMDLevelMAX-ACCESS read-onlySTATUS currentDESCRIPTION

"MD level of the Reflection Responder managed object."REFERENCE

"clause 12.18.1.1.3 b.1"

::= { ieee8021DdcfmStackEntry 2 }

ieee8021DdcfmStackRrDirection OBJECT-TYPESYNTAX Dot1agCfmMpDirectionMAX-ACCESS read-onlySTATUS currentDESCRIPTION

"The direction in which the RR faces."REFERENCE

"clause 12.18.1.1.3 b1"::= { ieee8021DdcfmStackEntry 3 }

8/8/2019 802.1Qaw-2009




ieee8021DdcfmStackRFMreceiverMdLevel OBJECT-TYPESYNTAX Dot1agCfmMDLevelMAX-ACCESS read-onlySTATUS currentDESCRIPTION

"MD level of the RFM Receiver MO configured on the interface."REFERENCE

"clause 12.18.1.1.3 b.2"::= { ieee8021DdcfmStackEntry 4 }

ieee8021DdcfmStackDrMdLevel OBJECT-TYPESYNTAX Dot1agCfmMDLevelMAX-ACCESS read-onlySTATUS currentDESCRIPTION

"MD level of the Deflection Responder managed object."REFERENCE


ieee8021DdcfmStackDrVlanIdOrNone OBJECT-TYPESYNTAX VlanIdOrNoneMAX-ACCESS read-onlySTATUS currentDESCRIPTION

"The MA of the DR configured on the interface."REFERENCE


ieee8021DdcfmStackSFMOriginatorMdLevel OBJECT-TYPESYNTAX Dot1agCfmMDLevelMAX-ACCESS read-onlySTATUS currentDESCRIPTION

"MD level of the SFM Originator MO configured on the interface."REFERENCE


ieee8021DdcfmStackSFMOriginatorVlanIdOrNone OBJECT-TYPESYNTAX VlanIdOrNoneMAX-ACCESS read-onlySTATUS currentDESCRIPTION

"The MA of the SFM Originator configured on the interface."REFERENCE


ieee8021DdcfmStackSFMOriginatorDirection OBJECT-TYPESYNTAX Dot1agCfmMpDirection

MAX-ACCESS read-onlySTATUS currentDESCRIPTION

"The direction of which the SFM Originator is facing."REFERENCE


-- ******************************************************************-- The Reflection Responder Table-- ******************************************************************

8/8/2019 802.1Qaw-2009




ieee8021DdcfmRrTable OBJECT-TYPESYNTAX SEQUENCE OF Ieee8021DdcfmRrEntryMAX-ACCESS not-accessibleSTATUS currentDESCRIPTION

"The Reflection Responder MIB object table. Each row in the tablerepresents a different Reflection Responder. All rows in thistable persist across a system restart, however after such a restartthe value of the ActivationStatus column will be false."


::= { ieee8021DdcfmRr 1 }

ieee8021DdcfmRrEntry OBJECT-TYPESYNTAX Ieee8021DdcfmRrEntryMAX-ACCESS not-accessibleSTATUS currentDESCRIPTION

"The Reflection Responder. Each entry associated with a ReflectionResponder."

INDEX { ieee8021DdcfmRrIfIndex,ieee8021DdcfmRrMdIndex,ieee8021DdcfmRrDirection}

::= { ieee8021DdcfmRrTable 1 }

Ieee8021DdcfmRrEntry ::= SEQUENCE {ieee8021DdcfmRrIfIndex InterfaceIndex,ieee8021DdcfmRrMdIndex Dot1agCfmMDLevel,ieee8021DdcfmRrDirection Dot1agCfmMpDirection,ieee8021DdcfmRrPrimaryVlanIdOrNone VlanIdOrNone,ieee8021DdcfmRrFilter OCTET STRING,ieee8021DdcfmRrSamplingInterval Unsigned32,ieee8021DdcfmRrTargetAddress MacAddress,ieee8021DdcfmRrContinueFlag TruthValue,ieee8021DdcfmRrDuration Unsigned32,ieee8021DdcfmRrDurationInTimeFlag TruthValue,ieee8021DdcfmRrVlanPriority Integer32,

ieee8021DdcfmRrVlanDropEligible TruthValue,ieee8021DdcfmRrFloodingFlag TruthValue,ieee8021DdcfmRrTruncationFlag TruthValue,ieee8021DdcfmRrActivationStatus TruthValue,ieee8021DdcfmRrRemainDuration Unsigned32,ieee8021DdcfmRrNextRfmTransID Unsigned32,ieee8021DdcfmRrRowStatus RowStatus}

ieee8021DdcfmRrIfIndex OBJECT-TYPESYNTAX InterfaceIndexMAX-ACCESS not-accessibleSTATUS currentDESCRIPTION

"This object is the interface index of the interface either a

bridge port, or an aggregated IEEE802.3 port within a BridgePort, on which Reflection Responder is defined.When the ifIndex value corresponds to the ifIndex of aBridge Port, the value in this column must match the value in theieee8021BridgeBasePortIfIndex column for the bridge port."


::= { ieee8021DdcfmRrEntry 1 }

ieee8021DdcfmRrMdIndex OBJECT-TYPESYNTAX Dot1agCfmMDLevel

8/8/2019 802.1Qaw-2009




MAX-ACCESS not-accessibleSTATUS currentDESCRIPTION

"MD level of the Reflection Responder managed object."REFERENCE

"clause 12.18.2.1.2 a.2"::= { ieee8021DdcfmRrEntry 2 }

ieee8021DdcfmRrDirection OBJECT-TYPESYNTAX Dot1agCfmMpDirectionMAX-ACCESS not-accessibleSTATUS currentDESCRIPTION

"The direction in which the RR faces."REFERENCE

"clause 12.18.2.1.2 a.3"::= { ieee8021DdcfmRrEntry 3 }

ieee8021DdcfmRrPrimaryVlanIdOrNone OBJECT-TYPESYNTAX VlanIdOrNoneMAX-ACCESS read-createSTATUS currentDESCRIPTION

"The VID to be used on RFM frames."REFERENCE

"clause 12.18.2.2.2 b.1"DEFVAL { 0 }::= { ieee8021DdcfmRrEntry 4 }

ieee8021DdcfmRrFilter OBJECT-TYPESYNTAX OCTET STRING (SIZE(0..1500))MAX-ACCESS read-createSTATUS currentDESCRIPTION

"A pattern string specifies what data frames are selected to bereflected. Below are the primary Reflection Filters allImplementers should support. Multiple primary filters can becombined together by

&& (and), || (or), or !(negation).1) All;2) VID= vid;3) I-SID = x;4) DA = xx.xx.xx.xx.xx.xx;5) SA = xx.xx.xx.xx.xx.xx;6) EtherType =xx.For the reason that this management object allows a max size of1500, messages carrying this object may be fragmented on somesegments."

REFERENCE"clause 12.18.2.2.2 b.2"


ieee8021DdcfmRrSamplingInterval OBJECT-TYPE

SYNTAX Unsigned32UNITS "miliseconds"MAX-ACCESS read-createSTATUS currentDESCRIPTION

"Indicates a time interval in which only the first frame matchingthe filter conditions is refected."



8/8/2019 802.1Qaw-2009




ieee8021DdcfmRrTargetAddress OBJECT-TYPESYNTAX MacAddressMAX-ACCESS read-createSTATUS currentDESCRIPTION

"The Reflection Target Address, which is a MAC address to which thereflected frames are targeted. Only individual address is allowedfor the Reflection Target Address.If not specified, the source_address of the selected data frame isused for Reflection Target Address."



ieee8021DdcfmRrContinueFlag OBJECT-TYPESYNTAX TruthValueMAX-ACCESS read-createSTATUS currentDESCRIPTION

"True indicates that the selected data frames are to be continuedtowards the DA specified in the frame header.False indicates that the selected data frames are terminated."


DEFVAL { true }::= { ieee8021DdcfmRrEntry 8 }

ieee8021DdcfmRrDuration OBJECT-TYPESYNTAX Unsigned32MAX-ACCESS read-createSTATUS currentDESCRIPTION

"Duration of time in the unit of seconds or the numberof frames to be reflected, for Reflection Responder toremain active after activation; Minimum 2 octets (65536seconds) are needed for the duration of time;"



ieee8021DdcfmRrDurationInTimeFlag OBJECT-TYPESYNTAX TruthValueMAX-ACCESS read-createSTATUS currentDESCRIPTION

"True indicates that duration is in seconds;False indicates that duration is by the total number of frames

reflected."REFERENCE

"clause 12.18.2.2.2 b.6"DEFVAL { true }::= { ieee8021DdcfmRrEntry 10 }

ieee8021DdcfmRrVlanPriority OBJECT-TYPESYNTAX Integer32(0..7)MAX-ACCESS read-createSTATUS currentDESCRIPTION

"Priority, 3 bit value to be used in the VLAN tag, to be used in thetransmitted encapsulated frames. The default value is the highestpriority."


DEFVAL { 7 }

8/8/2019 802.1Qaw-2009





ieee8021DdcfmRrVlanDropEligible OBJECT-TYPESYNTAX TruthValueMAX-ACCESS read-createSTATUS currentDESCRIPTION

"It indicates that drop_eligible bit value to be used inthe VLAN tag which to be used in the transmitted encapsulatedframes is set as True or False accordingly."


DEFVAL { false }::= { ieee8021DdcfmRrEntry 12 }

ieee8021DdcfmRrFloodingFlag OBJECT-TYPESYNTAX TruthValueMAX-ACCESS read-createSTATUS currentDESCRIPTION

"True indicates that flooding is allowed if Egress port can't beidentified for RFM by the Filtering Database, False otherwise."



ieee8021DdcfmRrTruncationFlag OBJECT-TYPESYNTAX TruthValueMAX-ACCESS read-createSTATUS currentDESCRIPTION

"True indicates that the received data frame will be truncated tokeep the contructed RFM size not exceeding the egress port’s

Maximum Service Data Unit Size, False otherwise."REFERENCE

"clause 12.18.2.2.2 b.11"


ieee8021DdcfmRrActivationStatus OBJECT-TYPESYNTAX TruthValueMAX-ACCESS read-onlySTATUS currentDESCRIPTION

"True When receiving a request to activate a Reflection Responder,False When receiving a request to stop Reflection Responder orits timer expires."


DEFVAL { false }::= { ieee8021DdcfmRrEntry 15 }

ieee8021DdcfmRrRemainDuration OBJECT-TYPESYNTAX Unsigned32UNITS "seconds"MAX-ACCESS read-onlySTATUS currentDESCRIPTION

"The value indicates the time, in the unit of seconds, or countleft for Reflection Responder to be active."


8/8/2019 802.1Qaw-2009





ieee8021DdcfmRrNextRfmTransID OBJECT-TYPESYNTAX Unsigned32MAX-ACCESS read-onlySTATUS currentDESCRIPTION

"It indicates the value of RFM Transaction Identifier field of thenext RFM transmitted. It is incremented by 1 with eachtransmission of RFM."



ieee8021DdcfmRrRowStatus OBJECT-TYPESYNTAX RowStatusMAX-ACCESS read-createSTATUS currentDESCRIPTION

"The status of the row.The writable columns in a row can not be changed if the row isactive."


-- ******************************************************************-- The RFM Receiver Table-- ******************************************************************

ieee8021DdcfmRFMReceiverTable OBJECT-TYPESYNTAX SEQUENCE OF Ieee8021DdcfmRFMReceiverEntryMAX-ACCESS not-accessibleSTATUS currentDESCRIPTION

"The RFM Receiver MIB object table. Each row in the tablerepresents a different RFM Receiver. All rows associated with this table persist across system restart."


::= { ieee8021DdcfmRFMReceiver 1 }

ieee8021DdcfmRFMReceiverEntry OBJECT-TYPESYNTAX Ieee8021DdcfmRFMReceiverEntryMAX-ACCESS not-accessibleSTATUS currentDESCRIPTION

"The DDCFM RFM Receiver. Each entry associated with a DDCFM RFMReceiver that reference to a MP."

INDEX { ieee8021DdcfmRfmReceiverIfIndex,ieee8021DdcfmRfmReceiverMdIndex}::= { ieee8021DdcfmRFMReceiverTable 1 }

Ieee8021DdcfmRFMReceiverEntry ::= SEQUENCE {ieee8021DdcfmRfmReceiverIfIndex InterfaceIndex,

ieee8021DdcfmRfmReceiverMdIndex Dot1agCfmMDLevel,ieee8021DdcfmRFMRowStatus RowStatus

}

ieee8021DdcfmRfmReceiverIfIndex OBJECT-TYPESYNTAX InterfaceIndexMAX-ACCESS not-accessibleSTATUS currentDESCRIPTION

"The interface index of the interface either abridge port, or an aggregated IEEE802.3 port within a Bridge

8/8/2019 802.1Qaw-2009




Port, on which the RFM Receiver is created.When the ifIndex value corresponds to the ifIndex of aBridge Port, the value in this column must match the value in theieee8021BridgeBasePortIfIndex column for the bridge port."

REFERENCE"clause 12.18.3.1.2 a.2 "

::= { ieee8021DdcfmRFMReceiverEntry 1 }

ieee8021DdcfmRfmReceiverMdIndex OBJECT-TYPESYNTAX Dot1agCfmMDLevelMAX-ACCESS not-accessibleSTATUS currentDESCRIPTION

"MD level of the RFM Receiver managed object."REFERENCE

"clause 12.18.3.1.2 a.2"::= { ieee8021DdcfmRFMReceiverEntry 2 }

ieee8021DdcfmRFMRowStatus OBJECT-TYPESYNTAX RowStatusMAX-ACCESS read-createSTATUS currentDESCRIPTION


::= { ieee8021DdcfmRFMReceiverEntry 3 }

-- ******************************************************************-- The Decapsulator Responder Table-- ******************************************************************ieee8021DdcfmDrTable OBJECT-TYPE

SYNTAX SEQUENCE OF Ieee8021DdcfmDrEntryMAX-ACCESS not-accessibleSTATUS currentDESCRIPTION

"The DDCFM Decapsulator Responder MIB object table. Each row in thetable represents a different DDCFM Decapsulator Responder. All rows

in this table persist across a system restart; however after sucha restart, the value of the ActivationStatus column will be false."


::= { ieee8021DdcfmDr 1 }

ieee8021DdcfmDrEntry OBJECT-TYPESYNTAX Ieee8021DdcfmDrEntryMAX-ACCESS not-accessibleSTATUS currentDESCRIPTION

"The DDCFM Decapsulator Responder. Each entry associated with aDDCFM RFM Receiver which reference to a MP."

INDEX { ieee8021DdcfmDrIfIndex,ieee8021DdcfmDrMdIndex,

ieee8021DdcfmDrVlanIdOrNone }::= { ieee8021DdcfmDrTable 1 }

Ieee8021DdcfmDrEntry ::= SEQUENCE {ieee8021DdcfmDrIfIndex InterfaceIndex,ieee8021DdcfmDrMdIndex Dot1agCfmMDLevel,ieee8021DdcfmDrVlanIdOrNone VlanIdOrNone,ieee8021DdcfmDrSfmOriginator MacAddress,ieee8021DdcfmDrSourceAddressStayFlag TruthValue,ieee8021DdcfmDrFloodingFlag TruthValue,ieee8021DdcfmDrDuration Unsigned32,

8/8/2019 802.1Qaw-2009




ieee8021DdcfmDrActivationStatus TruthValue,ieee8021DdcfmDrRemainDuration Unsigned32,ieee8021DdcfmDrSFMsequenceErrors Unsigned32,ieee8021DdcfmDrRowStatus RowStatus}

ieee8021DdcfmDrIfIndex OBJECT-TYPESYNTAX InterfaceIndexMAX-ACCESS not-accessibleSTATUS currentDESCRIPTION

"The interface index of the interface either a BridgePort, or an aggregated IEEE802.3 port within a BridgePort, on which the Decapsulator Responder is created.When the ifIndex value corresponds to the ifIndex of aBridge Port, the value in this column must match the value in theieee8021BridgeBasePortIfIndex column for the bridge port."

REFERENCE"clause 12.18.4.1.2 a.2 "

::= { ieee8021DdcfmDrEntry 1 }

ieee8021DdcfmDrMdIndex OBJECT-TYPESYNTAX Dot1agCfmMDLevelMAX-ACCESS not-accessibleSTATUS currentDESCRIPTION

"MD level of the Decapsulator Responder managed object."REFERENCE

"clause 12.18.4.1.2 a.2"::= { ieee8021DdcfmDrEntry 2 }

ieee8021DdcfmDrVlanIdOrNone OBJECT-TYPESYNTAX VlanIdOrNoneMAX-ACCESS not-accessibleSTATUS currentDESCRIPTION

"An integer indicating the VID expected from the Send Frame Messageframes."



ieee8021DdcfmDrSfmOriginator OBJECT-TYPESYNTAX MacAddressMAX-ACCESS read-createSTATUS currentDESCRIPTION

"MAC address reference to the corresponding Send Frame MessageOriginator."



ieee8021DdcfmDrSourceAddressStayFlag OBJECT-TYPESYNTAX TruthValueMAX-ACCESS read-createSTATUS currentDESCRIPTION

"True indicates that Decapsulator Responder does not replace thesource_address field of the decapsulated frame with theDecapsulator Responder's own MAC address, False otherwise."


DEFVAL { true }

8/8/2019 802.1Qaw-2009





ieee8021DdcfmDrFloodingFlag OBJECT-TYPESYNTAX TruthValueMAX-ACCESS read-createSTATUS currentDESCRIPTION

"True indicates that broadcast is allowed if Egress port can't beidentified by the Filtering Database, False otherwise."


DEFVAL { true }::= { ieee8021DdcfmDrEntry 6 }

ieee8021DdcfmDrDuration OBJECT-TYPESYNTAX Unsigned32UNITS "seconds"MAX-ACCESS read-createSTATUS currentDESCRIPTION

"The time that the Decapsulator Responder can stay active afterits activation in the unit of seconds."



ieee8021DdcfmDrActivationStatus OBJECT-TYPESYNTAX TruthValueMAX-ACCESS read-onlySTATUS currentDESCRIPTION

"True When receiving a request to activate a DecapsulatorResponder, false When receiving a request to stop the DecapsulatorResponder or its timer expires."


DEFVAL { false }::= { ieee8021DdcfmDrEntry 8 }

ieee8021DdcfmDrRemainDuration OBJECT-TYPESYNTAX Unsigned32UNITS "seconds"MAX-ACCESS read-onlySTATUS currentDESCRIPTION

"The value indicates the time left for Decapsulator Responder keepactive. Its granularity is in seconds."



ieee8021DdcfmDrSFMsequenceErrors OBJECT-TYPESYNTAX Unsigned32

UNITS "integer"MAX-ACCESS read-onlySTATUS currentDESCRIPTION

"The value indicates the total number of out-of-sequence SFMs."REFERENCE

"clause 12.18.4.2.3 b.8"::= { ieee8021DdcfmDrEntry 10 }

ieee8021DdcfmDrRowStatus OBJECT-TYPESYNTAX RowStatus

8/8/2019 802.1Qaw-2009




MAX-ACCESS read-createSTATUS currentDESCRIPTION



-- ******************************************************************-- The SFM Originator Table-- ******************************************************************ieee8021DdcfmSoTable OBJECT-TYPE

SYNTAX SEQUENCE OF Ieee8021DdcfmSoEntryMAX-ACCESS not-accessibleSTATUS currentDESCRIPTION

"The DDCFM Send Frame Message Originator MIB object table. Each rowin the table represents a different DDCFM Send Frame MessageOriginator. All rows in this table persist across a system restart;however after such a restart, the value of the ActivationStatuscolumn will be false."


::= { ieee8021DdcfmSFMOriginator 1 }

ieee8021DdcfmSoEntry OBJECT-TYPESYNTAX Ieee8021DdcfmSoEntryMAX-ACCESS not-accessibleSTATUS currentDESCRIPTION

"Each entry associated with a Send Frame Message Originator."INDEX { ieee8021DdcfmSfmIfIndex,

ieee8021DdcfmSoMdIndex,ieee8021DdcfmSoVlanIdOrNone,ieee8021DdcfmSoDirection}

::= { ieee8021DdcfmSoTable 1 }

Ieee8021DdcfmSoEntry ::= SEQUENCE {

ieee8021DdcfmSfmIfIndex InterfaceIndex,ieee8021DdcfmSoMdIndex Dot1agCfmMDLevel,ieee8021DdcfmSoVlanIdOrNone VlanIdOrNone,ieee8021DdcfmSoDirection Dot1agCfmMpDirection,ieee8021DdcfmSoDrMacAddress MacAddress,ieee8021DdcfmSoDuration Unsigned32,ieee8021DdcfmSoActivationStatus TruthValue,ieee8021DdcfmSoRemainDuration Unsigned32,ieee8021DdcfmSoRowStatus RowStatus}

ieee8021DdcfmSfmIfIndex OBJECT-TYPESYNTAX InterfaceIndexMAX-ACCESS not-accessibleSTATUS current

DESCRIPTION"The interface index of the interface either a bridgeport, or an aggregated IEEE802.3 port within a bridgeport, on which Send Frame Message Originator is created.When the ifIndex value corresponds to the ifIndex of aBridge Port, the value in this column must match the value in theieee8021BridgeBasePortIfIndex column for the bridge port."


::= { ieee8021DdcfmSoEntry 1 }

8/8/2019 802.1Qaw-2009




ieee8021DdcfmSoMdIndex OBJECT-TYPESYNTAX Dot1agCfmMDLevelMAX-ACCESS not-accessibleSTATUS currentDESCRIPTION

"MD level of the Send Frame Message Originator managed object."REFERENCE

"clause 12.18.5.1.2 a.2"::= { ieee8021DdcfmSoEntry 2 }

ieee8021DdcfmSoVlanIdOrNone OBJECT-TYPESYNTAX VlanIdOrNoneMAX-ACCESS not-accessibleSTATUS currentDESCRIPTION

"An integer indicating the VID to be used on Send Frame Messageframes."



ieee8021DdcfmSoDirection OBJECT-TYPESYNTAX Dot1agCfmMpDirectionMAX-ACCESS not-accessibleSTATUS currentDESCRIPTION

"The direction in which the SFM Originator faces."REFERENCE

"clause 12.18.5.1.2 a.2"::= { ieee8021DdcfmSoEntry 4 }

ieee8021DdcfmSoDrMacAddress OBJECT-TYPESYNTAX MacAddressMAX-ACCESS read-createSTATUS currentDESCRIPTION

"MAC Address of the corresponding Decapsulator Responder."REFERENCE

"clause 12.18.5.4.2 b"::= { ieee8021DdcfmSoEntry 5 }

ieee8021DdcfmSoDuration OBJECT-TYPESYNTAX Unsigned32UNITS "seconds"MAX-ACCESS read-createSTATUS currentDESCRIPTION

"Duration, in the unit of seconds, of Send Frame Message Originatorstaying active once activated."

REFERENCE"clause 12.18.5.4.2 c"


ieee8021DdcfmSoActivationStatus OBJECT-TYPESYNTAX TruthValueMAX-ACCESS read-onlySTATUS currentDESCRIPTION

"True When receiving a request to activate a Send Frame MessageOriginator, false When receiving a request to stop the Send FrameMessage Originator or its timer expires."


DEFVAL { false }

8/8/2019 802.1Qaw-2009





ieee8021DdcfmSoRemainDuration OBJECT-TYPESYNTAX Unsigned32UNITS "seconds"MAX-ACCESS read-onlySTATUS currentDESCRIPTION

"The value indicates the time left for Send Frame MessageOriginator keep active. Its granularity is in seconds."



ieee8021DdcfmSoRowStatus OBJECT-TYPESYNTAX RowStatusMAX-ACCESS read-createSTATUS currentDESCRIPTION



-- ******************************************************************-- IEEE802.1Qaw MIB Module - Conformance Information-- ******************************************************************ieee8021DdcfmCompliances OBJECT IDENTIFIER ::= { ieee8021DdcfmConformance 1 }ieee8021DdcfmGroups OBJECT IDENTIFIER ::= { ieee8021DdcfmConformance 2 }

-- ******************************************************************-- Units of conformance-- ******************************************************************ieee8021DdcfmStackGroup OBJECT-GROUP

OBJECTS {ieee8021DdcfmStackRrMdLevel,ieee8021DdcfmStackRrDirection,

ieee8021DdcfmStackRFMreceiverMdLevel,ieee8021DdcfmStackDrMdLevel,ieee8021DdcfmStackDrVlanIdOrNone,ieee8021DdcfmStackSFMOriginatorMdLevel,ieee8021DdcfmStackSFMOriginatorVlanIdOrNone,ieee8021DdcfmStackSFMOriginatorDirection}

STATUS currentDESCRIPTION

"Objects for the DDCFM Stack group."::= { ieee8021DdcfmGroups 1 }

ieee8021DdcfmRrGroup OBJECT-GROUPOBJECTS {

ieee8021DdcfmRrPrimaryVlanIdOrNone,

ieee8021DdcfmRrFilter,ieee8021DdcfmRrSamplingInterval,ieee8021DdcfmRrTargetAddress,ieee8021DdcfmRrContinueFlag,ieee8021DdcfmRrDuration,ieee8021DdcfmRrDurationInTimeFlag,ieee8021DdcfmRrVlanPriority,ieee8021DdcfmRrVlanDropEligible,ieee8021DdcfmRrFloodingFlag,ieee8021DdcfmRrTruncationFlag,ieee8021DdcfmRrActivationStatus,

8/8/2019 802.1Qaw-2009




ieee8021DdcfmRrRemainDuration,ieee8021DdcfmRrNextRfmTransID,ieee8021DdcfmRrRowStatus}


"Objects for the Reflection Responder group."::= { ieee8021DdcfmGroups 2 }

ieee8021DdcfmRFMReceiverGroup OBJECT-GROUPOBJECTS {

ieee8021DdcfmRFMRowStatus}


"Objects for the RFM Receiver group."::= { ieee8021DdcfmGroups 3 }

ieee8021DdcfmDrGroup OBJECT-GROUPOBJECTS {

ieee8021DdcfmDrSourceAddressStayFlag,ieee8021DdcfmDrSfmOriginator,ieee8021DdcfmDrFloodingFlag,ieee8021DdcfmDrDuration,ieee8021DdcfmDrActivationStatus,ieee8021DdcfmDrRemainDuration,ieee8021DdcfmDrSFMsequenceErrors,ieee8021DdcfmDrRowStatus}


"Objects for the Decapsulator Responder group."::= { ieee8021DdcfmGroups 4 }

ieee8021DdcfmSoGroup OBJECT-GROUPOBJECTS {

ieee8021DdcfmSoDrMacAddress,ieee8021DdcfmSoDuration,

ieee8021DdcfmSoActivationStatus,ieee8021DdcfmSoRemainDuration,ieee8021DdcfmSoRowStatus}


"Objects for the Send Frame Message Originator group."::= { ieee8021DdcfmGroups 5 }

--*****************************************************************-- MIB Module Compliance statements--*****************************************************************ieee8021DdcfmCompliance MODULE-COMPLIANCE

STATUS current

DESCRIPTION"The compliance statement for support of the DDCFM MIB module."

MODULEMANDATORY-GROUPS {

ieee8021DdcfmStackGroup,ieee8021DdcfmRrGroup,ieee8021DdcfmRFMReceiverGroup,ieee8021DdcfmDrGroup,ieee8021DdcfmSoGroup}

8/8/2019 802.1Qaw-2009




OBJECT ieee8021DdcfmRrRowStatusSYNTAX RowStatus { active(1), notInService(2) }WRITE-SYNTAX RowStatus { notInService(2), createAndGo(4),

destroy(6) }DESCRIPTION "Support for createAndWait is not required."

OBJECT ieee8021DdcfmRFMRowStatusSYNTAX RowStatus { active(1), notInService(2) }

WRITE-SYNTAX RowStatus { notInService(2), createAndGo(4),destroy(6) }

DESCRIPTION "Support for createAndWait is not required."

OBJECT ieee8021DdcfmDrRowStatusSYNTAX RowStatus { active(1), notInService(2) }WRITE-SYNTAX RowStatus { notInService(2), createAndGo(4),


OBJECT ieee8021DdcfmSoRowStatusSYNTAX RowStatus { active(1), notInService(2) }WRITE-SYNTAX RowStatus { notInService(2), createAndGo(4),


::= { ieee8021DdcfmCompliances 1 }

END

8/8/2019 802.1Qaw-2009




19. CFM Entity operation

19.2.2 MEP Functions

Insert the following list items after the first sublist j) in 19.2.2 . Renumber subsequent list items as

necessary:

k) May decapsulate and transmit the payload of received Send Frame Messages (SFMs) (29.2.6);l) May pass the received RFMs to RFM-Receiver (29.2.4);

19.2.3 MEP Architecture

Replace Figure 19-2 with the following:

8/8/2019 802.1Qaw-2009




F r a

m e M D L e v e l n o t p r e s e n t

Active Level Demultiplexer

Figure 19-2—Maintenance association End Point (MEP)

MEP Continuity Check Receiver

MP Loopback Responder

MEP Loopback Initiator

MEP LinkTrace Initiator

MEP CCM Database

Passive SAP — ( ) — (E)ISS

— ( ) — (E)ISS Active SAP

Active Type Demultiplexer

F r a

m e M D

L e v e l > m d L e v e l

F r a

m e M D L e v e l < m d L e v e l

A c t i v eM ul t i pl ex er

Passive Multiplexer

F r

am eT y p e! = C F M

F r am eMD

L ev el > m d L ev el

F r am eMD

L ev el ==m d L ev el

Type ==CFM

Type==

CFM

LBM

LTR

Passive Type Demultiplexer

LBR

LMI

LBR

LTM*

LBM

CCM

MEP symbol:

EqualOpCodeDemulti-plexer

Maintenance Association

MEP Fault Notification Generator

MAdefectindication

Passive LevelDemultiplexer

LowOpCode De-multiplexer

CCM

other

other

CCM

(E)ISS — ( ) — Linktrace SAP

Linktrace Responder

LTM

(E)ISS — ( ) — LTI SAP†

LTM LTRLTR

MD Level ==mdLevel

F r am eMD

L ev el < m d L ev el

F r am eMD

L ev el n o t pr e s en t

* This path present only in Down MEP† This path present only in Up MEP

MIP CCM Database

Decapsulator Responder SFM

F r a m

e T y p e ! = C F M

MEPContinuity Check Initiator

RFM Receiver RFMLOM SAP (

)

8/8/2019 802.1Qaw-2009




Insert the following entries to Table 19-1:

Insert the following new subclauses after 19.2.16:

19.2.17 MEP Decapsulator Responder

The MEP Decapsulator Responder is an optional component entity within an MEP shim required only by

DDCFM. Its position relative to other MP component entities is shown in Figure 19-2. When the

destination_address of the Send Frame Message (SFM) matches with the MEP’s MAC address, the MEP

Decapsulator Responder (29.2.6) will decapsulate the SFM, change the source_address field of the

decapsulated data frame if it is required, and send the frame to the LOM SAP of selected port(s) (29.3.9.1).

19.2.18 MEP RFM Receiver

The MEP RFM Receiver is an optional component entity within a MEP shim required only by DDCFM. It is

placed next to the OpCode Demultiplexer functions receiving RFM frames. When the destination_address

of the Reflected Frame Message (RFM) matches with the MPs MAC address, the MEP RFM Receiver will

pass the received RFM to the corresponding, non-standardized RFM Analyzer.

19.3.2 MHF functions

Insert the following bullet items after first sublist d) of 19.3.2 and renumber subsequent list items as

necessary:

e) May decapsulate and transmit the payload of the received Send Frame Message (29.4.3)

f) May pass the received Reflected Frame Message (29.4.2).

19.3.3 MHF architecture

Replace Figure 19-3 with the following:

Table 19-1—Actions taken by MP OpCode Demultiplexers

OpCodeMEP Equal OpCod

Demultiplexer

MEP Low OpCode

Demultiplexer

MHF OpCode Demultiplexer

SFM Sets SFMreceived (29.3.8.5)and SFMPDU (29.3.8.3)

Discards PDU Sets SFMreceived (29.3.8.5) andSFMPDU (29.3.8.3). Transfers theSFM to Passive MHF Multiplexer

RFM Sets RFMreceived (29.3.6.1)and RFMPDU (29.3.6.2)

Discards PDU Sets RFMreceived (29.3.6.1) andRFMPDU (29.3.6.2). Transfers theRFM to Passive MHF Multiplexer

8/8/2019 802.1Qaw-2009




Insert the following new subclauses after 19.3.11:

19.3.12 MHF Decapsulator Responder

The MHF Decapsulator Responder is identical to the MEP Decapsulator Responder described in 19.2.17.

19.3.13 MHF RFM Receiver

The MHF RFM Receiver is identical to the MEP RFM Receiver described in 19.2.18.

Data frame

A c t i v eMHF M ul

t i pl ex er

MHF Level Demultiplexer

Figure 19-3—MIP Half Function

Passive SAP — ( ) — (E)ISS


MHF Type Demultiplexer

Frame Type == CFM

Passive MHF Multiplexer

CCM

LBR

LTR

MHF symbol:

F r a m e M D


Frame MD Level == mdLevel

LBM

MIP CCM Database

LTM

F r a m e M D

L e v e l < m d L e v e l

other Linktrace — ( ) — SAP (ISS)

Linktrace Responder

F r a m e M D

L e v e l n o t p r e s e n t

OpCode De-multiplexer

F r a m e T y p e ! = C F MMHF Continuity Check Receiver

RFM Receiver

MHF Loopback Responder

Decapsulator Responder SFM

RFM

LOM SAP ( )

8/8/2019 802.1Qaw-2009




20. Connectivity Fault Management protocols

Change Clause 20 as follows and renumber subsequent list items as needed:

Maintenance association End Points (MEPs) and Maintenance association Intermediate Point (MIPs) can

participate in the following CFM protocols:

a) Continuity Check protocol (20.1);

b) Loopback protocol (20.2); and

c) Linktrace protocol (20.3); and

d) DDCFM protocol (29.3);

8/8/2019 802.1Qaw-2009


8/8/2019 802.1Qaw-2009




21. Encoding of CFM Protocol Data Units

Change bullet d) as follows:

d) Formats of the Continuity Check Message (CCM, 21.6), the Loopback Message and Loopback

Reply (LBM and LBR, 21.7), the Linktrace Message (LTM, 21.8), and Linktrace Reply (LTR, 21.9),

Send Frame Message (SFM, 29.4.3), and the Reflected Frame Message (RFM, 29.4.2).

21.4.3 OpCode

Change Table 21-4 as follows:

21.5.1.1 Type

Change Table 21-6 as follows:

Table 21-4—OpCode Field range assignments

CFM PDU or organization OpCode range

Reserved for IEEE802.1 0

Continuity Check Message (CCM) 1

Loopback Reply (LBR) 2

Loopback Message (LBM) 3

Linktrace Reply (LTR) 4

Linktrace Message (LTM) 5

Reflected Frame Message (RFM) 6

Send Frame Message (SFM) 7

Reserved for IEEE802.1 68–31

Defined by ITU-T Y.1731 32–63


Table 21-6—Type Field values

TLV or organization Type field

End TLV 0

Sender ID TLV 1

Port Status TLV 2

Data TLV 3

Interface Status TLV 4

Reply Ingress TLV 5

Reply Egress TLV 6

8/8/2019 802.1Qaw-2009




21.5.6 Data TLV

Change the first paragraph as follows:

Type = 3. Zero or more octets of arbitrary data. Serves several purposes, including reflected data frame in

RFM, to be decapsulated data in SFM, the transmission of different frame sizes to test Maximum Service

Data Unit Size capabilities, and the testing for data-specific error dependencies. The Data TLV may be

included in the LBM, the LBR, the RFM, and the SFM, but not in any other CFM PDU.

LTM Egress Identifier TLV 7

LTR Egress Identifier TLV 8

Truncated Data TLV (29.3.3.2) 9

Data Part 1 TLV (29.3.3.2) 10

Data Part 2 TLV (29.3.3.2) 11


Organization-Specific TLV 31

Defined by ITU-T Y.1731 32–63


Table 21-6—Type Field values (Continued )

TLV or organization Type field

8/8/2019 802.1Qaw-2009




Insert a new clause as follows:

29. DDCFM operations and protocols

29.1 Principles of DDCFM operation

Data driven and data dependent connectivity fault management (DDCFM) comprises tools to facilitate the

diagnosis and isolation of data driven and data dependent faults in Virtual Bridged Local Area Networks.

This clause describes the functions of DDCFM and how they can be operated and managed. DDCFM is an

extension to Connectivity Fault Management specified by Clause 18 through Clause 22. As in the case of

CFM, DDCFM capabilities can be used in networks operated by multiple independent organizations, each

with restricted management access to others’ equipment.

29.1.1 Data driven and data dependent faults (DDF)

There are two broad types of faults in Virtual Bridged Local Area Networks that affect only certain frames

or sequences of frames. Simple data dependent faults are those that result in the repetitive loss or

misdirection of each of those frames, independently of any other frames, and are usually the result of simple

misconfiguration or of a failure to appreciate the consequences of a configuration option (installing protocol

specific filters, for example). Data driven faults are more complex: the presence (or absence) of some data

frames causes or contributes to the loss of other frames. While the services supported by Virtual Bridged

Local Area Networks are conceptually data independent, the use of data driven techniques enables enhanced

service delivery. To give three examples: multicast frame filtering and consequent bandwidth saving is

facilitated by Internet Group Membership Protocol (IGMP) snooping; stateful firewalls are used to protect

users connected to managed services; and efficient allocation of frames to the individual links of an

aggregation (IEEE 802.1AX Link Aggregation) is often based on spotting conversations by looking at frame

data.

29.1.2 Basic principle to diagnose and isolate DDFs

The basic principle to diagnose DDFs is to isolate them to a small enough network segment, such as a

Bridge Port, a member port of LAG within a Bridge Port, or a LAN segment. Once DDFs are isolated,

understanding the cause of the fault at this location becomes much easier.

The basic procedure to achieve isolation of a DDF is to divide the network into segments and determine

whether certain data frames can traverse through each segment as expected. When a network segment is

identified as faulty, the segment is further divided into smaller segments until a bridge, a Bridge Port, or a

member port of LAG within a Bridge Port is identified as not passing data frames as expected.

A DDF may not be apparent in the absence of live traffic (that is, when test data are used). DDCFM is

designed to carry out the diagnosis while live traffic is being exchanged.

DDCFM facilitates diagnosis and consequent isolation of DDFs with the following two techniques: forward

path test (FPT) and return path test (RPT).

8/8/2019 802.1Qaw-2009




29.1.2.1 Forward path test

The goal of forward path test (FPT), as depicted in Figure 29-1, is to determine whether specified data

frames (frames associated with a service instance, or data frames with certain destination addresses or

VLAN, etc.) can reach a particular location (which could be a Bridge Port, or a member port of LAG within

a Bridge Port) without error. FPT’s Reflection Responder (29.2.2) reflects the identified data frames (e.g., a

service instance or selected data frames) to a specific target location, which could be an end station, a bridge,or a test device. The data frames to be reflected can also be continued to their original destination(s). This

option, called the Continue option throughout this standard, is to support testing of a data stream in a manner

transparent to the application sourcing or sinking that data stream.

FPT can be configured on ports where no MPs exist. However, when they are implemented within MPs or

configured on ports with MPs, better fault isolation can be achieved. For example, if the target location does

not receive the expected reflected data frames in the specified time span, it can send a LBM (21.7) to verify

the connectivity between the Target location and the MP on which the Reflection Responder (29.2.2) is

configured. For a network that supports MEPs but not MIPs, FPT can be used to diagnose segment

connectivity by configuring a Reflection Responder on an intermediate node to encapsulate the received

CCM in RFM format (29.4.2) and forward them to a target location.

The receiver at the target location records the reflected frames for examination by the operator and may also

transfer the reflected frames to an analysis function. Some examples of target location analyzers are as

follows: comparing the reflected frames with the original ones to verify if there are any errors, running a

proxy application at the target location to simulate the handshakes as if those packets actually reach their

original destinations, etc.

As in CFM (Clause 18 through Clause 22), a network operator can only set or activate FPT’s Reflection

Responder within its own maintenance domain. At the customer’s request, a network provider may use

DDCFM to verify whether DDFs occur within its domain. FPT’s Reflection Responder (29.2.2) can only be

created or activated by a network provider’s own Network Management System via secure interface.Therefore, customers or other operators cannot set a FPT Reflection Responder (29.2.2) in a maintenance

domain that does not belong to them.

In order for intermediate bridges and/or a target location to distinguish the reflected data frames from other

traffic, each reflected frame is encapsulated with an RFM header. The RFM header added to the reflected

data frame carries the same Maintenance Domain level associated with the Reflection Responder, so that the

reflected data frames, each encapsulated with a proper RFM header, are contained within the same

Maintenance Domain. The target location has to be in the same maintenance domain to receive the RFMs.

AD a t a f r a m e

s o u r c e

T a r g e t

BD a t a f ra m e

des t i na t i on

R e f l e c t io n R e s p o n d e r

T r a f f i c c o n t i n u e t o t h e i r

d e s t i n a t i o n ( s )

R F M

T a r g e t l o c a t io n c o u l d b e t h e s o u r c e o f

d a t a f r a m e s , o r s t a ti o n / b ri d g e c a p a b l e o f

a n a l y z in g t h e r e f le c t e d d a t a f r a m e s

Figure 29-1—Forward path test (FPT)

8/8/2019 802.1Qaw-2009




Depending on the conditions specified for selecting data frames to be reflected, some conditions can cause

large amount of data frames to be reflected. If there are multiple locations within a network reflecting a large

number of data frames simultaneously, excessive traffic could be added to some segments of the network,

which may impact network performance. To avoid excessive traffic being added to the network by a

Reflection Responder, this standard recommends only one Reflection Responder be activated at a time

within one maintenance domain.

FPT consists of Reflection Responder configuration, the action to reflect identified data frames, and the

analysis of the reflected data frames. The last step, i.e., analysis of the reflected data frames, is beyond the

scope of this standard.

29.1.2.2 Return path test

The return path test (RPT) is to 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 destination_address associated

with each of the frames under test. The RPT is achieved by an originating station encapsulating each frame

of the flow under test with an SFM header, a Decapsulator Responder (29.2.6) removing the SFM header,

optionally placing its own MAC in the source_address field of the decapsulated data frames, and sending the

data frames to a station or stations as specified by the destination_address field. By default, RPT’s

Decapsulator Responder places its own MAC address in the source_address field of the decapsulated dataframes before sending them out. However, a network operator can force a Decapsulator Responder not to

change the source_address field of the decapsulated data frame before sending it out to conduct special

purpose testing.

The RPT allows a network operator to inject specific data frames into the network for testing purposes. To

prevent one network operator from injecting traffic to other networks, it is necessary for the associated

managed object to be created under secure mode and for SFM originator to be in the same Maintenance

Domain as the MP on which Decapsulator Responder is defined.

The Figure 29-2 illustrates a simple case of injected traffic from Node B to reach Node A. Multiple data

frames can be injected and injected data frames could have different addresses or multicast addresses in their

corresponding destination_address field.

Figure 29-2—Return path test

The RPT consists of the Decapsulator Responder configuration, the sending of SFMs, the action to

decapsulate and forward, and the analysis of the received data frames at their destination(s). The last step,

i.e., the analysis of the received data frames at their destination(s), is beyond the scope of this standard.

29.1.2.3 Derived testing scenarios

Forward path test and return path test can be used together in various ways to achieve more sophisticated

testing to diagnose and isolate data driven and data dependent faults. It is beyond the scope of this standard

AS F M O r i g in a t o r B

T h e D e c a p s u l a t o r R e s p o n d e r d e c a p s u l a t e s t h e

S F M f r a m e s a n d s e n d t h e m t o s t a t i o n s s p e c i fi e d

b y D A f ie l d o f d e c a p s u l a t e d d a t a f r a m e s

S FM

8/8/2019 802.1Qaw-2009




to elaborate different ways of combining forward path test and return path test. This subclause only

illustrates one example of using both forward path test and return path test.

Figure 29-3 shows how to achieve segment fault isolation in the middle of a network using FPT and RPT

together. By creating a Decapsulator Responder and Reflection Responder on two Bridge Ports in the middle

of a network, a network operator can test if the specified data frames can traverse through the segment or

not. This type of testing is especially useful to diagnose data driven and data dependent faults out of firewall.This type of testing can also be used to diagnose a connectivity fault between two intermediate Bridge Ports

(or two MIPs) by setting the Reflection Responder filter (29.2.2.1) to the specified CCMs.

Figure 29-3—Combination of forward path test and return path test

29.2 DDCFM Entity operation

This subclause specifies the following:

a) Forward path test Reflection Responder b) Forward path test RFM Receiver

c) Return path test Decapsulator Responder

d) Return path test frames’ SFM Originator

29.2.1 DDCFM implementation

The data driven and data dependent connectivity fault management (DDCFM) protocol is performed by the

Reflection Responder, the Decapsulator Responder, the RFM Receiver, and the SFM Originator. All of these

entities are created and activated by operator commands. The operation of Reflection Responder,

Decapsulator Responder, and SFM Originator are timer limited.

Both RFMs and SFMs are CFM PDUs and their format is described in 21.4 and 29.4. They are forwarded in

the same way as regular CFM messages. An MEP at higher MD level shall drop the received RFMs and

SFMs. An MEP at the same level shall process, but not forward, RFMs and SFMs received from its Active

SAP, and shall drop RFMs/SFMs received from its Passive SAP. An MHF shall always forward RFMs/

SFMs received from its SAPs and shall also process those at the same MD level received from its Active

SAP.

The RR, RFM Receiver, DR, and SFM originator are CFM entities that are associated with a specific MD,

enabling access only to the administrators of this MD. They can be placed at any point in the network that is

bounded by any Domain SAP (DoSAP) of their corresponding MDs. Their relationship to MPs is guided by

A

T a r g e t

DCB

D e c a p s u l a to r R e s p o n d e r

R e f l e c t io n R e s p o n d e r

w i t h C o n t i n u e o p t io n

e n a b l e d

S e g m e n t u n d e r t e s t

S F M

R F M

8/8/2019 802.1Qaw-2009




the MP component entities that the DDCFM entities also require. In particular, the RR does not require any

of the MP’s sub-functions (19.2 and 19.3) and correspondingly it is defined as an independent CFM shim. It

can be placed at any Bridge Port bounded by the DoSAP of the RR’s associated MD. It does not even require

the EISS Multiplex Entity (6.17) or Backbone Service Instance Multiplexer (6.18). The same holds true for

an SFM Originator. Note that both of them transmit CFM frames that are associated with a specific MA but

the creation of these DDCFM entities themselves is not associated with an MA. This in practice means that

one RR or SFM Originator can send RFMs or SFMs (respectively), which are associated with different MAs

than the encapsulated frames. The other two DDCFM entities have a number of common subentities to the

MPs. In particular, on top of their unique (MP) RFM Receiver and (MP) Decapsulator Responder state

machines, they require the functions provided by the Type Demultiplexer, Level Demultiplexer, and the

OpCode Demultiplexer. In addition if the service is VLAN based, they also require the EISS Multiplex

Entity. All of these make the implementation of the RFM receiver or the Decapsulator Responder very

simple in the case of an MP where they can re-use the MP component entities and provide the additional

functions required by the MP RFM Receiver or MP Decapsulator Responder entities. Implementing these

DDCFM entities on non MPs would require all the previously mentioned MP subentities. Figure 29-5 shows

an MP independent RFM Receiver and Figure 29-6 shows an MP independent Decapsulator Responder. On

the other hand, implementing these DDCFM entities on MPs would require only the addition of the MP

Decapsulator Responder and MP RFM Receiver component entities in the MP architecture with the

appropriate changes in the Opcode Demultiplexer as specified in 19.2 and 19.3.

29.2.2 Forward Path Test Reflection Responder

The Reflection Responder (RR) is a CFM protocol shim for filtering frames to be reflected, copying the

filtered frames to the Passive SAP if the Continue option is set, and encapsulating each filtered frame with

the RFM header (29.4.2). For an interface supporting DDCFM, an RR shim shall be allowed at EISS/ISS

SAPs where MPs are allowed on the protocol stack shown in Figure 22-4, Figure 22-8, Figure 26-2, and

Figure 26-8. By placing an RR shim on an aggregated IEEE802.3 port within a Bridge Port, the RR can

reflect data frames from an member link of a Link Aggregation Group to test if specific data frames can go

through the link.

The Figure 29-4 illustrates the component entities of a Reflection Responder.

Figure 29-4—Detailed Functions of Reflection Responder

— ( ) — (E)ISS Passive SAP


RR Filter

RFM

RR EncapsulationRR Transmit (

) —

( E ) I S S R R T r a n s m i t S A P

( F r a m e s ! = F

i l t e r ) | | R R c o n t i n u e | | ! R R a c t i v e

F r a m e s = =

F i l t e r

8/8/2019 802.1Qaw-2009




29.2.2.1 RR Filter

The RR Filter function within the Reflection Responder filters frames from Active SAP that match the

Reflection Filtering definition(s) [29.2.3 b2)]. When the RR is active and the sampling interval has expired,

a frame that matches the Reflection Filter definition(s) is sent to RR Encapsulation to be reflected. A frame

is passed to the Passive SAP when RR is not active, the frame does not match the Reflection Filter

definition(s), or the Continue option is true.

To prevent data frames from being reflected multiple times within a network, RFM frames cannot be

reflected. An RR Filter definition implicitly includes the condition of the OpCode in common CFM header

not equal to RFM, in addition to all other conditions specified.

29.2.2.2 RR Encapsulation

The RR Encapsulation function within the Reflection Responder is for encapsulating the filtered frame with

the appropriate RFM header. If a sampling interval is specified, once a frame meeting the Reflection

Filtering definitions is identified within one sampling interval, no more frames shall be encapsulated until

the next sampling interval starts.

29.2.2.3 RR Transmit

RR Transmit identifies the egress port by querying FDB and forwards the RFM frames to the LOM entity of

the identified egress port. The query uses the Reflection Target address [12.18.2.1.2, b3)] and the

vlan_identifier associated with the RFM [29.3.3.3, c)]. If there is no vlan_identifier associated with the

RFM, the PVID value of the port where RR is configured is used. If an egress port cannot be identified and

the FloodingEnabled flag of the RR is true, then the RFM frame is sent to the LOM entity on every port

associated with the VID set of the RFM frame. If the FloodingEnabled flag of the RR is false and an egress

port cannot be identified, the RFM frame is dropped.

29.2.3 Reflection Responder related parameters

29.2.3.1 Reflection Responder identification

A Reflection Responder is identified by the interface upon which the RR is created, a Maintenance Domain

that identifies the administrative boundaries, and a value indicating the direction (Up or Down) in which the

RR is facing. The interface upon which the RR is created can be a Bridge Port or a member port of a LAG of

a Bridge Port.

29.2.3.2 Maintenance Association for Reflection Responder

The primary VID associated with RR’s MA is in the RFM emitted by the RR. When MA for an RR is set to

0, then the VID of the filtered frame are used in the corresponding RFM.

29.2.3.3 Reflection Responder Filter definition

The Reflection Responder Filter is for selecting data frames to be reflected. Multiple filters can be combined

together by “&& (and)”, “|| (or)”, or “! (negation)” operations.

All bridges supporting DDCFM shall support the following reflection filters (and may support additional

Reflection Filters):

a) Reflect All—all frames are selected.

b) VLAN based selection—all data frames belonging to the specified VLAN are selected.

8/8/2019 802.1Qaw-2009


8/8/2019 802.1Qaw-2009




29.2.5 Return path test related parameters

Return path test configuration has two parts: one part is to configure SFM Originator and the other part is to

configure Decapsulator Responder.

29.2.6 Decapsulator Responder

The Decapsulator Responder (DR) decapsulates Send Frame Messages (SFMs), and sends the decapsulated

frames towards destinations specified by the destination_address field of the decapsulated data frames.

Under normal circumstance, the source_address field of the decapsulated frame is replaced by the DR’s own

MAC address to avoid confusing other bridges’ learning in the network. However, a network operator can

enforce the DR not to modify the source_address field of the decapsulated frame for special purpose fault

diagnosis. The Decapsulator Responder configuration is specified in 12.18.4.1.

DR shim shall be allowed at EISS/ISS SAPs where MPs are allowed on the protocol stack shown in Figure

22-4, Figure 22-8, Figure 26-2, and Figure 26-8.

Multiple DRs can be created on one bridge interface to receive SFMs at different MD levels or SFMs

originated from different SFM Originators.

When an SFM is received by an active DR, it is examined for validity and discarded if invalid. If valid, the

received SFM shall be decapsulated. The source_address field of the decapsulated frame is replaced by DR’s

own MAC address unless SourceAddressStayFlag is set. The modified frame shall be used to identify the

egress port by querying the FDB. The query uses the destination_address and vlan_identifier values of the

decapsulated data frame. If the decapsulated frame is untagged, the PVID value of the port where DR is

configured is used. The Boolean FloodingEnabled flag of the DR indicates if the frame is to be flooded or

discarded if an egress port cannot be identified by FDB. Figure 29-6 illustrates the detailed functions of

Level Demultiplexer

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

RFM Receiver

— ( ) — (E)ISS Passive SAP


Type Demultiplexer

F r a m e T y p e ! = C F M

Frame Type == CFM

Multiplexer

RFM

F r a m e M D


Frame MD Level == mdLevel F r a m e M D

L e v e l < m d L e v e l

other

F r a m e M D

L e v e l n o t p r e s e n tOpCode De-

multiplexer

8/8/2019 802.1Qaw-2009


8/8/2019 802.1Qaw-2009




29.3.1.2 nPendingRFMs

An integer value used to track the number of RFMs to be transmitted. nPendingRFMs is a variable that can

be incremented by every Reflection Responder’s RR Encapsulation state machine and can be decremented

by RR Transmit state machine.

nPendingRFMs is set to 0 when all of the Reflection Responders on the bridge are de-activated.

29.3.1.3 dataReceived

dataReceived is a Boolean variable, which is set to true when there is a data frame received from (E)ISS, and

set to false by the RR Filter state machine.

29.3.1.4 dataFrame

This variable is the data frame received from (E)ISS.

29.3.1.5 nFilteredFrameList

This variable keeps track of the number of filtered data frames to be reflected. This variable is incremented

by RR Filter and decremented by Reflection Responder’s Encapsulation state machine.

29.3.1.6 filteredFrameList

This is a list of received data frames from RR Filter that have not been processed yet.

29.3.1.7 nextFilteredFrame

This variable copies the first one on the filteredFrameList to be reflected as RFM. Once a frame is copied to

this variable, the frame is removed from the filteredFrameList.

29.3.1.8 RRtime

RRtime is the value of RR Duration (29.2.3.6).

29.3.1.9 RRwhile

RRwhile is a timer variable, which is initialized to RR Duration [ 12.18.2.2.2, b7)] when RR is activated and

used by the RR Filter state machine to time out the active Reflection Responder. RRwhile has granularity in

seconds.

29.3.1.10 RRsampInt

RRsampInt is the sampling interval (29.2.3.4) during which the RR only reflects a maximum of one frame

that meets the filter condition. When the sampling interval is not configured, RRsampInt is set to 0.

29.3.1.11 RRsampWhile

A timer variable used by RR Filter state machine to time out sampling interval.

8/8/2019 802.1Qaw-2009




29.3.1.12 RRmaxFrames

The maximum number of frames for RR to reflect after RR is activated [ 12.18.2.2.2, b8)]. Once activated,

RR will stay active until either RRmaxFrames is reached or RRwhile ( 29.3.1.9) expires, whichever comes

first. If RRmaxFrames is set to 0, the RR stays active until RRwhile (29.3.1.9) expires.

29.3.1.13 RRframeCount

A counter used by the Reflection Responder’s Encapsulation state machine to keep track of the number of

data frames to be reflected. Once RRframeCount is equal to or greater than RRmaxFrames, Reflection

Responder is de-activated.

29.3.1.14 filterMatched

A Boolean variable that is set to true if the data frame received matches with the RR’s filter conditions and

false if the data frame received does not match the RR’s filter conditions.

29.3.1.15 RRactive

RRactive is true when the corresponding Reflection Responder is active and false otherwise.

29.3.1.16 nextRFMtransID

The value to place in the RFM Transaction Identifier field of the next RFM to be transmitted.

nextRFMtransID is incremented by 1 by the Reflection Responder’s processRRencap() procedure with each

transmission.

This variable is readable as a managed object [12.18.2.3.3, b.14)].

29.3.1.17 maxDataTLVvalueSize

This is the maximum number of bytes allowed to be copied into Reflected Data TLV’s value field in order to

keep the RFM’s service data unit size not exceeding its Maximum Service Data Unit Size (MSDUS) (6.5.8).

The length of an RFM PDU is 12 octets (4 bytes for CFM header + 1 byte for End TLV(0) + 4 bytes

Transaction Identifier + 3 bytes Reflected Data TLV Type/Length field) + the actual number of bytes of the

reflected data frame. If there is no other optional TLV for the RFM data frame1, then

a) maxDataTLVvalueSize = MSDUS – (5 (CFM common header length) + 4 (Transaction Identifier) +

3 (Reflected Data Frame TLV Type/Length field))

29.3.1.18 reflectedDataLength

This variable is to hold the value for the Length field of Reflected Data TLV (29.4.2.4).

29.3.2 RR Filter Procedures

The following procedures are defined for the RR Filter state machine:

a) filterFrame()

b) forwardFrame()

c) loadFilteredFrameList()

1Even though not required, implementers may choose to include other optional TLVs in RFM. If extra TLVs are included in a RFM, themaxDataTLVvalueSize has to be decremented by the number of bytes taken by the extra TLV.

8/8/2019 802.1Qaw-2009




29.3.2.1 forwardFrame()

This procedure passes the frame received to (E)ISS Passive SAP.

29.3.2.2 filterFrame()

filterFrame() is called when RRactive is true and there is a data frame received from EISS. This procedure performs the following steps

a) If the received data frame from (E)ISS SAP meets the Reflection Filter definition(s), then returns

true

b) Otherwise, returns false

29.3.2.3 loadFilteredFrameList()

This procedure adds the received frame to the filteredFrameList.

29.3.3 RR Encapsulation Procedures

The following procedures are defined for the RR Encapsulation state machine:

a) processRRencap()

b) splitFilteredFrame()

c) constructRFM()

29.3.3.1 processRRencap()

processRRencap() is called when RR is activated and filteredFrameList is not empty. There are two local

variables in this procedure: DataFrame_1 and DataFrame_2, which are used when the filtered frame has to

be truncated or split into two frames to be reflected.

processRRencap() processes the incoming data frame from the RR Filter as follows:

a) Set the reflectedDataLength variable to the length of the nextFilteredFrame.

b) If the value of reflectedDataLength is larger than the bridge’s maxDataTLVvalueSize (29.3.1.17),

then call splitFilteredFrame (nextFilteredFrame, DataFrame_1, DataFrame_2) and then perform the

following two steps:

1) If Truncation flag is set, call constructRFM(TLV_type, maxDataTLVvalueSize,

DataFrame_1), where the TLV_type is set to the “Truncated Data TLV” type value defined by

Table 21-6

2) If the Truncation flag is not set, perform the following two steps:

— constructRFM(TLV_type, maxDataTLVvalueSize, DataFrame_1), where the TLV_type is

set to the “Data Part 1 TLV” type value defined by Table 21-6

— constructRFM(TLV_type, reflectedDataLength – maxDataTLVvalueSize, DataFrame_2),

where the TLV_type is set to the “Data Part 2 TLV” type value defined by Table 21-6

c) Otherwise, call constructRFM(TLV_type, reflectedDataLength, nextFilteredFrame), where

TLV_type is set to the “Data TLV” type value defined by Table 21-6.

29.3.3.2 splitFilteredFrame()

This procedure is called when the nextFilteredFrame causes the length of RFM’s service data unit size to be

larger than the Maximum Service Data Unit Size (6.5.8). There are three parameters for this procedure:

a) nextFilteredFrame, which is an input to the procedure.

8/8/2019 802.1Qaw-2009




b) DataFrame_1, which contains the first maxDataTLVvalueSize number of bytes from the

nextFilteredFrame.

c) DataFrame_2, which contains the remaining bytes from the nextFilteredFrame.

splitFilteredFrame() performs the following steps:

— Copy the maxDataTLVvalueSize number of bytes from the nextFilteredFrame to DataFrame_1. — Copy the remaining bytes from the nextFilteredFrame to DataFrame_2.

29.3.3.3 constructRFM()

This procedure is to construct a RFM frame and increment the nPendingRFMs by 1. There are three

parameters passed into this procedure:

a) TLV_Type, which could be 3 (i.e., Data TLV) (21.5.6), 9 (Truncated Data TLV) (21.5.1.1), 10 (Data

Part 1 TLV), or 11 (Data Part 2 TLV).

b) TLV_Length, which is the length of the reflected data frame.

c) Data frame to be included in the TLV value field.

This procedure constructs the RFM (E)M_UNITDATA.request by the following steps:

d) Sets the source_address parameter to the MP’s or bridge interface’s own MAC address.

e) If the Reflection Target Address [12.18.2.2.2, b4)] is not specified, then source_address of the

selected data frame is copied to the RFM’s destination_address parameter; otherwise, Reflection

Target Address is copied to the RFM’s destination_address parameter.

f) Sets the priority and drop_eligible parameters to the priority and drop_eligible attributes of the

Reflection Responder managed object (12.18.2.2.2).

g) In a VLAN aware bridge, the primary VID associated with the RR’s MA [12.18.2.1.2, b1)] is used

as the vlan_identifier. If the RR’s MA is set to 0, the vlan_identifier is determined by the following:

1) If the RR is defined on an S-VLAN component, use the S-VID if the S-VID is present in the

selected data frame, otherwise use the PVID of the port where RR is configured.

2) If the RR is defined on a C-VLAN component, use the C-VID if the C-VID is present in the

selected data frame, otherwise use the PVID of the port where the RR is configured.h) Copy RFM OpCode to the RFM’s OpCode Field.

i) Copy the RR’s Maintenance Domain Level [12.18.2.1.2, a)] to the RFM’s MDLevel field.

j) Copy the first parameter (TLV_Type) to the Reflected Data TLV Type field.

k) Copy the second parameter (TLV_Length) to the Reflected Data TLV Length field.

l) Copy the third parameter (Data frame) to the Reflected Data TLV value field.

m) Copy the nextRFMtransID to the RFM Transaction Identifier field. Increment nextRFMtransID by

1, wrapping around from 232 – 1 to 0.

n) Increment nPendingRFMs by 1.

o) Sets the frame_check_sequence parameter to the unspecified value; sets the connection_identifier to

null, and sets the canonical_format_indication to 0 (6.6.1).

29.3.4 RR Transmit procedure

The following procedure is defined for the RR Transmit state machine:

a) xmitRFM()

29.3.4.1 xmitRFM()

xmitRFM() is called by the RR Transmit state machine. It queries the FDB in order to identify an egress

port. The set of potential transmission ports, normally created by the Active Topology enforcement (8.6.1) in

8/8/2019 802.1Qaw-2009




IEEE Std 802.1Q, is the set of all bridge interfaces that are both in the active set of the vlan_identifier

associated with the RFM, and that are in the Forwarding state for that vlan_identifier.

a) Query FDB using the RFM’s destination_address field and vlan_identifier parameter values.

b) If an egress port is identified and the identified Egress port meets the following conditions:

1) The Egress port does not have a Down MEP with higher MD level than the RFM’s MD;2) The Egress port does not have an Up MEP with same or higher MD level as the received

RFM’s MD;

then send an RFM EM_UNITDATA.request to the egress port’s LOM SAP. Otherwise, drop the

received RFM frame;

c) If an egress port cannot be identified

1) When the FloodingEnabled flag of the RR [12.18.2.1.2, b7)] is not set, drop the frame.

2) When the FloodingEnabled flag of the RR is set, send M_UNITDATA.request to the LOM’s

SAP of every forwarding port that meets the conditions 1) and 2) of item b) above.

29.3.5 Reflection Responder related state machines

29.3.5.1 RR Filter state machine

Figure 29-7 depicts the state machine for RR Filter.

Figure 29-7—RR Filter state machine

filterMatched &&

!RRcontinue &&

RRsampWhile == 0

RR_DISABLE

RR_WAITING

RR_START

RR_FILTER

RR_REFLECT

RRactive

UCT

RRactive && RRwhile > 0 &&

!(RRmaxFrames > 0 &&RRframeCount >= RRmaxFrames ) &&

dataReceived

filterMatched &&!RRcontinue &&

RRsampWhile > 0

!RRactive || RRwhile == 0 ||

(RRmaxFrames > 0 &&

RRframeCount >= RRmaxFrames)

BEGIN

RRwhile = RRtime

dataReceived = FALSE

filterMatched = filterFrame()

loadFilteredFrameList()

nFilteredFrameList +=1

RRframeCount += 1

RRsampWhile = RRsampInt

RRactive = FALSERRframeCount = 0

RRsampWhile = 0

RRwhile = 0

filterMatched = FALSE

RR_FORWARD_ACTIVE

forwardFrame()

!RRactive &&dataReceived

!filterMatched ||RRcontinue

filterMatched &&RRsampWhile == 0

!filterMatched ||

RRsampWhile > 0

UCT

RR_FORWARD_INACTIVE

dataReceived = FALSE

forwardFrame()

RRactive !RRactive

8/8/2019 802.1Qaw-2009




29.3.5.2 RR Encapsulation state machine

Figure 29-8 describes the state machine for RR Encapsulation.

Figure 29-8—RR Encapsulation state machine

29.3.5.3 RR Transmit state machine

RR Transmit state machine can be shared by multiple Reflection Responders activated on the bridge.

Figure 29-9—RR Transmit state machine

29.3.6 RFM Receiver variables

The following variables are local to the RFM Receiver state machine. There is one instance of these

variables per RFM Receiver.

RR_ENCAP_WAITING

nFilteredFrameList = 0

RR_ENCAP_OFF

BEGIN

UCT

processRRencap()

nFilteredFrameList -=1;

RR_ENCAP

nFilteredFrameList !=0

nFilteredFrameList !=0nFilteredFrameList ==0

RR_XMIT

xmitRFM ()

RR_XMIT_OFF

nPendingRFMs = 0

nPendingRFMs -=1;

nPendingRFMs >0

BEGIN

nPendingRFMs > 0nPendingRFMs == 0

8/8/2019 802.1Qaw-2009




29.3.6.1 RFMreceived

RFMreceived is a Boolean variable, which is set to true by the MP OpCode Demultiplexer when an RFM is

received, and cleared by the RFM Receiver state machine.

29.3.6.2 RFMPDU

RFMPDU is a record of the M_UNITDATA.indication or EM_UNITDATA.indication parameters of the last

RFM received by the MP OpCode Demultiplexer (19.2.7).

29.3.7 RFM Receiver procedure

The procedure listed in 29.3.7.1 through 29.3.7.2 is defined for the RFM receiver:.

29.3.7.1 ReceiveRFM()

ReceiveRFM() procedure performs the following steps:

a) If the destination_address field of the received RFM does not match the RFM Receiver’s MAC

address, drops the frame. b) Otherwise, pass the received RFMPDU to RFM Analyzer.2

Even though RFM Analyzer is out of the scope of this standard, RFM Analyzer has to be able to recognize

the value in Reflected Data TLV (29.3.3.2), which could be

— A whole data frame being reflected; or

— A truncated data frame being reflected; or

— The first portion of the data frame being reflected; or

— The second portion of the data frame being reflected.

If an RFM Receiver is configured on an MP and the RFM Receiver does not receive any RFMs within the

expected time frame, it can send a LBM (21.7) to the MP on which the Reflection Responder is defined to

verify the connectivity to the MP. If there is no LBR received, ReceiveRFM() can report an alarm to thenetwork administrator.

2RFM Analyzer is out of the scope of this standard.

8/8/2019 802.1Qaw-2009




29.3.7.2 RFM Receiver state machine

Figure 29-10—RFM Receiver state machine

29.3.8 Decapsulator Responder variables

There is one instance of the parameters listed in 29.3.8.1 through 29.3.8.7 per Decapsulator Responder.

29.3.8.1 DRwhile

A timer variable used by the Decapsulator Responder state machine to time out the active Decapsulator

Responder. DRwhile has a granularity finer than or equal to 1 s.

29.3.8.2 DRtime

The time that the Decapsulator Responder can remain active after its activation.

29.3.8.3 SFMPDU

SFMPDU is a record of the M_UNITDATA.indication or EM_UNITDATA.indication parameters of the

SFM received by the MP OpCode Demultiplexer (19.2.7) when an SFM is received.

29.3.8.4 DRactive

DRactive variable represents the activation status of the corresponding Decapsulator Responder. DRactive is

set to true when the corresponding Decapsulator Responder is activated and set to false when the

corresponding Decapsulator Responder is de-activated or its duration expires. When DRactive is false, all

SFMs received by the bridge interface are dropped.

29.3.8.5 SFMreceived

SFMreceived is set to true by the OpcodeDemultiplexer (19.2.7) when an SFM is received.

29.3.8.6 previousSFMtransId

previousSFMtransId variable keeps the value of SFM Transaction Identifier of the previously received SFM

frame. The previousSFMtransId variable is initialized to zero when the DR is activated.

R F M _ R E C E I V E

R F M _ R X _ W A IT IN G

r e c e iv e R F M ( );

R F M r e ce iv e d

B E G I N

R F M r e c e iv e d = f a ls e ;

U C T

8/8/2019 802.1Qaw-2009


8/8/2019 802.1Qaw-2009


8/8/2019 802.1Qaw-2009




29.4.2.1 Flags

(1 octet) in RFM. The Flags field of the Common CFM Header for RFM is reserved for future use.

29.4.2.2 First TLV Offset

(1 octet) The First TLV Offset field of the Common CFM Header in a RFM is transmitted as 4.

Validation Test: The First TLV Offset field of the Common CFM Header in a RFM contains a value greater

than or equal to 4.

29.4.2.3 RFM Transaction Identifier

(4 octets) A Reflection Responder copies the content of nextRFMtransID variable (29.3.1.16) to this field.

29.4.2.4 Reflected Data TLV

Reflected Data TLV in RFM is a Data TLV (21.5.6) to contain the reflected data frame. The Length field is

the total octets of the reflected data frame.

The Type field of the Reflected Data TLV could be one of the following four values (Table 21-6):

a) Data TLV Type value, which is 3

b) Truncated Data TLV Type value, which is 9

c) Data-Part-1 TLV Type value, which is 10

d) Data-Part-2 TLV Type value, which is 11

29.4.2.5 Additional RFM TLVs

The following TLVs may be included in a RFM by each MP originating RFM (Reflection Responder):

a) Send ID TLV (21.5.3) and

b) Organization-Specific TLVs (21.5.2)

The Additional RFM TLVs may be placed in any order.

Table 29-1—RFM format

Octet

Common CFM Header 1–4

RFM Transaction Identifier 5–8

Reserved for definition in future versions of the protocola

Reflected Data TLV First TLV Offset + 5

Additional TLVFirst TLV Offset + 5

+ Length of Reflected Data TLV

End TLV (0)

aThis field has 0 length in this version 0 of DDCFM. It is shown in order to stress that additionalinformation can be present in future versions of DDCFM, and that a version 0 receiver ignoresits contents, if present.

8/8/2019 802.1Qaw-2009




29.4.3 SFM format

The SFM format is shown in Table 29-2.

29.4.3.1 Flags

(1 octet) in SFM. The Flags field of the Common CFM Header for SFM is reserved for future use.

29.4.3.2 First TLV Offset

(1 octet) The First TLV Offset field of the Common CFM Header in an SFM is transmitted as 4.

Validation Test: The First TLV Offset field of the Common CFM Header in an SFM contains a value

greater than or equal to 4.

29.4.3.3 SFM Transaction Identifier

(4 octets) SFM originator may use this field to distinguish the order of SFMs sent. DR may use this identifier

to check the order of the received SFMs.

29.4.3.4 SFM Original Data TLV

SFM Original Data TLV is a Data TLV (21.5.6) to contain the original data frame. The Length field is the

total octets of the original data frame, including its destination_address, source_address, TPID, TCI, Type/

Length, client data, pad ,and FCS fields.

29.4.3.5 Additional SFM TLVs

The following TLVs may be included in an SFM by each SFM Originator:

a) Send ID TLV (21.5.3)

b) Organization-Specific TLVs (21.5.2)

The Additional SFM TLVs may be placed in any order.

Table 29-2—SFM format

Octet

Common CFM Header 1–4

SFM Transaction Identifier 5–8

Reserved for definition in future versions of the protocola

aThis field has 0 length in this version 0 of DDCFM.

Original Data TLV First TLV Offset + 5

Additional TLVsFirst TLV Offset + 5 +

Length of OriginalData TLV

End TLV (0)

8/8/2019 802.1Qaw-2009


8/8/2019 802.1Qaw-2009




Annex A

(normative)

PICS proforma3

A.5 Major capabilities

A.14 Bridge management

Insert the following rows at the end of the table in A.14

3Copyright release for PICS proformas: Users of this standard may freely reproduce the PICS proforma in this annex so that it can beused for its intended purpose and may further publish the completed PICS.

Insert the following row at the end of the table in A.5:

Item Feature Status References Support

DDCFM Is management of data driven and data dependentconnectivity faults implemented?

O 19, 29 Yes[ ] No [ ]


MGT-100 Does the Bridge provide control of all the requiredDDCFM managed objects?

DDCFM:M <12.18> Yes[ ]

Questions DDCFM-MGT-2 through DDCFM-MGT-21 refer to operations related to DDCFMmanaged objects.

MGT-102 Create Reflection Responder managed object DDCFM:M 12.18.2.1 Yes[ ]

MGT-103 Read Reflection Responder managed object DDCFM:M 12.18.2.3 Yes[ ]

MGT-104 Write Reflection Responder managed object’sattributes

DDCFM:M 12.18.2.2 Yes[ ]

MGT-105 Delete Reflection Responder managed object DDCFM:M 12.18.2.4 Yes[ ]

MGT-106 Activate a Reflection Responder managed object DDCFM:M 12.18.2.5 Yes[ ]

MGT-107 De-activate a Reflection Responder managedobject

DDCFM:M 12.18.2.6 Yes[ ]

MGT-108 Create RFM Receiver managed object DDCFM:M 12.18.3.1 Yes[ ]

MGT-109 Delete RFM Receiver managed object DDCFM:M 12.18.3.2 Yes[ ]

MGT-110 Create Decapsulator Responder managed object DDCFM:M 12.18.4.1 Yes[ ]

MGT-111 Read Decapsulator Responder managed object DDCFM:M 12.18.4.2 Yes[ ]

MGT-112 Write Decapsulator Responder managed object’sattributes

DDCFM:M 12.18.4.3 Yes[ ]

MGT-113 Delete Decapsulator Responder managed object DDCFM:M 12.18.4.4 Yes[ ]

MGT-114 Activate a Decapsulator Responder managed object DDCFM:M 12.18.4.5 Yes[ ]

8/8/2019 802.1Qaw-2009


IEEEStd 802.1Qaw-2009

A.24 Management Information Base (MIB)

Insert one row at the end of the table in A.24 as follows:

Insert new A.27 as follows:

A.27 Data driven and data dependent connectivity fault management

MGT-115 De-activate a Decapsulator Responder managedobject

DDCFM:M 12.18.4.6 Yes[ ]

MGT-116 Create SFM Originator managed object DDCFM:M 12.18.5.1 Yes[ ]

MGT-117 Read SFM Originator managed object DDCFM:M 12.18.5.2 Yes[ ]

MGT-118 Write SFM Originator managed object’s attributes DDCFM:M 12.18.5.4 Yes[ ]

MGT-119 Delete SFM Originator managed object DDCFM:M 12.18.5.3 Yes[ ]

MGT-120 Activate SFM Originator managed object DDCFM:M 12.18.5.5 Yes[ ]

MGT-121 De-activate SFM Originator managed object DDCFM:M 12.18.5.6 Yes[ ]


MIB-21 Is the IEEE8021-DDCFM-MIB module fullysupported (per its MODULE-COMPLIANCE)?

MIB:O 17.7.9 Yes[ ]


DDCFM-1 Does the Bridge support the Reflection Responder function?

DDCFM:M 29.2.2 Yes[ ]

DDCFM-2 Does the Bridge support the RFM Receiver function?


DDCFM-3 Does the Bridge support the Decapsulator Responder function?


DDCFM-4 Does the Bridge support the SFM Originator function?

