Shahram, There are many factors introduce PDV noise which has a significant impact on the synchronization performance , except the priority of PTP messages. I think the PDV metrics should be considered in PTP LSP Setup,Protection and Redundancy . That is, except for TC-capability and the priority of PTP messages, the capability of reserving bandwidth should be considered in PTP LSP Setup, because some of the network nodes don’t support the capability of reserving bandwidth due to the complexity of implementation and the cost of HW.
In addition,it is possible that a more efficient path for the PTP becomes available, for example, the deployment of new 1588-aware LSRs, and so on. In order to improve the synchronization performance, the head-end re-route the PTP onto the new path. Since an occasional connection failure is insignificant to the synchronization performance. However, the PDV noise by the packet timing signal as it traverses the network from the 1588 Master to the 1588 Slave is critical to the synchronization performance.So, it is reasonable to recover the synchronization application based on the PDV metrics. I would like to hear any suggestions from you and everybody. Thanks. Best Regards Junhui "Shahram Davari" <[email protected]> 发件人: [email protected] 2011-08-09 01:37 收件人 "Ron Cohen" <[email protected]>, "[email protected]" <[email protected]> 抄送 主题 Re: [TICTOC] DSCP for PTP Ron, I agree with you that all PTP messages must configured with highest priority (a.k.a EF PHB) and EF should be the default. In fact I would also think it is best to use L-LSP with EF PHB for 15880MPLS. If this is acceptable by the group then we could add this to the 1588oMPLS draft. Regards, Shahram From: [email protected] [mailto:[email protected]] On Behalf Of Ron Cohen Sent: Sunday, August 07, 2011 1:00 AM To: [email protected] Subject: [TICTOC] DSCP for PTP Hi, Current standards do not recommend which DSCP values to set on PTP messages. As a result vendors have chosen different default values, and some vendors also differentiate between the DSCP set on PTP Event messages (Sync, Delay_Req, etc.) and PTP General messages (Announce, Follow_Up, Delay_Resp). I think TICTOC can help clarify the recommended DSCP usage, along the guidelines of RFC4595, 'Configuration Guidelines for DiffServ Service Classes'. In my opinion classifying PTP event and general messages into separate PHBs is problematic as discard of Follow_Up would render its associated Sync message useless. Forwarding of Sync messages in a higher priority queue compared to Follow_Up may lead to Sync message getting ahead of the previous Follow_Up message which again causes the slave to discard the previous Sync message. Hence the first order recommendation in my opinion should be to use the same PHB (and DSCP marking) to all PTP messages. Choosing one of the existing PHBs as the recommended one for PTP is somewhat harder. EF is a reasonable choice in my opinion, as per RFC4595 'The intent of Expedited Forwarding PHB [RFC3246] is to provide a building block for low-loss, low-delay, and low-jitter services.' TICTOC could in principle recommend defining a new PHB tailored for PTP and similar services, but I guess this would be a longer process. I would appreciate if others will share their insight on the recommended usage and whether this issue should or should not be addressed by TICTOC. Here is the relevant text from IEEE1588-2008 Annex D: "For PTP event messages, the value of the differentiated service (DS) field in the Type of Service (ToS) field should be set to the highest traffic class selector codepoint available." The PTP Telecom profile for frequency distribution, ITU-T G.8265.1, doesn't specify or recommend DSCP settings. Best, Ron_______________________________________________ TICTOC mailing list [email protected] https://www.ietf.org/mailman/listinfo/tictoc -------------------------------------------------------- ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others. This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender. This message has been scanned for viruses and Spam by ZTE Anti-Spam system.
_______________________________________________ TICTOC mailing list [email protected] https://www.ietf.org/mailman/listinfo/tictoc
