Subject: Re: [TICTOC] Proposed charter

From: Stewart Bryant <[email-masked]>
Date: Sat, 01 Dec 2007 10:38:57 +0000

>>
>> On the second reading, I thought of something else.
>> How does Synchronous Ethernet fit into this?
>>
> I think that should fit in nicely given the modular approach. e.g., if 
> the link layer provides something would otherwise have to be emulated, 
> it should "plug in" to the model. At least, that's how I understand it 
> at a very high level. Perhaps someone else here could explain the 
> details better, or if I am way off base.
>>
>> Perhaps if the group wants to deal with it, it could be mentioned as 
>> another form of on-path support.
>>
> Not sure if it has to be mentioned in the charter, but certainly in 
> the framework document.

I think that there is common agreement that if syncE is available it 
should be
used to discipline the local oscillator. It is not how much performance gain
we will get over a pure packet approach, but I have heard numbers in
the range 1 to 1000, so it is well worth doing.

The modularity draft talks about this.

Stewart

_______________________________________________
TICTOC mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/tictoc

---

From: "Yaakov Stein" <[email-masked]>
Date: Mon, 3 Dec 2007 01:00:38 +0200

> another form of on-path support.

Definitely.

In my slides that you will see this week, it is specifically called out
as "on-path" support.

As to how much can be gained by using Sync-E with time distribution
protocols,
I gave a talk on this recently with analytical and simulation results.

Y(J)S

---

From: "FERRANT JEAN-LOUP" <[email-masked]>
Date: Mon, 3 Dec 2007 20:32:22 +0100

Stewart,

I support your idea to use SyncE; as it provides excellent timing it is certainly interesting to see how to take benefit of this. Combining different solutions will certainly help to solve the general problem.

Jean-Loup 

-----Message d'origine-----
De : Stewart Bryant [mailto:[email-masked]] 
Envoyé : samedi 1 décembre 2007 11:39
À : Mark Townsley
Cc : STUART VENTERS; [email-masked]
Objet : Re: [TICTOC] Proposed charter

> Not sure if it has to be mentioned in the charter, but certainly in 

I think that there is common agreement that if syncE is available it should be used to discipline the local oscillator. It is not how much performance gain we will get over a pure packet approach, but I have heard numbers in the range 1 to 1000, so it is well worth doing.

Stewart

---

From: "Sasha Vainshtein" <[email-masked]>
Date: Mon, 10 Dec 2007 16:28:45 +0200

Stuart and all,
If Synchronous Ethernet can be called on-path support, then why not POS?

AFAIK, its physical level (i.e., SONET) provides the same
synchronization capabilities as these of Synchronous Ethernet.
Its great advantage is it has been already widely deployed for quite
some time, and all the relevant (non-IETF) standards are quite stable.
 
On a more serious note, we should be careful with the usage of terms.
"On-path support" sounds well, but different people can easily associate
different things with it. Some of the examples (the list is incomplete)
include:

*	PTP boundary clocks (BC)
*	PTP end-2-end and peer-2-peer transparent clocks (E2E and P2P
TC)
*	Links that admit high-quality clock recovery from their physical
layer (POS, Synchronous Ethernet) etc.

IMHO the framework document should define what does and what does not
qualify as "on-path support" (in addition to the rest of the things that
should be included in this document).
 
My 2c
                  Sasha

________________________________

From: STUART VENTERS [mailto:[email-masked]] 
Sent: Friday, November 30, 2007 6:20 PM
To: [email-masked]
Cc: [email-masked]
Subject: [TICTOC] Proposed charter

Mark, 

Nice job, 

It's unfortunate that there's a second protocol with significant
overlap, but given that it's there, the words seem reasonable.

Regards, 

Stuart

---

From: Stewart Bryant <[email-masked]>
Date: Mon, 10 Dec 2007 14:48:20 +0000

> If Synchronous Ethernet can be called on-path support, then why not POS?
Some systems use POS format with non-synced clocks, but yes - you can
take frequency reference from SONET/SDH.

The emphasis on Ethernet is because that is the way that the Transport
folks are going for new deployments.
> synchronization capabilities as these of Synchronous Ethernet.
I think that is router dependent.
> "On-path support" sounds well, but different people can easily 
> associate different things with it. Some of the examples (the list is 
> incomplete) include:
>
>     * PTP end-2-end and peer-2-peer transparent clocks (E2E and P2P TC)
I agree.
> IMHO the framework document should define what does and what does not qualify as "on-path support" (in addition to the rest of the things that should be included in this document).
>  
Yes we need to develop this concept.

