Thread Links Date Links
Thread Prev Thread Next Thread Index Date Prev Date Next Date Index

Re: [EFM] Network timing?


One of the interesting side features of a "side band" type of OAM, is the 
simplistic ability to support "network timing" if the service requires 
it.  Personally, I do not think that E1/T1 interfaces at the CPE Demark 
will be much of an issue.  There is already a simple standard for mapping 
Ethernet frames into T1/E1 payloads, ITU X.86.

Thank you,
Roy Bynum

At 08:10 AM 9/26/01 +0000, Frank Coluccio wrote:

>Hi Mathhew,
>It sounds like you're desribing a variant of FDDI II's  "guaranteed" T1
>capabilities, or some form of T1 emulation _a_la_ ATM. I've discussed this
>possibility with others here in the past. At what "super rate" (minimum entry
>level) of Ethernet would you propose, first, before such an isochronous 
>should be considered? [Or, should it be considered at all?]
>In 10 Mb/s or lower, I don't think so. At 100 Mb/s or higher, a 
>possibility, imo.
>What say?
> >
> > Hi EFMers,
> >
> > I guess this is a question for the service providers out there. 
> Imagining an
> > EFM ONU supporting bearer emulation (say, in order to provide E1/T1 
> interfaces
> > for connection to a legacy PABX), is there any interest in having the OLT
> > propagate network timing (usually 8kHz, traceable back to some 
> reference) to
> > the ONUs by some method?
> >
> > Propagation of network timing is allowed for in the xDSL standards.
> >
> > Should we require propagation of network timing in EFM it could be 
> propagated
> > by either the Ethernet symbol rate itself or via some coding method. Some
> > physical layer schemes (ATM25 comes to mind) use a low spec oscillator 
> for the
> > line rate and insert special line tokens at 8kHz to allow user side 
> equipment
> > to recover network timing if required. It would be possible to use one 
> of the
> > non-data 8B/10B tokens as a timing marker and send at 8kHz, 
> alternatively if
> > there is an OAM block it could be sent at 8kHz rate.
> >
> > Best Regards,
> >
> > Matt
> >
> > Matt Beanland, Project Manager/Principal Architect
> > Telecommunications Research and Development, Fujitsu Australia Ltd
> > 5 Lakeside Drive, Burwood East 3151, Victoria, Australia
> > e-mail: matthew.beanland@xxxxxxxxxxxxxx         Phone: (613) 9845 4313
> >
> >