1、IEEE Std C57.19.00-2004IEEE Standards Interpretations for IEEE Std 1588 -2008 IEEE Standard for a Precision Clock Synchronization Protocol for Networked Measurement and Control Systems Copyright 2009 by the Institute of Electrical and Electronics Engineers, Inc. Three Park Avenue New York, New York
2、10016-5997 USA All Rights Reserved.This is an interpretation of IEEE Std 1588-2008. Interpretations are issued to explain and clarify the intent of a standard and are not intended to constitute an alteration to the original standard or to supply consulting information. Permission is hereby granted t
3、o 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 you
4、r own risk.IEEE Standards Department Copyrights and Permissions 445 Hoes Lane, P. O. Box 1331 Piscataway, New Jersey 08855-1331, USAFebruary 2009 Interpretation Number 1: Topic: Figure 4 - Transport Protocol Subclause: 6.5.4 Interpretation Request #1In the text just below Figure 4 the standard state
5、s: “The end-to-end transparent clock forwards all messages just as a normal bridge, router, or repeater. However for PTP event messages, the http:/standards.ieee.org/reading/ieee/interp/1588-2008.html (1 of 11) 2009/02/27 4:30:42 PMIEEE Std C57.19.00-2004residence time bridge, shown in Figure 4, mea
6、sures the residence time of PTP event messages (the time the message takes to traverse the transparent clock). These residence times are accumulated in a special field, the correctionField, of the PTP event message or the associated follow up message (Follow_Up or Pdelay_Resp_Follow_Up). This correc
7、tion is based on the difference in the timestamp generated when the event message enters and leaves the transparent clock. Any updates to checksums required by the network protocol are made. The grandmaster sends a sync Ethernet frame to the transparent clock with the Ethernet header source MAC addr
8、ess fields as masters source MAC address (of course). In switch like ours, there is a CPU (and an Ethernet port) within the switch handles PTP messages, and the CPU has its own MAC address. Because TC has to alter the content of the Ethernet frame such as changing correction field and checksums, it
9、essentially terminates the original sync Ethernet frame then generate a new one to send out, so the outgoing sync Ethernet frame will have switchs MAC address as the source MAC address instead of the grandmasters source MAC address. From the excerpt of spec above, it pretty much says like “The end-t
10、o-end transparent clock forwards all messages just as a normal bridge, router, or repeater, except changing correction field and checksum“. A normal bridge or router will not alter an Ethernet frames source MAC address. So my question is: should the transparent clock keep the original grandmasters s
11、ource MAC address, or not?. Interpretation Response #1PTP does not attempt to change the behavior of the transport protocol. Clause 10 defines the processing behavior of transparent clocks and explicitly states the PTP fields that need to be modified by transparent clocks, but is silent about modifi
12、cations of the source protocol address. PTP Annex K defines an experimental security protocol for PTP. Annex K uses the source protocol address as part of the attributes of the security association formed between sender and receiver clocks. If the source protocol address is modified by a transparent
13、 clock the security association lookup described in K.7 fails and the received PTP message would be silently discarded. Annex K K.14.6 describes the processing rules for secure transparent clocks.PTP supports a unicast communication model assuming that the behavior of the protocol is preserved. Anne
14、x A.9.2 describes the ramifications of a unicast model on boundary and transparent clocks. In particular it addresses the issue of formation of the synchronization hierarchy. It http:/standards.ieee.org/reading/ieee/interp/1588-2008.html (2 of 11) 2009/02/27 4:30:42 PMIEEE Std C57.19.00-2004suggests
15、 that one way to achieve the correct hierarchy is by configuration each port in advance with the unicast protocol addresses of the neighboring clocks visible from every port. However in some scenarios it is desirable to automate the discovery of neighboring clocks. For example, if only master ports
16、are configured with addresses of the neighboring ports, slave-only clocks could potentially learn the protocol address of the master clock from the source protocol address of Sync messages. If the source protocol address is modified by transparent clocks this automatic learning process would lead to
17、 error.We also note that implementations of transparent clocks exist that use unmanaged switch technology for which there is no appropriate source address.In summary, PTP does not mandate that transparent clock must not override the source protocol address of PTP messages. If the source protocol add
18、ress is modified, the experimental PTP security extension can not be used, and automatic discovery as detailed above or other similar features (outside the scope of PTP) that assume that transparent clocks are transparent with regards to the protocol addresses must be implemented with care.Writers o
19、f PTP profiles are encouraged to highlight any non-transparent modifications of the transport layer fields performed by the transparent clocks designed to the profile.Interpretation Number 2: Topic: clockIdentities and portIdentities Subclause: 7.5.2.4Interpretation Request #2The last part of 7.5.2.
20、4 reads: “A portIdentity A of type PortIdentity with attributes clockIdentity and portNumber and a clockIdentity B of type ClockIdentity are compared as follows:a. If A.clockIdentity is less than B.clockIdentity, then A B. c. Otherwise, B A.”Question: Should item c) state “Otherwise, A = B”, which i
21、s consistent with the second sentence of http:/standards.ieee.org/reading/ieee/interp/1588-2008.html (3 of 11) 2009/02/27 4:30:42 PMIEEE Std C57.19.00-2004Para 7.5.2.4? Interpretation Response #2No-IEEE Std 1588-2008 is correct as written. Note that 3 different comparison cases are defined in 7.5.2.
22、4 to cover the possible cases involved in executing the best master clock algorithm on multiport devices. The first case is comparing two clockIdentities. The second case is comparing two portIdentities. The third case-and the subject of the question-is comparing a portIdentity with a clockIdentity.
23、 In this case the clockIdentity does NOT have a portNumber field and for purposes of this comparison a zero value for portNumber is assumed (since this will be the case for the usage of this third option). With this assumption the result is BA as stated. Interpretation Number 3: Topic: announceRecei
24、ptTimeout Default Value Subclause: 7.7.3.1 Interpretation Request #3The value of portDS.announceReceiptTimeout shall specify the number of announceInterval that has to pass without receipt of an Announce message before the occurrence of the event ANNOUNCE_RECEIPT_TIMEOUT_EXPIRES; see 9.2.6.11. The r
25、ange shall be 2 to 255 subject to further restrictions of a PTP profile. The minimum value should be 3.Question: Should the last sentence state “The default value should be 3.”, since the previous sentence states that the Announce Receipt Timeout range is 2 to 255?. Interpretation Response #3IEEE St
26、d 1588-2008 is correct. It states a recommended (hence should) minimum value of 3. This is a configurable attribute and the default value is left to be defined in a profile. The profiles in http:/standards.ieee.org/reading/ieee/interp/1588-2008.html (4 of 11) 2009/02/27 4:30:42 PMIEEE Std C57.19.00-
27、2004Annex J define the default value to be 3. Other profiles may select a different value provided it is in the range of 2 to 255. A value of 2 is permitted but is not recommended except in carefully controlled environments where more rapid reaction to missed Announce messages is needed and the numb
28、er of missed messages is very low. Interpretation Number 4: Topic: Initialization Value - defaultDS.priority2 member Subclauses: 8.2.3.8; and 8.2.3.9 Interpretation Request #48.2.3.8 parentDS.grandmasterPriority1 The value of parentDS.grandmasterPriority1 is the priority1 attribute (see 7.6.2.2) of
29、the grandmaster clock. The initialization value shall be the value of the defaultDS.priority1 member. 8.2.3.9 parentDS.grandmasterPriority2 The value of parentDS.grandmasterPriority2 is the priority2 attribute (see 7.6.2.3) of the grandmaster clock The initialization value shall be the value of the
30、parentDS.priority2 member. Question: Should the last sentence of Para 8.2.3.9 state “The initialization value shall be the value of the defaultDS.priority2 member.” so it is consistent with Para 8.2.3.8?. Interpretation Response #4This is clearly a typographical error and the correct statement of 8.
31、2.3.9 should be “The initialization value shall be the value of the defaultDS.priority2 member. http:/standards.ieee.org/reading/ieee/interp/1588-2008.html (5 of 11) 2009/02/27 4:30:42 PMIEEE Std C57.19.00-2004Interpretation Number 5: Topic: logMessageInterval field of an announce message Subclause:
32、 13.3.2.11 Interpretation Request #5 Subclause 13.3.2.11 says that the logMessageInterval field of an announce message must be the value of portDS.logAnnounceInterval. portDS.logAnnounceInterval is the multicast announce period. This seems odd when the message is a unicast announce message which may
33、 have been negotiated to be transmitted with a different period. Is my reading correct? Interpretation Response #5 Subclause 13.3.2.11 says that the logMessageInterval field of an announce message must be the value of portDS.logAnnounceInterval. PortDS.logAnnounceInterval is the log (base 2) of the
34、multicast announce period. It is possible that unicast announce messages are transmitted with a different period; however the text of the standard says that the value of the logMessageInterval field of those (unicast) messages shall equal portDS.logAnnounceInterval, the log of the multicast announce
35、 period. Interpretation Number 6: Topic: PTP-defined static, dynamic, and configurable attributes Subclause: 15.5.1.1.1 Interpretation Request #6 The second paragraph of 15.5.1.1.1 states that “PTP-defined static, dynamic, and configurable attributes“ may not be used with the SET actionField value.
36、However, the previous paragraph states that configurable attributes may indeed be changed with the SET actionField. I suggest that the second paragraph should instead read “PTP-defined static and dynamic attributes.“ Is this correct? http:/standards.ieee.org/reading/ieee/interp/1588-2008.html (6 of
37、11) 2009/02/27 4:30:42 PMIEEE Std C57.19.00-2004Interpretation Response #6IEEE Std 1588-2008 appears to be in error as noted. The correction suggested is “PTP-defined static, and unless otherwise noted in the standard, dynamic attributes.” The caveat is needed since there are some attributes that ar
38、e configurable or dynamic depending on the implementation, for example those in the time properties data set depending on whether the attributes are designed to be set automatically via a GPS link, i.e. dynamic, or by management messages, i.e. configurable. Interpretation Number 7: Topic:Version 2 c
39、lock response to NULL management message Subclause: 15.5.3.1.1 Interpretation Request #7 Are version two clocks required to respond to a null management message? In my opinion, if the actionField is COMMAND, the answer is yes and ACKNOWLEDGE message should be returned. It is a bit ambiguous for the
40、case where the actionField is SET or GET because there is no data involved. Interpretation Response #7NULL management messages can have a legal value of actionField of GET, SET, or COMMAND. Hence the rules of table 38 apply. In the case of GET and SET, the structure of the management message has a l
41、engthField of 0 indicating that the dataField is of zero length. Therefore, the TLV returned in response to a NULL with GET or SET should be this same TLV with lengthField of 0. http:/standards.ieee.org/reading/ieee/interp/1588-2008.html (7 of 11) 2009/02/27 4:30:42 PMIEEE Std C57.19.00-2004Interpre
42、tation Number 8: Topic: Clock Description Subclause: 15.5.3.1.2 Interpretation Request #8Subclause 15.5.3.1.2.1 establishes the clockType field as an array of 16 Boolean values. Values at indices 0-4 represent the presence or absence of various clock types in a node, and the remaining values are res
43、erved. Per 5.4.3, arrays of primitive types (such as Boolean) are “formatted with the member having the lowest numerical index closest to the start of the protocol data unit.“ This seems to indicate that the 5 bits closest to the front of the PDU would be those used for clockType data, and that the
44、remainder would be reserved. I have encountered multiple implementations, however, that use the 5 bits farthest from the start of the PDU as the data bits, leaving the 11 bits closest to the front of the PDU reserved. Which interpretation of 15.5.3.1.2.1 is correct?Interpretation Response #8 The dat
45、a type of the clockType field is Boolean16. The bit corresponding to array index 0, which from Table 42 indicates whether the clock is an ordinary clock, occupies bit position 7 of the first octet in the CLOCK_DESCRIPTION management TLV data field. The remaining bits defined in Table 42 occupy bit p
46、ositions 6, 5, 4, and 3 corresponding to the descriptions for boundary clock, peer-to-peer transparent clock, end-to-end transparent clock, and management node respectively. The reserved indices from Table 42 correspond to bit positions 2, 1, and 0 in the first octet and bit positions 7 through 0 in
47、 the second octet. To illustrate, for an ordinary clock, which from Table 42 corresponds to Boolean array index 0, a portion of Table 41 is reproduced below with the clockType field (the first two octets) expanded to show the position of the bit indicating that the device is an ordinary clock. Table
48、 41CLOCK_DESCRIPTION management TLV data field Bits Octets TLV data offset7 6 5 4 3 2 1 0http:/standards.ieee.org/reading/ieee/interp/1588-2008.html (8 of 11) 2009/02/27 4:30:42 PMIEEE Std C57.19.00-20041 0 0 0 0 0 0 0 2 00 0 0 0 0 0 0 0 1physicalLayerProtocol L 2-remainder of fields not shown It is
49、 recommended that in the next revision of IEEE Std 1588, that the definition of clockType be rewritten, without changing the positions or meanings of the bits, in the same style as used in defining the flagField, see 13.3.2.6. Interpretation Number 9: Topic: displayData field Subclause: 15.5.4.1.6 Interpretation Request #9Subclause 15.5.4.1.6 states that the displayData field “is an optional text field.“ Does this mean that the displayData field can be elided entirely, or that the lengthField of the PTPText field would be set to 0 a
