Re: [EFM] Network timing?
Frank & Matt:
You are referring to standards based hybrid networks that support both connection and
connection less services. FDDI II was developed for specific application service
requirements over and above those that could be provided by FDDI but it never used an
802.3 frame structure. There is already an IEEE standard (IEEE802.9a) that utilized
the then existing 802.3 10Base-T MAC and also carried an additional 4 T1's
(6.2Mb/sec) of isochronous stratum clocked payload to each DTE for some of the same
applications and had a separate out of band management channel. This was
accomplished by employing a PHY change with 4B/5B encoding in place of the Manchester
encoding then employed for 802.3 networks. I was at National Semiconductor at that
time and we looked at many different options including using fiber for distances
greater than 100 meters, moving to the then proposed 100Base-T MAC, and using the
IPG for additional bandwidth. Some of our biggest support for the work came from
service providers even though it was dedicated to the customer prem.
Within the EFM Study Group/Task Force we will have to determine what application
services our collective employers wish us to support (even though we are voters as
individuals), and ultimately the applications that the "subscriber" listed in our PAR
title will support with their wallet. We must do this while remaining within the
scope of IEEE802.3. This scope has broadened quite a bit since the 10Base5 days, but
remember there was also a 10Broad36 with quite a different PHY.
Ethernet was developed to support departmental peripherals, then expanded into work
groups then the enterprise, and now into the MAN/WAN. Our Distinct Identity criteria
posits that we are "substantially different from other IEEE 802 standards". We must
clearly define the potential application services requirements within a subscriber
access network, including those for OAM, ensure that they will fit within the
objectives of our PAR, and then decide to what degree we need to make
additions/changes to the 802.3 physical layer specifications to meet those services,
while still staying within our "most attractive cost/performance ratio of any
networking technology" goal. No doubt a serious challenge. As I put forth in my
March presentation, we must employ technology in support of the application
requirements that we will see developing in the subscriber access domain, and not the
other way around.
Sincerely, Richard Brand
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 approach
> 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?
>
> Frank
>
> >
> > 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
> >
> >
begin:vcard
n:Brand;Richard C.
tel;work:408 495 2462
x-mozilla-html:FALSE
org:Advanced Technology Investments;Nortel Networks (408) 495 2462
adr:;;;;;;
version:2.1
email;internet:rbrand@xxxxxxxxxxxxxxxxxx
title:Director, Network Architecture & Applications
fn:Richard C. Brand
end:vcard