RE: [RPRWG] 802.17 Outline: Stratum Clock distribution?
Alright,
Here we go for a long one ... :
I understand the PSTN/ISDN networks at both ends (if any) should be synced
(as they are today). This was not my point though. I am concerned about the
possible use of RPR networks to either:
- convey information content emulating/carrying circuit based services (hard
to avoid in the telecom environment for the medium term;
- convey synchronisation information used itself to synchronize remote
clocks (SSU's etc) to a PRC (Primary Reference Clock).
The latter application does not seem critical to me (there are good
aternatives: GPS receivers, other network layers etc).
But about the former I would like to clarufy my point by a comparison with a
non-suspect because "synchronous" technology, SDH:
In the SDH network (despite the S in the name) it is not necessary to
synchronize the SDH engine clocks either. However not doing so degrades the
timing quality of the transported signals considerably (jitter, wander). In
principle this could be corrected at the boundary of the SDH network by
adequate buffering and retiming.
However, the preferred approach (by far) is simply to keep the SDH switching
core in sync with ref. clocks and minimize the accumulation of jitter. This
requires the availability of sync functions to certain standards in the
equipment used. Ref. ITU rec G.813.
Why would this be different with RPR over whatever PHY as technology? Is
there evidence that the timing behaviour of synchronous services carried
over RPR rings would not be adversely affected? Once again: I agree that
there is no genuine sync requirement for the RPR to guarantee the RPR will
work. The question is: will it be good enough to support circuit based
services. If not that would be a seriuous limitation which may jeopardize
its chances for deployment in the telecom environment.
JP.
-----Original Message-----
From: Jeanne.De_Jaegher@xxxxxxxxxx [mailto:Jeanne.De_Jaegher@xxxxxxxxxx]
Sent: 26 November 2001 11:38
To: BURVENICH Jean-Pierre (ANS/NIS)
Subject: RE: [RPRWG] 802.17 Outline: Stratum Clock distribution?
Circuit emulation over a packet technology does not require synchronization
in the packet network.
The two PSTN end networks should be synchronized. There are different ways
of doing this but these are independant of the packet network in between.
Jeanne
"BURVENICH Jean-Pierre (ANS/NIS)" <jean-pierre.burvenich@xxxxxxxxxxx> on
26/11/2001 10:59:38
To: "'Chan, James'" <jchan@xxxxxxxxxxxxxxxxx>
cc: "'stds-802-17@xxxxxxxx'"
<stds-802-17@xxxxxxxx>(bcc: Jeanne DE
JAEGHER/BE/ALCATEL)
Subject: RE: [RPRWG] 802.17 Outline: Stratum Clock
distribution?
I share James' opinion in terms of the requirement. As a telecom operator
person I do not have the same opinion as to the requirement for it to be
part of the standard. If the industry's intention for RPR is to provide a
universal standard useful for telecom purposes I believe operators will
highly value the support of sync requirements. In a standardized way. Sync
requirements heve a tendency to be underestimated in most technology
developments until they are to be deployed in real life.
Though I can at this stage not contribute to the actual content of such
requirement I strongly believe it would be useful to be examined.
JP.
Jean-Pierre Burvenich
Manager Strategy, Architecture and Economics of the Core Network
Belgacom WBU/ANS/NIS
K. Albert II laan 27
B-1030 Brussel
Tel+32 2 202 7001
Fax +32 2 202 7425
Mob +32 477 666 746
EMail jean-pierre.burvenich@xxxxxxxxxxx
-----Original Message-----
From: Chan, James [mailto:jchan@xxxxxxxxxxxxxxxxx]
Sent: 21 November 2001 22:33
To: 'djz@xxxxxxxxxxx'; Jeanne.De_Jaegher@xxxxxxxxxx
Cc:
Subject: RE: [RPRWG] 802.17 Outline: Stratum Clock distribution?
Stratum Clock Distribution to me means ANSI T1.101 Synchronization hierarchy
standard. This is very different to time-of-day clocks. Synchronization is
necessary from PSTN (TDM voice) perspective. It may also be required for a
RPR network supporting circuit emulation services (there may be other ways
to do it without synchronization). However, this is an implementation
specific issue which should not be part of the RPR standard. Individual
vendors may choose to do it as their differentiator.
I was not aware of stratum clock discussion in the last meeting. Can any
else shed some light?
Regards,
James Chan
-----Original Message-----
From: David James [mailto:djz@xxxxxxxxxxx]
Sent: Wednesday, November 21, 2001 10:14 AM
To: Jeanne.De_Jaegher@xxxxxxxxxx
Cc: stds-802-17@xxxxxxxx
Subject: RE: [RPRWG] 802.17 Outline: Stratum Clock distribution?
Jeanne,
Some physical layers have no provisions for accurately
synchronizing time-of-day clocks (GMT like clocks) of
clock slave's to clock masters.
For physical layers without such services, this clause
describes how such time-of-day clocks can be accurately
synchronized by MAC-level services.
From IEEE Std 1394 Serial Bus experiences, as well as
the telecom industry as a whole, the value of synchronous
transfers is greatly increased if time-of-day clocks
can also be synchronized.
DVJ
David V. James, PhD
Chief Architect
Network Processing Solutions
Data Communications Division
Cypress Semiconductor
110 Nortech Parkway
San Jose, CA 95134
Work: +1.408.942.2010
Cell: +1.650.954.6906
Fax: +1.408.942.2099
Work: djz@xxxxxxxxxxx
Base: dvj@xxxxxxxxxxxx
> -----Original Message-----
> From: owner-stds-802-17@xxxxxxxxxxxxxxxxxx
> [mailto:owner-stds-802-17@xxxxxxxxxxxxxxxxxx]On Behalf Of
> Jeanne.De_Jaegher@xxxxxxxxxx
> Sent: Wednesday, November 21, 2001 3:17 AM
> To: stds-802-17@xxxxxxxx
> Subject: [RPRWG] 802.17 Outline: Stratum Clock distribution?
>
>
>
>
>
> Good morning,
>
> Can someone tell me what the section over Stratum Clock
> Distribution covers?
>
>
> Thank's
>
> Jeanne
>
>
>
**** DISCLAIMER ****
"This e-mail and any attachments thereto may contain information
which is confidential and/or protected by intellectual property
rights and are intended for the sole use of the recipient(s) named above.
Any use of the information contained herein (including, but not limited to,
total or partial reproduction, communication or distribution in any form)
by persons other than the designated recipient(s) is prohibited.
If you have received this e-mail in error, please notify the sender either
by telephone or by e-mail and delete the material from any computer.
Thank you for your cooperation."