Re: [HSSG] fault signalling
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