Stewart
> My 2c
>                   Sasha
>
> ------------------------------------------------------------------------
> *From:* STUART VENTERS [mailto:[email-masked]]
> *Sent:* Friday, November 30, 2007 6:20 PM
> *To:* [email-masked]
> *Cc:* [email-masked]
> *Subject:* [TICTOC] Proposed charter
>
> Mark,
>
> Nice job,
>
> ------------------------------------------------------------------------
>

---

From: "STUART VENTERS" <[email-masked]>
Date: Mon, 10 Dec 2007 10:35:28 -0600

Sasha,
 
Good point, a properly timed POS link should be able to provide an initial frequency reference just like Synchronous Ethernet.
  Which highlights that I perhaps muddied the definition of 'on-path'.
 
This points out that we need a clear agreement as to what 'on-path' support means.
  (Since it appears to be affecting what part of the solution space we are searching.)
 
I suspect there is consensus that it:
   Does include boundary and transparent clocks.
   Doesn't include normal packet forwarding afforded to all applications.
 
We need agreement on how to classify:
  Frequency from synchronous PHY's.
  Existing packet delivery services afforded to special applications.
     (For example priority forwarding of timing packets.)
  Special routing rules for timing packets.
  Other stuff as it comes up.
 
I was thinking of on-path support as anything the network does special for timing packets that wouldn't make sense for other applications.
  (Which is too loose to be a useful definition.)
 
You're right, we need a list defining what's in and what's out.

Aside from phy clocks, it seems there are roughly 2 methods of transferring timing with packets on the table.
   1) Hop by hop with precision measuring equipment at each end of each link.  (Perfect packets.)
   2) End to end with precision measuring equipment at each end and depending on statistics. (Lucky packets.)
 
Clearly, on-path was intended to support the 'perfect packet' branch.
   What's the feeling about the 'lucky packet' branch.
 
Should we use 'on-path' to describe things which control the packet arrival statistics supporting the 'lucky packet' branch?
  (Or reserve it for the 'perfect packet' branch.)

Regards,
 
Stuart

-----Original Message-----
From: Sasha Vainshtein [mailto:[email-masked]]
Sent: Monday, December 10, 2007 8:29 AM
To: STUART VENTERS
Cc: [email-masked]; [email-masked]
Subject: RE: [TICTOC] Proposed charter

Stuart and all,
 
AFAIK, its physical level (i.e., SONET) provides the same synchronization capabilities as these of Synchronous Ethernet.
Its great advantage is it has been already widely deployed for quite some time, and all the relevant (non-IETF) standards are quite stable.
 
On a more serious note, we should be careful with the usage of terms. "On-path support" sounds well, but different people can easily associate different things with it. Some of the examples (the list is incomplete) include:

*	Links that admit high-quality clock recovery from their physical layer (POS, Synchronous Ethernet) etc.

My 2c
                  Sasha

  _____  

Mark, 

Nice job, 

It's unfortunate that there's a second protocol with significant overlap, but given that it's there, the words seem reasonable.

On the second reading, I thought of something else. 
How does Synchronous Ethernet fit into this? 
Perhaps if the group wants to deal with it, it could be mentioned as another form of on-path support. 

Regards, 

Stuart

---

From: "FERRANT JEAN-LOUP" <[email-masked]>
Date: Mon, 10 Dec 2007 17:54:32 +0100

All,
 
is there any existing definition of "on-path"?
 
Regards
 
Jean-Loup

De : STUART VENTERS [mailto:[email-masked]] 
Envoyé : lundi 10 décembre 2007 17:35
À : Sasha Vainshtein
Cc : [email-masked]
Objet : RE: [TICTOC] Proposed charter

Sasha,

 

 

 

Regards,
 
Stuart

	-----Original Message-----
	From: Sasha Vainshtein [mailto:[email-masked]]
	Sent: Monday, December 10, 2007 8:29 AM
	To: STUART VENTERS
	Cc: [email-masked]; [email-masked]
	Subject: RE: [TICTOC] Proposed charter

	Stuart and all,

	 
	My 2c
	                  Sasha

	Mark, 

	Nice job, 

	Regards, 

	Stuart

---

From: Stewart Bryant <[email-masked]>
Date: Mon, 10 Dec 2007 17:30:15 +0000

> is there any existing definition of "on-path"?
It's the network links and nodes time packets use between
clock and client.

The services that are provided by these links and nodes
are for us to identify as part of this work.

Stewart

---

From: Kurt Erik Lindqvist <[email-masked]>
Date: Thu, 13 Dec 2007 10:39:27 +0100

> folks are going for new deployments.

