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

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