Requested revision
Standard: | 802.1Q-2011 | Clause: | 5.4.4, 10.3, 35.2.4 |
Clause title: | MSRP requirements, |
Rationale for revision
Clause 5.4.4 requires MSRP to make use of the MAP operation specified in
10.3.1; however, clause 10.3 clearly states:
"The MAP function for the MSRP application is specified in 35.2.4."
Further, 35.2.4 indicates:
"For the Talker and Listener attributes MSRP propagates attributes in a
manner different from that described in 10.3 for MMRP and MVRP"
5.4.4, 10.3, and 35.2.4 must be made consistent.
Currently, there is no MAP behavior defined for how new or non-new
attributes
are propagated or what to do when tcDetected occurs.
per 10.1 last paragraph: “The rules applied to the marking and
propagation of
newly declared values in this way are common to all MRP Applications;
however,
the action taken on receipt of an attribute declaration marked as “new” is
specific to each MRP Application
Proposed text
Remove the conflict between 5.4.4 and 10.3/35.2.4.
TWO substantial changes:
#1:
5.4.4(d) to point to 35.2.4.5 rather than 10.3.1.
5.4.4(d) also must not reference the "Base Spanning Tree Context" but rather
should reference the "single context" referred to in 35.2.4.5
Re-write 5.4.4(d) as follows:
"Propagate registration information in accordance to the the single
context for
MSRP attribute propagation that includes all Bridge Ports, as specified in
35.2.4.5."
#2:
Add to 35.2.4 or anyplace deemed more fitting:
For any MAD_Join.indication, or any MAD_Join.request being propagated by
the
MSRP Atribute Propagation,
if the 'new' parameter in the request being propagated is TRUE, then the
value of the 'new' parameter in the propagated MAD_Join.request is set
TRUE.
If the value of tcDetected (13.23) for the Port providing the
MAD_Join.indication and MAP Context is nonzero, then the value of the 'new'
parameter in the propagated MAD_Join.request is set TRUE, regardless of the
value of this parameter in the indication or request that is being
propagated.
Otherwise the 'new' parameter in the propagated request is FALSE.
Impact on existing networks
Without standard specified behavior, existing implementations may vary in
their MAP operation, specifically in regard to 'new'
Originator
Name: | Aaron Stewart, Bob Noseworthy | Email: | astewart@iol.unh.edu; ren@iol.unh.edu |
Affiliation: | University of New Hamsphire's InterOperability Lab | ||
Submitted: | 2012-08-23 |