I still believe my comment after the meeting that the vast majority of  
IP packets in the world does not travel over Ethernet and won't for a  
long time if ever (at least for the core. Access is a different  
matter). But that is a different discussion. Talking with some real  
world providers over dinner last night, that seems to be a fairly  
shared view at least in the Nordics. But I guess we are special :) I  
know that Stewart / Yaakov made the counter argument that  
manufacturers of basestations where heading for Ethernet interfaces  
and that they therefor wanted sync over Ethernet. That might be true  
but is orthogonal to "emphasis on". From the discussion in Vancouver I  
thought the outcome was that on-path support would be used where  
available. I.e not required, but if other link layers (as it's called  
in the IETF :-) ) would provide on-path support that should be  
supported too.

> I think that is router dependent.

Again, so why not make sure you can use it - where available?

- kurtis -

---

From: "Yaakov Stein" <[email-masked]>
Date: Sun, 16 Dec 2007 07:48:13 +0200

Kurt / Sasha / Stewart

By "on-path" support, we mean any special feature on links or in network
elements along the way
that can be used to improve timing distribution.

This can mean, for example, :
LINK SUPPORT
1) a SyncE link
2) a POS path with frequency available to user
3) a DSL link with NTR

NETWORK ELEMENT SUPPORT
1) a network element with local timing (e.g. GPS, atomic clock)
2) boundary clock
3) a transparent clock

(these are the most common cases, but there are many others).

TICTOC protocols should be able to exploit such on-path support when
they exist, 
but must be able to function (albeit with possibly lower performance)
when they are NOT available.

As Ron has said, in certain cases if on-path support is not available, 
performance may not conform to that needed for specific applications.

As Stewart presented in his slides, TICTOC will need to develop
discovery, selection, and path traversal mechanisms
in order to utilize on-path support when it is available.

Y(J)S

---

From: "Sasha Vainshtein" <[email-masked]>
Date: Sun, 16 Dec 2007 17:41:52 +0200

Yaakov (and all),

It is good to have a list of special features that may qualify as
"on-path support".
At the same time I think that adding ALL of them as "on-path support"
does nor really help.

E.g., consider the case where:
- One of the NEs ("the grandmaster") receives a GPS or an atomic clock
and pushes it as the physical layer clock on all its links
- All the links between the NEs are synchronous (e.g., PoS or SyncE)
- All the NEs transfer the clock received from one of their synchronous
links to all the rest of the links in such a way that the   entire
network is covered by a tree of synchronous links with the grandmaster
as the root.
 
This would mean that the problem of frequency distribution is solved (as
it is in the SONET/SDH networks). But such a solution would be, IMHO,
completely out of scope of the TICTOC WG because it does not deal at all
with the IP/MPLS nature of the network.

So I would like to see a much more narrow definition with the emphasis
on functions that are closely related to the IP/MPLS nature of the
network. 
E.g., 1588v2 boundary clocks would be within the scope of this
definition, while 1588v2 transparent clocks would be within the scope
only complete with a technique that describes how an IP/MPLS router
modifies PTP packets that are not addressed to it.

My 2 c.
                Sasha

-----Original Message-----
From: Yaakov Stein [mailto:[email-masked]] 
Sent: Sunday, December 16, 2007 7:48 AM
To: Kurt Erik Lindqvist; [email-masked]
Cc: STUART VENTERS; [email-masked]; Sasha Vainshtein
Subject: RE: [TICTOC] on-path support (was: Proposed charter)

Kurt / Sasha / Stewart

By "on-path" support, we mean any special feature on links or in network
elements along the way that can be used to improve timing distribution.

NETWORK ELEMENT SUPPORT

TICTOC protocols should be able to exploit such on-path support when
they exist, but must be able to function (albeit with possibly lower
performance) when they are NOT available.

As Stewart presented in his slides, TICTOC will need to develop
discovery, selection, and path traversal mechanisms in order to utilize
on-path support when it is available.

Y(J)S

!DSPAM:4765469c291352044720877!

---

From: "Ron Cohen" <[email-masked]>
Date: Mon, 17 Dec 2007 09:54:40 +0200

Sasha,

I think the scenario you described below, where frequency is delivered
through SyncE or similar synchronous link layer, is within scope and is
a likely deployment scenario when applicable. TICTOC should address many
aspects in this scenario including:

- How to deliver time 
- Sync related signaling / OAM
- Discovery
- Failures etc

TICTOC in my opinion is not about inventing new protocols. It is mostly
about how you build a synchronous-enabled MPLS network taking the
building blocks from SyncE, IEEE1588v2, NTPv4 and marrying it with the
MPLS, BGP, etc protocols. 

Best,
Ron

