1. Maintenance Items
  2. 0044
  3. Request
Requested revision
Standard:802.1Q-2011Clause:10.7.7
Clause title:Applicant State Machine
Rationale for revision
Note 11 of Table 10-3 (Applicant SM) states:
“In implementations where dynamic creation and discarding of state 
machines is

desirable, the state machine can be discarded when in any of these states,
pending a future requirement to declare or register that attribute value”

A similar NOTE in 10.7.8 (Registrar SM) states:
“As with the Applicant, state information is conceptually maintained for 
all

possible values of all Attribute types that are defined for a given
application; however, in real implementations of MRP, it is likely
that the range of possible Attribute values in some applications will
preclude this, and the implementation will limit the state to those
Attribute values in which the Participant has an immediate interest.”


The behavior in the LO state of the Applicant state machine when tx!
occurs requires “s” followed by a transition to the VO state. By
requiring “s”, the Applicant SM requires all attribute values to be sent
in response to (for example) an rLA! while in the VO state.

This is clearly not desirable, but it is unclear when to consider the
Applicant and Registrar state machines as ‘discarded’.
Proposed text
Insert a new note 9 before MRP design notes to Table 10-3
(applied to the intersections of STATE columns VO, AO, QO &
EVENTS “rLv! || rLA! || Re-declare!”):

“This state transition is ignored if responding to rLA! and the Registrar
state machine associated with this attribute value is MT.”


Insert a new note 10 before MRP design notes to Table 10-3
(applied to the intersections of STATE columns VO, AO, QO and
EVENTS txLA! and txLAF!):

“This state transition is ignored if the Registrar state machine associated
with this attribute value is MT.”
Impact on existing networks
None. The change makes clear that MT need not be sent for all possible attribute values.
Originator
Name:Aaron Stewart, Bob NoseworthyEmail:astewart@iol.unh.edu; ren@iol.unh.edu
Affiliation:University of New Hamsphire's InterOperability Lab
Submitted:2012-08-23