RE: [RPRWG] 802.17 Outline: Stratum Clock distribution?
To RPRWG -
I do not recommend that station clock distribution be included as part of
the RPR standard. Clock distribution can be accomplished in a number of
ways without "cluttering" our RPR effort. Specifically, if network
synchronization is required, an RPR station can derive reference timing from
the underlying SONET/SDH framing if the SONET/SDH PHY is used.
Additionally, an RPR station may use an external timing reference such as
central office BITS clock, local Stratum 1 or equivalent synchronization
source.
This clocking distribution approach is similar to what has been done with
ATM. ATM does not define a new technique for distributing stratum-level
timing references between ATM switches. ATM simply relies on tried and true
methods for synchronizing ATM nodes, when and where required. ATM does
define techniques for deriving timing information from encapsulated circuit
traffic for the purpose of circuit emulation, but these techniques are
separate and independent of the methods used to synchronize the ATM switches
(or multiplexers) themselves. Adaptive clock recovery (ACR) was defined for
recovering timing information for emulated circuit traffic transported over
a non-synchronized ATM network. SRTS was defined for recovering timing
information for emulated circuit traffic transported over a synchronized ATM
network.
RPR encapsulation schemes for circuit emulation that incorporate timing
recovery techniques such as SRTS and ACR may be fair game for future RPR
standardization. However, I suggest we continue to focus on the base RPR
specification for now, leaving circuit emulation for future consideration.
- Bob
++++++++++++++++++++++
Bob Schiff
Lantern Communications, Inc.
211 River Oaks Parkway
San Jose, CA 95134
Phone: 408-521-6810
Mobile: 408-202-9188
http://www.lanterncom.com
-----Original Message-----
From: jean-pierre.burvenich@xxxxxxxxxxx
[mailto:jean-pierre.burvenich@xxxxxxxxxxx]
Sent: Tuesday, November 27, 2001 5:36 AM
To: Jeanne.De_Jaegher@xxxxxxxxxx
Cc: stds-802-17@xxxxxxxx
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."