Thread Links Date Links
Thread Prev Thread Next Thread Index Date Prev Date Next Date Index

Re: [HSSG] fault signalling



On Mon, 17 Sep 2007, Geoff Thompson wrote:

> While such signalling might be a "good idea", we have no expectation of

My thoughts on the subject include to have some mechanism that can 
tell information regarding the other end, such as:

I am not receiving light (amount of light is below for example -40dB).
I am not receiving enough light (below LOS threshold).
I am receiving light but I see you're not (since you're sending the symbol 
for "I'm not receiving light").
My amount of CRC input errors/illegal symbols is too high (BER) the past 5 
seconds.
(and more)

This could could be expanded by also doing terminology such as "end 
device" and "intermediate device" (regen/transponder) doing the same as 
above, and making them propagate this information if they're intermediate 
devices.

Also, would be nice if there were mechanisms for end system (and perhaps 
intermediate device) to propagate how much light it's getting when it's 
below LOS threshold, it's enough that it's accurate to within 5dB.

I am not sure it's a great idea to do all this using symbols, but some 
kind of mechanism (.1x?) should be able to propagate this and aid in fault 
finding. Operationally, even on single hop links it's a great advantage to 
have information on what's going on at the other end when it just doesn't 
work at first try.

I am also a firm believer in that "oneway up" should never be able to 
happen, which today is possible on 1GE and 10GE when one disables autoneg. 
It should be a corner case which should need to be specifically configured 
to ignore "oneway up", and default should be to detect this error and not 
bring up the link (put it should definately propagate this information to 
the user).

Operationally, 10GE today is not very robust and I would definately like 
100GE to offer more functionality in this aspect to make it work better 
for longer reaches where the problems are quite different from datacenter 
operations.

If we use OTU transport, the OTU devices should be able to transmit 
information to us as well, so perhaps a "link to intermediate device" 
state could be implemented as well, where the link is not considered up 
for actual traffic, but it's up enough so we can receive information from 
the transponder device? This would help enormously as operationally the 
transport network is not run by the same (part of) organisation that is 
running the 100GE device.

There is the requirement of very fast failover as well, so propagating 
information should be done at the hardware layer so as so be able to bring 
down link immediately instead of having a hello protocol running on top to 
handle this.

I wouldn't call the above email "structured" as I stated before, but I 
would like to get feedback on my thoughts on how this functionality could 
apply to 100GE.

Thanks in advance.

-- 
Mikael Abrahamsson    email: swmike@swm.pp.se