I'm new to TICTOC. I've worked on the AVB standards and am working on other
high-performance media networking systems and standards that would benefit
from improvements in clock distribution. I know a lot about Ethernet and IP
but I'm not an MPLS expert. Here's my contribution on the topic of QoS:

 

RFC 4596 specifically recommends using EF for NTP messaging. EF is also
routinely used for VoIP payloads. Ideally we'd want 1588 to take precedence
over both of these but there's no standard service level higher than EF.
Network administrators are free to define custom service levels above EF and
if there's any chance of a warm reception for such a recommendation, I think
it should be made.

 

As allowed by the other DiffServ RFCs and implementation by many vendors,
there's no magic to the DSCP numbers. Best practice is for edge network
devices to ignore incoming DSCP values and re-mark traffic based on
characteristics such as protocol identifier, destination address and port
number. 

 

The DCSP numbers used internally are then enterprise specific. In this
context you can appreciate that a 1588 QoS recommendation can be descriptive
and may not need to conform strictly to RFC 4596 recommendations.

 

1588 prioritization under AVB is largely irrelevant as no PTP packets are
ever bridged so there are never any queuing delays for QoS to address.

 

Kevin Gross

AVA Networks

 

From: [email protected] [mailto:[email protected]] On Behalf Of
Shahram Davari
Sent: Monday, August 08, 2011 11:37 AM
To: Ron Cohen; [email protected]
Subject: 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

Reply via email to