Re: Please help to clarify some things!
Bill:
I think we are building up a consensus that HSSG needs a WAN PHY (or light
SONET PHY). If you like, you may lead the way to provide us your views of
the requirements. We will appreciate your input.
Regards,
Ed Chang
> > The issue here is the backward computability within LAN campus,
> > or within WAN
> > camps. I cannot think any one good reason that 10xGbE should adapt SONET
> > fault-detection and recovery methods to mess up its own backward
> > compatibility without any gain at all.
>
> I agree. There is too much happening in terms of long range lasers and
> optical out of band management that I think it would be cazy at this stage
> to adopt any type of SONET fault detection, that was originally designed
for
> another set of requirements many years ago.
>
> >
> > I believe we should leave them alone, and concentrate in how to
> > bridge them
> > together in the most efficient way -- a light SONET framer.
>
> If we even need that. I am not convinced why standard ethernet will not
> work on a long haul network.
>
> Bill
>
> >
> > Regards,
> >
> > Ed Chang
> > NetWorth Technologies, Inc.
> > EChang@xxxxxxxxxxxxxxxx
> >
> >
> > > Ed,
> > >
> > > Thanks for the info. I believe what you have said is what I have been
> > > looking for. A good definition of a path between L.A. and N.Y.
> > >
> > > I also noticed a mentioning of the need for tight timing. I
> > agree with you
> > > 100% that for the synchronous traffic such as voice calls, it
> > is absolutely
> > > necessary in the traditional sense. However, when we talk
> > about Ethernet,
> > > that may not be true.
> > >
> > > The Ethernet model requires that each and every repeater have their
own
> > > local clock, which is not adjusted or synchronized with a
> > central clock. So
> > > any variation in length of the fiber between day and night
> > should have no
> > > effect on Ethernet. Ethernet is a packet based protocol, unlike a cell
> > based
> > > one, there is no synchonization requirements between packets
> > on when they
> > > can start or stop.
> > >
> > > I am trying to find out more on why we must have some of the
> > features in
> > > SONET, and what I can use which is already in the data com world.
> > >
> > > So far, I have the conclusion that:
> > >
> > > 1. Failure of link between signal repeaters can be detected by
> > link status,
> > > and remote link status info.
> > >
> > > 2. Failure of link can be recovered by bridging, or some form of link
> > > aggregation protocol.
> > >
> > > 3. A signal repeater is actually intelligent, so it cost will be very
> > > similar to a bridge. (Here I assume that signal repeaters have some
> > > intelligence to monitor the health of links connected. And there is
> > > reporting mechanism build into the repeaters. Correct me if I am
wrong.
> > > Thanks!)
> > >
> > > 4. Use a bridge to replace a singnal repeater. Since the
> > bridge is really
> > > acting as a repeater along the path, minimal buffering may be
required.
> > > Reducing the cost of a bridge implementation.
> > >
> > > 5. The path, which we will call route here, can be managed by routers.
> > >
> > > 6. If all the fibers between to adjacent bridge is broken, Link state
> > > protocol can help to recover total link failure between two
> > routers which
> > > are connected using bridges. Here the bridge can force link
> > failure to the
> > > uplink. Again, the mechanism is there.
> > >
> > > 7. Unless a link is 100% utilized, Slacks in the packet stream
> > can be used
> > > to send out any buffered data in the routers.
> > >
> > > 8. Difference between routing and bridging costs is rapidly narrowing.
> > > Making it possible to use layer 3 switch to replace bridges.
> > >
> > > 9. More fibers are dark rather than lit in the installed base. Thus
> > lighting
> > > them with a less expensive approach may be better off than staying
with
> > > conventional SONET approach. (This is a guess, please correct
> > me if I am
> > > wrong.)
> > >
> > > I hope these conclusions of mind can be used to help people
> > like myself who
> > > does not know enough about WAN but would still like to be able
> > to serve
> > that
> > > market. Or at least as a base to start discussing why we need certain
> > > features currently in SONET but not in Ethernet.
> > >
> > > Really appreciate your reply.
> > >
> > > Henry Ngai