-----Original Message-----
From: Sasha Vainshtein [mailto:[email-masked]] 
Sent: Sunday, December 16, 2007 5:42 PM
To: Yaakov Stein
Cc: STUART VENTERS; [email-masked]
Subject: RE: [TICTOC] on-path support (was: Proposed charter)

Yaakov (and all),

 

My 2 c.
                Sasha

-----Original Message-----
From: Yaakov Stein [mailto:[email-masked]] 
Sent: Sunday, December 16, 2007 7:48 AM
To: Kurt Erik Lindqvist; [email-masked]
Cc: STUART VENTERS; [email-masked]; Sasha Vainshtein
Subject: RE: [TICTOC] on-path support (was: Proposed charter)

Kurt / Sasha / Stewart

NETWORK ELEMENT SUPPORT

Y(J)S

--
This message was scanned by ESVA and is believed to be clean.
Click here to report this message as spam. 
http://mailgw.resolutenetworks.com/cgi-bin/learn-msg.cgi?id=2F09D27FF1.0
BE5A

---

From: "Sasha Vainshtein" <[email-masked]>
Date: Mon, 17 Dec 2007 10:41:02 +0200

Ron and all,
As you can easily guess, I disagree with you on two counts:
- that the scenario of a synchronized Ethernet network is within the
TICTOC scope
- that this is ever going to happen on a large scale (which is, of
course, no more than a personal belief).

Please see some details inline below.

Regards,
               Sasha

-----Original Message-----
From: Ron Cohen [mailto:[email-masked]] 
Sent: Monday, December 17, 2007 9:55 AM
To: Sasha Vainshtein; Yaakov Stein
Cc: STUART VENTERS; [email-masked]
Subject: RE: [TICTOC] on-path support (was: Proposed charter)

Sasha,

- How to deliver time [Sasha] This may be a valid issue.
- Sync related signaling / OAM [Sasha] Not clear what exactly you mean,
but the basics (like the SSM) is clearly out of scope (it has been
defined by ITU-T already).
- Discovery [Sasha] Of what? 
- Failures etc [Sasha] Already handled by ITU-T G.8262 IMO, no need for
the TICTOC to intervene.

[Sasha] This is not my understanding of the (still somewhat vague)
chapter. IMHO TICTOC is about distributing clock ( in its frequency,
phase,, time of day varieties) over IP/MPLS networks using the
mechanisms that are inherent for these networks (i.e. IP or MPLS
packets)  AND compatible with the normative behavior of the appropriate
routers as defined in the already existing relevant IETF standards
starting from RFC 1122 and RFC 1812, RFC 3031 etc.

This approach allows taking frequency from a synchronous link (or from a
dedicated external clock input port) and using this clock for
timestamping some packets that the router is generating or the packets
that have been received by this router and are addressed to it. But it
explicitly forbids any modification of the payload of the packets that
the router forwards unless these packets are marked with some Router
Alert indication. 

Best,
Ron

-----Original Message-----
From: Sasha Vainshtein [mailto:[email-masked]]
Sent: Sunday, December 16, 2007 5:42 PM
To: Yaakov Stein
Cc: STUART VENTERS; [email-masked]
Subject: RE: [TICTOC] on-path support (was: Proposed charter)

Yaakov (and all),

 

My 2 c.
                Sasha

-----Original Message-----
From: Yaakov Stein [mailto:[email-masked]]
Sent: Sunday, December 16, 2007 7:48 AM
To: Kurt Erik Lindqvist; [email-masked]
Cc: STUART VENTERS; [email-masked]; Sasha Vainshtein
Subject: RE: [TICTOC] on-path support (was: Proposed charter)

Kurt / Sasha / Stewart

NETWORK ELEMENT SUPPORT

Y(J)S

!DSPAM:476635bb85111804284693!

---

From: "Yaakov Stein" <[email-masked]>
Date: Tue, 18 Dec 2007 08:21:28 +0200

Sasha

No-one intended for TICTOC to develop SyncE hardware,
just as no-one intends for it to develop hardware for accurate
timestamping of packets.
However, this does not mean that SyncE is not relevant for TICTOC.

As an example, consider the situation where a network element that
requires timing has several paths to a PRC traceable master,
one of which runs over SyncE links.
One of TICTOC 's responsibilities would be to discover this fact
and to identify the path to the network element.

Furthermore, it has been shown that time distribution protocols
(NTP or 1588) can be made to perform better
(faster convergence times and lower steady state error)
when there is a common frequency reference, 
e.g. provided by SyncE.
Thus, a 1588 profile for cases when SyncE is available
would also be an important work item for TICTOC.

Y(J)S