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