Re: [HSSG] fault signalling
Mikael-
You need to be careful about the level of complexity that you are asking
for. Each item can e a significant expense. After all, there is only one
important question that has to be answered for a single hop system. That
would be "Do I need to put a repairman at the other end of the link?"
The more important question in that context (when you lose a link) usually
becomes (a) do I need to send a repairman to the far end equipment or do I
need to send a cable crew to find a break and (b) can I tell the difference
between the two without going through the step of sending a technician to
the far equipment?
In my view, it is perfectly reasonable to use test equipment on the fiber
to make determination (b). After all, the link is down so there is no
reason not to move the fiber to a piece of test equipment. If it is a WDM
fiber, then you will hopefully know if the loss is all of the wavelengths
or some subset.
Geoff
At 07:19 AM 9/18/2007 , Mikael Abrahamsson wrote:
>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