Subject: [TICTOC] Delay and delay variation as a function of network path computation contribution to ccamp

From: "Greg Dowd" <[email-masked]>
Date: Tue, 9 Nov 2010 21:40:29 -0800

GMPLS extensions to communicate latency as a TE performance metric

                 draft-wang-ccamp-latency-te-metric-01

http://tools.ietf.org/html/draft-wang-ccamp-latency-te-metric-01

Here's a submission defining support for communicating node/path latency
and variation.  This is the type of effort I think we could incorporate
into our discussions of synch network detection/construction.

Any comments?s

---

From: Stewart Bryant <[email-masked]>
Date: Wed, 10 Nov 2010 06:31:43 +0000

This draft, which is being worked on in MPLS (as part of the MPLS-TP 
work programme),  specifies both NTP and 1588 timestamps.

http://tools.ietf.org/html/draft-ietf-mpls-tp-loss-delay-00

It was suggested that I give a heads up on TICTOC  on the requirement to 
include a 1588 mode in support of requirements from the packet transport 
space.

- Stewart

---

From: Al Morton <[email-masked]>
Date: Wed, 10 Nov 2010 01:52:27 -0500

At 12:40 AM 11/10/2010, Greg Dowd wrote:

GMPLS extensions to
communicate latency as a TE performance metric

Here’s a submission defining support for communicating node/path latency
and variation.  This is the type of effort I think we could
incorporate into our discussions of synch network
detection/construction.

Any comments?

Based on a quick look, this requires one-way measurement

and therefore, some degree of synchronization for accuracy.

It would be good to keep the "round-trip" option

completely out of this capability - and specify that
"one-way"

latency must not be derived from arithmetic on a round-trip (RT)

measurement result.  In particular, the delay variation

derived from RT/2 will not be useful, AFAIK.

my 2 cents,

Al