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