Re: [HSSG] fault signalling
Mikael,
Just because you can do something doesn't mean you should. This is an
Ethernet interface and shouldn't be attempting to be a SONET interface.
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.
- 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
-----Original Message-----
From: Mikael Abrahamsson [mailto:swmike@SWM.PP.SE]
Sent: Tuesday, September 18, 2007 1:06 AM
To: STDS-802-3-HSSG@LISTSERV.IEEE.ORG
Subject: 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