Re: [HSSG] fault signalling
Steve-
I would agree. I don't consider myself to be an optical expert, but I have
been involved in a significant number of optical standards projects over
the years. The common tread among has seemed to be that everyone agreed
that there should be a signal detect function and that such a function
"should" be easy. When it came down to actually specifying such a function
(in light level, tolerance and duration) it often became one of the most
difficult specifications to develop. and agree upon.
Having said that, signal detect and its round trip cousin, far-end fault,
have proved to be far more valuable diagnostic tools than anything else
over the years, SMOI.
Geoff
At 07:51 AM 9/18/2007 , Trowbridge, Stephen J (Steve) wrote:
>Hi Mikael,
>
>When you use the words "low-level", it makes it sound as though this would
>be simple and cheap. But when I see the kinds of capabilities you are
>proposing, they strike me as follows:
>
>- Transmit and Receive Optical Power measurements
>We had these kinds of things early in the development of SONET and SDH. As
>the technology matured, we removed them from the standards because they
>only added cost to the equipment and weren't well correlated with
>real-world failures or required repair actions. Even in the SONET world,
>these kinds of measurements were only communicated from the NE where the
>measurements were taken to the management system - there was never any far
>end signaling of these kinds of measurements. I worry to see something
>proposed for Ethernet that was considered to be too expensive for SONET
>(and even more extensive than what SONET ever did, if it communicates such
>measurements to the far end).
>
>- Far end fault signaling
>Again, if I look to SONET, SDH and OTN, I see capabilities like RDI and
>AIS (or BDI and FDI more generically). These kinds of signaling
>capabilities indicate the EXISTANCE of an error upstream or downstream,
>but they never attempted to transmit the exact fault condition or alarm
>upstream or downstream. So again, you seem to be proposing that Ethernet
>include OAM capabilities that are in some respects, more extensive and
>more complex than what has been done in service provider network technologies.
>
>Without looking at what it will cost, some of these ideas seem appealing.
>But Ethernet hasn't historically built in capabilities to support
>particular operating environments such as the one you describe that would
>add cost across the board.
>
>Regards,
>Steve
>
>
>
>-----Original Message-----
>From: Mikael Abrahamsson [mailto:swmike@SWM.PP.SE]
>Sent: Tuesday, September 18, 2007 8:19 AM
>To: STDS-802-3-HSSG@LISTSERV.IEEE.ORG
>Subject: Re: [HSSG] fault signalling
>
>On Tue, 18 Sep 2007, Trowbridge, Stephen J (Steve) wrote:
>
> > There are two cases to be considered:
> > - If the service provided to the end customer is a service that runs
> > OVER an Ethernet (e.g., a VLAN, where the Ethernet itself is owned by
> > the service provider), I think you will find all of the OAM you need
> > to support this environment in 802.1ah and other documents such as
> > ITU-T Recommendation Y.1731.
>
>I am not proposing to solve the problem for services run OVER ethernet.
>I'm proposing managament for the link itself. I don't want to introduce
>ethernet frames to do this, I want it solved at the hw-layer without
>even introducing ethernet frames.
>
> > - If the service provide to the end customer is the Ethernet itself
> > (the customer expects a transparent service, for example, over the
> > service provider's OTN network), I think it is extremely unlikely that
>
> > the customer (or certainly ALL customers, which is what you would need
>
> > for a viable application) is willing to allow the service provider to
> > diddle some bits in THEIR Ethernet to maintain links within the
> > service provider network. The customer in this circumstance thinks
> > that every bit belongs to them. This second scenario can only be
> > supported by the service provider operating some server layer network
> > (e.g., OTN) which carries the Ethernet transparently and provides the
> > OAM within the OTN server layer and not the Ethernet client layer.
> > Regards,
> > Steve
>
>This is not what I'm proposing either.
>
>So let's go back to the single hop over dark fiber scenario.
>
>I have remote hands who patch the fibers in the field, and the link
>doesn't come up. I can't reach the other end since it's "on a stick" and
>the current link being turned up is the only (or first) way out.
>
>Now I need to fault-find why it doesn't come up. DOM would give me
>indication on whether I'm seeing light in, but I still don't know the
>status of the remote device, whether it sees my light or not, if it sees
>a little light or no light at all, etc. I don't even know if the patch
>is correctly done as I have no path trace buffer to see the hostname of
>the remote device is.
>
>It would be extremely helpful for the other device to be able to
>communicate back to be some basic information on it's interface, such
>as:
>
>How much light is it sending out (TX) (so I can correlate this with
>amount of light I'm receiving) How much light it's seeing in the RX
>direction.
>Hostname of the device.
>If the light received in makes any sense (framing).
>
>There are of course a lot of other aspects that are of help, these are
>just some examples.
>
>I think it would be a mistake to not insert some kind of low-level way
>of sending information on the link that later could be used for this
>kind of information.
>
>--
>Mikael Abrahamsson email: swmike@swm.pp.se