802.1 Tools
  • Home
  • Maintenance
    • All items
    • Open items
    • Closed items
    • Items for review
    • Status
  • Meetings
  • Help
  • Log in
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