IEEE-1588-INT-1-10-2009.pdf
《IEEE-1588-INT-1-10-2009.pdf》由会员分享,可在线阅读,更多相关《IEEE-1588-INT-1-10-2009.pdf(11页珍藏版)》请在三一文库上搜索。
1、IEEE Std C57.19.00-2004 IEEE 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
3、 to 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 y
4、our own risk. IEEE Standards Department Copyrights and Permissions 445 Hoes Lane, P. O. Box 1331 Piscataway, New Jersey 08855-1331, USA February 2009 Interpretation Number 1: Topic: Figure 4 - Transport Protocol Subclause: 6.5.4 Interpretation Request #1 In the text just below Figure 4 the standard
5、states: “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 PM Copyright The Institute of Electrical and Electronics Engineer
6、s, Inc. Provided by IHS under license with IEEELicensee=HP Monitoring/1111111164 Not for Resale, 04/08/2009 04:51:09 MDTNo reproduction or networking permitted without license from IHS -,-,- IEEE Std C57.19.00-2004 residence time bridge, shown in Figure 4, measures the residence time of PTP event me
7、ssages (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 correction is based on the difference in the t
8、imestamp 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 address fields as masters source MAC address
9、 (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 essentially terminates the original sync
10、 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-to-end transparent clock forwards all mes
11、sages 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 source MAC address, or not? . Interpretat
12、ion Response #1 PTP 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 modifications of the source protocol address
13、. 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 clock the security association lookup
14、 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. Annex A.9.2 describes the ramifications o
15、f 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 PM Copyright The Institute of Electrical and Electronics Engineers, In
16、c. Provided by IHS under license with IEEELicensee=HP Monitoring/1111111164 Not for Resale, 04/08/2009 04:51:09 MDTNo reproduction or networking permitted without license from IHS -,-,- IEEE Std C57.19.00-2004 suggests that one way to achieve the correct hierarchy is by configuration each port in ad
17、vance 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 are configured with addresses of the neighboring ports, slave-only clocks could po
18、tentially 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 error. We also note that implementations of transparent clocks exist that use unm
19、anaged 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 address is modified, the experimental PTP security extension can not be used, and a
20、utomatic 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 of PTP profiles are encouraged to highlight any non-transparent modifications of
21、 the transport layer fields performed by the transparent clocks designed to the profile. Interpretation Number 2: Topic: clockIdentities and portIdentities Subclause: 7.5.2.4 Interpretation Request #2 The last part of 7.5.2.4 reads: “A portIdentity A of type PortIdentity with attributes clockIdentit
22、y 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 is consistent with the second sentence of http:/standards.ieee.org/reading/
23、ieee/interp/1588-2008.html (3 of 11) 2009/02/27 4:30:42 PM Copyright The Institute of Electrical and Electronics Engineers, Inc. Provided by IHS under license with IEEELicensee=HP Monitoring/1111111164 Not for Resale, 04/08/2009 04:51:09 MDTNo reproduction or networking permitted without license fro
24、m IHS -,-,- IEEE Std C57.19.00-2004 Para 7.5.2.4? Interpretation Response #2 No-IEEE Std 1588-2008 is correct as written. Note that 3 different comparison cases are defined in 7.5.2.4 to cover the possible cases involved in executing the best master clock algorithm on multiport devices. The first ca
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- IEEE 1588 INT 10 2009
链接地址:https://www.31doc.com/p-3770847.html