Subject: RE: [TICTOC] "Carrier Class" timing requirement

From: "Sasha Vainshtein" <[email-masked]>
Date: Sun, 8 Apr 2007 09:52:12 +0300

Stewart and all,
Please see inline below.

Regards,
                 Sasha
-----Original Message-----
From: Stewart Bryant [mailto:[email-masked]] 
Sent: Friday, April 06, 2007 1:23 PM
To: Steve Chen
Cc: [email-masked]
Subject: Re: [TICTOC] "Carrier Class" timing requirement

Steve Chen wrote:
> Stuart and Dave,
>
> Sorry I just got to comment on your emails below.
>
> My opinion is that trying to meet "Carrier Class" timing requirement 
> is a noble but difficult goal that we probably will not reach for a 
> while. And is it absolutely necessary? Especially when carriers have 
> already deployed Stratum 1 with Stratum 2 backups all over the place?
>   
I agree that it is a difficult problem, although work by a number of
chip vendors suggests that it is tractable.

The problem with Stratum1/2 sources is that you need to be able to
transfer frequency from the source to the client.
In the past this has been easily achieved through the SONET/SDH/TDM
network, but the move to 
Ethernet creates a gap in coverage. This may to some extent be addressed
by SyncE, but it is by no means 
certain how widely that will be deployed.

[Sasha> I do not think that the problem is created by Ethernet. Please
note that, AFAIK,  an IP/MPLS network
[Sasha> that is built from the routers connected by POS links cannot
transfer frequency in spite of the fact that each 
[Sasha> link is synchronous. This is because the routers (as opposed to
TDM muxes) usually do not have 
[Sasha> a central clock that uses the clock coming from one link (or
from an external clock ) as its source  
[Sasha> and feeds all the synchronous links. Instead, each link uses its
own clock.

... snipped to the end ...

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

---

From: Stewart Bryant <[email-masked]>
Date: Wed, 11 Apr 2007 11:31:01 +0100

> ... snipped to the end ...
Sasha you are correct that the same problem exists on an IP/POS network

- Stewart