Re: Please help to clarify some things!
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
----- Original Message -----
From: <NetWorthTK@xxxxxxx>
To: <hngai@xxxxxxxxxxxx>; <stds-802-3-hssg@xxxxxxxx>
Sent: Tuesday, August 31, 1999 11:04 PM
Subject: Re: Please help to clarify some things!
> Henry:
>
> You are asking Roy questions, not me. I am sure, Roy will respond to your
> question very soon.
>
> However, your question is just the right timing to try minimizing the
> differences of opinions we have at this point. I may not be able to help
> much, but I will try. Again, sorry for jumping on to your ride without
your
> permission.
>
> There are fundamental difference in requirements between LAN and WAN.
>
> Through a switch or a hub, LAN can be treated almost a point-to-point
> connection, and the path from terminal "A" to "B" is mostly fixed and
> predictable, which does not need much of the "path" management.
>
> However, WAN is a long distance connection, of which the connections, for
> example, from terminal "A" in New York to the terminal "B" in Los Angels
are
> different most of time, when each PACKET is sent. The path from terminal
"A"
> in New York to the terminal "B" in Los Angels has unlimited combinations
of
> lines and sections. Depending on the conditions of traffic pattern and
AIS
> (alarming signals) of the lines and sections, the path will select the
> optimum combination of lines and sections to complete its delivery of data
> from "A" to "B." In addition, WAN need a very tight clock tolerance to
deal
> with the difference of the cable lengths in the day time and in the night
> time. We should appreciate WAN people, by implementing SONET and its
> management protocol to handle all these difficulties to keep data flowing.
>
>
> However, LAN is completely different from WAN in the connection issues; as
a
> result, it is not necessary for LAN to consider all these AIS of SONET.
Not
> only that, it is a waste to implement those SONET management protocols in
LAN
> environment.
>
> I believe the key question we are dealing in HSSG is "how to bridge LAN
and
> WAN," or 10 GbE and SONET -- regardless of being our charter or not. The
> logical solution is the "SONET framer." Then it comes the questions of
"how
> much SONET" is needed in the framer?
>
> It seems the consensus is a "Light SONET" as Paul is suggesting, and
limited
> to the "line management protocol" as Roy is claiming. It is clear, at LAN
> side, MAC/PLUS is perfectly OK with Ethernet protocol, which absolutely
does
> not need the interference from SONET -- as the majority of us are saying.
>
> Is HSSD responsible for a Light SONET Framer? It is a good question.
>
> Regards,
>
> Ed Chang
> NetWorth Technologies, Inc.
>
>
>
>
>
>
>
>
>
>
>
>
>
> >
> > Roy,
> >
> > Quite a while back there was some talk on remote link down information
in
> > 802.3. If we can work that into the 10G Ethernet PHY specification,
would
> > that satisfy your requirement? Since we don't use link pulse, may be we
can
> > put in something in the line coding scheme to indicate remote link
status?
> > The original remote link down function basically uses the link pulse to
> > inform the MAC that the up link is failing. Even if ping fails because
of
> > failing optics on the up link, we can still get the link status on the
up
> > link from the other MAC. What do you think?
> >
> > Thanks!
> > Henry Ngai
> >
> > ----- Original Message -----
> > From: Roy Bynum <rabynum@xxxxxxxxxxx>
> > To: <mick@xxxxxxxxxxx>
> > Cc: <stds-802-3-hssg@xxxxxxxx>
> > Sent: Monday, August 30, 1999 8:25 PM
> > Subject: Re: Please help to clarify some things!
> >
> >
> > >
> > > Mick,
> > >
> > > The splice points are just physical joinings of the fiber. The
problem
> is
> > that
> > > they can be inconsistent to the point of effecting the functionality
of
> > the data
> > > transmission. They can also be effected by people messing with them
in
> > the
> > > process of working on the fiber cable. As a cable degrades or is
> damaged
> > the
> > > link level may fail to the point of not being able to use "ping", yet
the
> > remote
> > > status information can inform you of whether the problem is in both
> > directions
> > > of the traffic, or just one, and which one. A ping can not tell you
if
> > the link
> > > failed in one direction only. As a transmission laser starts to fail,
the
> > remote
> > > system returning its receive status information can cause an
allert/trap
> > against
> > > the local system, even though the problem was seen on the remote
system.
> > At
> > > present, SNMP can only tell you if there are excessive error frames.
It
> > does
> > > not have visibility at the optical level. Having a network
management
> > system be
> > > able to properly report where the problem is will save a lot of time,
> > effort,
> > > and expensive support people in the process of resolving the problem.
> > Part of
> > > what I am recommending is adding to SNMP the visibility to the
optical
> > level.
> > >
> > > Thank you,
> > > Roy Bynum
> > > MCI WorldCom
> > >
> > > Mick Seaman wrote:
> > >
> > > > Roy,
> > > >
> > > > I'm sorry, I feel you are repeating "full duplex 10Gb 802.3 is in
need
> > of
> > > > protocol
> > > > level operations support functionality" but not adding to my
> > understanding
> > > > of why at all. I am probably not alone.
> > > >
> > > > Can we be more specific about those things that the functionality
you
> > > > propose will enable us to diagnose that can not be accomplished by
> > > > collecting data in the systems attached to the Gigabit MAC and then
> > sharing
> > > > that data or responding to queries using that MAC to transmit and
> > receive.
> > > >
> > > > Is it possible to see or manage the splice points you refer to
using an
> > > > embedded protocol? I thought they were just physical splice points
and
> > that
> > > > none of the protocols you were discussing contained embedded OTDR.
So
> > the
> > > > only thing that would help me to manage these would be better
insight
> > into
> > > > BER or 'physical' level signal conditioning at the end stations.
Why
> > can't I
> > > > get at the information provided by this using SNMP, or check
> > connectivity
> > > > using 'ping' etc. etc. What is there here that needs support in the
> MAC?
> > It
> > > > may be that the world needs better management protocols but why is
that
> > a
> > > > subject for HSSG discussion?
> > > >
> > > > Mick
> > > >
> > > > From: owner-stds-802-3-hssg@xxxxxxxxxxxxxxxxxx
> > > > [mailto:owner-stds-802-3-hssg@xxxxxxxxxxxxxxxxxx]On Behalf Of Roy
Bynum
> > > > Sent: Sunday, August 29, 1999 10:24 PM
> > > > To: Henry Ngai
> > > > Cc: stds-802-3-hssg@xxxxxxxx
> > > > Subject: Re: Please help to clarify some things!
> > > >
> > > > Henry,
> > > >
> > > > In your document, your first and second drawings are somewhat
correct.
> > I
> > > > doubt
> > > > that 10GbE would ever be implemented as you are showing it in your
> third
> > > > drawing. In your first drawing, you need to add a fiber plant that
has
> > > > things
> > > > like splice points every 5 km at most, access to the fiber cable by
> > people
> > > > that
> > > > have nothing to do with your data, and other issues. The
traditional
> > 802.3
> > > > LAN
> > > > environment was outgrown when full duplex 802.3 over optical
transport
> > was
> > > > standardized. It is even possible to take full duplex 100BaseFX
over
> > WAN
> > > > distances with optical converters that are sold by several
different
> > > > vendors.
> > > > As seen by individuals that are attempting to create manageable
> > enterprise
> > > > level data networks with GbE, full duplex 10Gb 802.3 is in need of
> > protocol
> > > > level operations support functionality in order to grow to its true
> > > > potential.
> > >
> > >
> >
> >
> >
> > ----------------------- Headers --------------------------------
> > Return-Path: <owner-stds-802-3-hssg@xxxxxxxxxxxxxxxxxx>
> > Received: from rly-zc01.mx.aol.com (rly-zc01.mail.aol.com
[172.31.33.1])
> by
> > air-zc02.mail.aol.com (v60.28) with ESMTP; Wed, 01 Sep 1999
00:01:34 -0400
> > Received: from ruebert.ieee.org (ruebert.ieee.org [199.172.136.3]) by
rly-
> > zc01.mx.aol.com (v60.28) with ESMTP; Wed, 01 Sep 1999 00:01:11 -0400
> > Received: by ruebert.ieee.org (8.8.8+Sun/8.8.8)
> > id XAA00738; Tue, 31 Aug 1999 23:54:57 -0400 (EDT)
> > Message-ID: <00e601bef42e$14144be0$d301a8c0@xxxxxxxxxxx>
> > From: "Henry Ngai" <hngai@xxxxxxxxxxxx>
> > To: <stds-802-3-hssg@xxxxxxxx>
> > References: <007201bef30f$b4cb8b90$510c01aa@xxxxxxxxxxx>
> <37CB4B2A.1777482C@
> > airmail.net>
> > Subject: Re: Please help to clarify some things!
> > Date: Tue, 31 Aug 1999 20:57:14 -0700
> > Organization: NEEC
> > MIME-Version: 1.0
> > Content-Type: text/plain;
> > charset="iso-8859-1"
> > Content-Transfer-Encoding: 7bit
> > X-Priority: 3
> > X-MSMail-Priority: Normal
> > X-Mailer: Microsoft Outlook Express 5.00.2314.1300
> > X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300
> > Sender: owner-stds-802-3-hssg@xxxxxxxxxxxxxxxxxx
> > Precedence: bulk
> > X-Resent-To: Multiple Recipients <stds-802-3-hssg@xxxxxxxxxxxxxxxxxx>
> > X-Listname: stds-802-3-hssg
> > X-Info: [Un]Subscribe requests to majordomo@xxxxxxxxxxxxxxxxxx
> > X-Moderator-Address: stds-802-3-hssg-approval@xxxxxxxxxxxxxxxxxx
> >
> >
>