Interpretations

Answering questions that may arise related to the meaning of portions of an IEEE standard concerning specific applications.

Interpretation for IEEE Std 802.1ag™-2007 IEEE Standard for Local and Metropolitan Area Networks - Virtual Bridged Local Area Networks Amendment 5: Connectivity Fault Management

Copyright © 2011 by the Institute of Electrical and Electronics Engineers, Inc. 3 Park Avenue New York, New York 10016-5997 USA All Rights Reserved.

Interpretations are issued to explain and clarify the intent of a standard and do not constitute an alteration to the original standard. In addition, interpretations are not intended to supply consulting information. Permission is hereby granted to download and print one copy of this document. Individuals seeking permission to reproduce and/or distribute this document in its entirety or portions of this document must contact the IEEE Standards Department for the appropriate license. Use of the information contained in this document is at your own risk.

IEEE Standards Department Copyrights and Permissions 445 Hoes Lane, Piscataway, New Jersey 08855-1331, USA

October 2011

Interpretation Request #1
Topic: Support of priority tagged CFM frames

Clause 22.1.6 describes how a MEP, positioned above or below the Support of the EISS entity, can be used to transmit and receive untagged CFM frames for the purpose of protecting all the traffic on the port.

When a MEP is not associated with a VID, does it still transmit and receive untagged CFM frames when the following attributes are configured?

  • dot1agCfmMepCcmLtmPriority (clause 12.14.7.1.3:h)
  • dot1agCfmMepTransmitLbmVlanPriority (clause 12.14.7.3.2:e)

If the answer is yes, under what conditions can a MEP transmit and receive priority tagged CFM frames? [Note: The expectation is that a MEP can currently only transmit and received tagged and untagged CFM frames, and that an update to 802.1ag will be required to support priority tagged CFM frames.]

Interpretation Response
VLAN and/or priority tags are generated by certain functional elements (e.g. that specified in subclause 6.7 “Support of the EISS” in IEEE Std 802.1Q‐2005) in the interface stack supporting a Bridge Port. The CFM shims themselves do not generate VLAN or priority tags, nor does tag generation by other elements depend upon configuring CFM related priority attributes. Whether a tag appears in a transmitted CFM frame solely depends upon where the CFM shim is configured relative to other functional elements that do generate these tags.

The only functional element defined in 802.1Q (including all current amendments) that generates priority‐tagged frames is specified in subclause 6.9 “Support of the ISS for attachment to a Provider Bridged Network” in IEEE Std 802.1ad‐2005. This is not a general purpose priority‐tagging function. It is specifically constrained to be at the ISS of a port on a C‐component in a Customer Bridge connected to a Port‐based Service Interface to a Provider Bridged Network. In this scenario, a MEP could be configured on the ISS above this element and the result would be the transmission of priority‐S‐tagged (an S‐TAG with a VID value of zero) CFM frames. The standard does not prohibit configuring a MEP at this location, but it does not require that an implementation of a Customer Bridge support this capability.

Interpretation Request #2
Topic:  Clarification of the intention in ProcessLBR() Clause, Subclause, Annex, Figure, or Table:  20.31.1 ProcessLBR()

It seems that once any LBR with the incorrect LTID is received, then every LBR received after that will be considered to have an incorrect LTID, until LBIactive becomes false. This is because in action c)2), the received Loopback Transaction Identifier is copied to expectedLBRtransID, but expectedLBRtransID is not incremented after that.

It is possible that that was the intended behavior, that all subsequent LBRs are considered incorrect after one incorrect LBR is received.

However, it is also possible that it was intended for expectedLBRtransID to track the new LTID, so that the first LBR is considered incorrect but subsequent ones are considered correct.

Clarification of the intention in ProcessLBR() is requested. Is it as written, or was there a typo in the standard?  (e.g., was the intention to say "2) The value from the received Loopback Transaction Identifier field is copied into expecedLBRtransID, then expectedLBRtransID and the number of incorrect LBRs received [item z) in 12.14.7.1.3] is incremented by 1."

Interpretation Response
The intention of IEEE Std 802.1ag-2007 was that if LBRs 1 2 3 5 6 7 8 ... are received, only one error would be counted, for the 3-5 sequence.  If LBRs 1 2 3 5 4 6 7 8 ... are received, then three errors would be counted, one for 3-5, one for 5-4, and one for 4-6. This is not the behavior of IEEE Std 802.1g-2007 as currently written; this will be addressed in a future revision of IEEE Std 802.1Q™.

Interpretation Request #3
Subclause: 20.3.2 Linktrace Message reception, forwarding, and replying

Applicable conditions:
If an Up MEP, as shown in Figure 20-13, case 8, transmits a Linktrace, the Linktrace Responder should see it, decrement the TTL field, respond (to the MEP) and forward the LTM out the appropriate port, as shown in that diagram. However, according to point f) of 20.3.2 on page 144, the LTM would not be forwarded; it must have been received by an MHF in order to be forwarded. The case of an LTM generated by an internal Up MEP seems to have not been taken into account when writing point f).

Clearly, an LTM generated by an Up MEP should be forwarded.

Point f) now reads:

f) The LTM was received by an MHF, not a MEP; This should perhaps be changed to read:

f) The LTM was received via an MHF Linktrace SAP or a MEP LTI SAP, and not a MEP Linktrace SAP;

Interpretation Response
The document is in error. It is agreed that that an LTM generated by an Up MEP should be forwarded. The error will be addressed in the next revision of IEEE Std 802.1Q.