Re: Please help to clarify some things!
Henry:
We are all learning each other among us of diversified expertise, which is a
great benefit to be a HSSG member.
I agree that LAN uses local clocks in repeaters, which simplify the clock
issues -- an advantage to be more cost-effective.
I agree that Ethernet has its own fault detection and recovery mechanisms
serving well to keep data flowing without any deficiency. Of course, WAN
people also claim that SONET Assise information severed WAN very well to keep
data flowing without any deficiency. Both camps achieved the similar goals
with different approaches. They are distinctly different due to their
differences in the implementation requirements.
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 believe we should leave them alone, and concentrate in how to bridge them
together in the most efficient way -- a light SONET framer.
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
>