Requested revision
Standard: | 802.1AS-2011 | Clause: | 10.2.11 |
Clause title: | PortSyncSyncSend State Machine |
Rationale for revision
PortSyncSyncSend SM (Fig 10-8) does not behave as intended if the device was grandmaster and then has priority1 set to 255, resulting in continuous erroneous transmission of Sync messages from a port that transitions from having priority1 set to a value not equal to 255, then set via management action to 255. ===== In the normal case, a device that is not GrandMaster capable will have priority1 set to 255. In this case gmPresent is always FALSE and the SiteSyncSync SM (Figure 10-3) will never issue a PortSyncSync structure to the PortSyncSyncSend SM. ===== In the case of a device that can be a grandmaster, consider the following case: If such a grandmaster-capable device has a priority1 value that is not 255 (eg: 248) then gmPresent will be TRUE and if such a device wins election as grandmaster via the BMCA (as is exceedingly likely even if just for a short time if the device is asCapable before its link partner) then the device's ClockMaster SM will issue a PortSyncSync structure through the SiteSyncSync SM to the PortSyncSyncSend SM. This results in a PortSyncSync structure being propagated to the Media Dependent layer by the entry to the SEND_MD_SYNC state and resulting action of the txMDSync function. As the device's ClockMaster is the source of the Sync, the syncReceiptTimeoutTime is set to a maximum value of 0xFFFFFFFFFFFFFFFF per 10.2.2.3.3 (and 10.2.8.2.1(h)). [Note: localPortNumber=0 per 10.2.8.2.1, and thus the selectedRole[localPortNumber]=slavePort per 10.3.12.1.4(h)(12) (hence why the SiteSyncSync SM forward's the sync)] Now consider such a device having its priority1 value changed to 255 via management action. Such a management change may be considered by some to be a violation of 8.6.2.1 which states: "The value of priority1 shall be 255 for a time-aware system that is not grandmaster-capable. The value of priority1 shall be less than 255 for a time-aware system that is grandmaster-capable." However it is not clear if a specific instance of a time-aware system can change from being "not grandmaster-capable" to grandmaster-capable" through only management action. Subclause 10.1.2 titled "Grandmaster-capable time-aware system" does strongly indicate that a device may elect to be grandmaster-capable or not "at-will", quoting 10.1.2: "A time-aware system may be grandmaster-capable. An implementation may optionally provide the ability to configure a time-aware system as grandmaster-capable via a management interface." (Note this issue has been discussed by Geoff Garner and 802.1AS-Rev members in January 2015, who indicate that yes, priority1 may be changed to 255 via management action as it is read/write) If such a change of priority1 to 255 is allowed, then a minor problem with the standard exists, specifically the device will continue to send Sync messages until a Sync message is received from a link partner, or the device's selectedRole[thisPort] != MasterPort (eg, it becomes a SlavePort). Furthermore, because the Sync message transmitted by the device is generated only by the PortSyncSyncSend SM, the preciseOriginTimestamp field is not updated at any time during the 'erroneous' transmission (though the followUpCorrectionField should be properly computed) It is believed that the standard intends to allow devices to arbitrarily change priority1 values to/from 255 at managment's discretion. The result of this change should prevent any Sync information from being transmitted when prioirity1 is 255. As noted in the NOTE in 10.1.2 quoted below: "NOTE—While a time-aware system that is not grandmaster-capable can never be the grandmaster of the gPTP domain, such a time-aware system contains a best master selection function, invokes the best master selection algorithm, and conveys synchronization information received from the current grandmaster." There are two points here: 1- a non-grandmaster-capable system still participates in BMCA (and as a result, still sends Announce messages per existing requirements not in dispute) 2- a non-grandmaster-capable time-aware system may still act as a time-relay (a bridge that never wishes to be (or cannot be) grandmaster, but can relay time) The following is provided by Geoff Garner: ========================================== "" In the discussion at the January meeting of 802.1AS-Rev/D0.8, we discussed the proposed fix to an issue where a device that is gmCapable has its priority1 changed to 255. If there are no other gmCapable devices in the network, this device will continue to send Sync messages. The reason is that, in this situation, there is nothing that will trigger the PortRoleSelection state machine and updtRolesTree(), which if triggered would result in the Announce messages sent by this node reflecting the changed priority1 information. This would eventually result in gmPresent changing to FALSE. However, since updtRolesTree() is not triggered, this will not happen, and the node will keep sending Sync messages. ""
Proposed text
This issue was raised in 2014 to Geoff Garner and discussed through 802.1AS-Rev meetings. As the following remedy is included in 802.1AS-Rev/D0.8 and D0.9, the proposed remedy is offered to raise awareness of the issue and align 802.1AS-2011 with the behavior anticipated to be in 802.1AS-Rev. The remaining text is provided by Geoff Garner: ========================================== The proposed fix is in D0.8, in 10.3.12.1.1 and in Figure 10-14 (the updtRolesTree() SM). Specifically, a new variable: systemIdentityChange is introduced. This is a Boolean that is set to TRUE whenever any attribute of the systemIdentity (see 10.3.2) changes (this includes priority1, clockClass, clockAccuracy, offsetScaledLogVariance, priority2, and clockIdentity). The variable is reset in the ROLE_SELECTION state of the PortRoleSelection SM. It is added as a condition (via an OR) to transition from this state back to itself. With this variable, if priority1 changes, systemIdentityChange will become TRUE, the transition will occur, and updtRolesTree() will get invoked (and systemIdentityChange will be reset to FALSE. Related to this, it was decided in the meeting to remove the note below systemIdentityChange that currently reads: NOTE - In practice, the systemIdentity changes when one of the attributes priority1, clockClass, clockAccuracy, offsetScaledLogVariance, and priority2 change, e.g., due to management action, degradation or loss of the ClockSource, etc. The systemIdentity also includes the attribute clockIdentity, but this attribute does not change. Instead, the following normative statement would be added: “The systemIdentity shall change when one of the attributes priority1, clockClass, clockAccuracy, offsetScaledLogVariance, and priority2 change, e.g., due to management action, degradation or loss of the ClockSource, etc. The systemIdentity also includes the attribute clockIdentity, but this attribute does not change. In addition, a PICs would be added.
Impact on existing networks
If the interpretations above are correct, a remedy to eliminate the
erroneous Sync transmissions by a non-grandmaster-capable system would
reduce risk of timing error in a time-aware system.
Originator
Name: | Bob Noseworthy | Email: | ren@iol.unh.edu |
Affiliation: | University of New Hamsphire's InterOperability Lab | ||
Submitted: | 2015-02-26 |