Re: [RPRWG] 802.17 Outline: Stratum Clock distribution?
Somehow, the synchronization issue needs to be addressed in a standardized
and most efficient way. For now, I would suggest leaving the placeholder for
it until it is ultimately resolved. From a standardization perspective,
failure to address the issue may lead to a lack of interoperability across
vendor product offerings. From an efficiency perspective, failure to
properly incorporate the best method may result in a proliferation of more
efficient, incompatible approaches to the issue that, again, diverge across
vendors. If RPR, by virtue of the standard, does not accomodate the *full*
extensions and capabilities of converged services, it may not present itself
as a viable alternative to existing technologies, even though they may offer
these attributes in a less efficient manner overall.
Tim
----- Original Message -----
From: <jean-pierre.burvenich@xxxxxxxxxxx>
To: <Jeanne.De_Jaegher@xxxxxxxxxx>
Cc: <stds-802-17@xxxxxxxx>
Sent: Tuesday, November 27, 2001 7:35 AM
Subject: 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."
>
>
>