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
>
>