With regard to section 12:
12. Management and Signaling Messages
PTP Management messages MAY be used. Any PTP management message
which is sent with the targetPortIdentity.clockIdentity set to all
1s (all clocks) MUST be sent as a multicast message. Management
messages with any other value of for the Clock Identity is
intended for a specific clock and MUST be sent as a unicast
message. Similarly, if any signaling messages are used they
MUST also be sent as unicast messages whenever the message is
intended for a specific clock.
This restriction (not allowing all 1's for unicast management messages) seems
unnecessary and slightly bothersome. A node's portIdentity is as easily
obtainable as its IP address. In fact, the easiest way to determine a node's
portIdentity is to send a management message (any one, really) to the node's
IP, with the targetPortIdentity set to all 1's. The reply reveals the
portIdentity. We have tools that use this trick to identify nodes so that other
management messages may be addressed more properly, either by unicast or
multicast. In particular, we have a test tool that allows an admin to enter
only the IP address and find all the node's information, such as domain,
portState, etc.
Since the query message is unicast, it avoids the messiness of sorting through
dozens, or hundreds, of multicast replies. I suggest that a unicast message,
regardless of the targetPortIdentity is pretty much, by definition, intended
for a specific clock. I would like to see this restriction removed.
Additionally, you only mention a clockIdentity of all 1's. We often use all 1's
for the clockIdentity and all 1's for the portNumber. This allows the node to
respond without the query having prior knowledge of either the clockIdentity or
the portNumber.
Jeffry Dwight
Greyware Automation Products, Inc.
_______________________________________________
TICTOC mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/tictoc
