Re: [HSSG] fault signalling
Mikael (and Stephen and others),
This subject was addressed in great length during 802.3ah.
http://www.ieee802.org/3/ah/index.html
We adopted an objective for Operations and Maintenance:
Support far-end OAM for subscriber access networks:
– Remote Failure Indication
– Remote Loopback
– Link Monitoring
You can see the baseline presentations for this:
http://www.ieee802.org/3/efm/baseline/oambaseline.html
This would cover everything that you have requested. The protocol that
was invented for this project is extensible enough to accommodate any
new PHY characteristics (it had to be to cope with the DSL PHYs). All
that would need to be done in 802.3ba is to add the management objects
for optical monitoring that you suggest and add the codepoints into
802.3ah OAM.
Hugh.
Mikael Abrahamsson wrote:
> On Tue, 18 Sep 2007, Trowbridge, Stephen J (Steve) wrote:
>
> Thanks for your feedback, Stephen.
>
>> Without looking at what it will cost, some of these ideas seem
>> appealing. But Ethernet hasn't historically built in capabilities to
>> support particular operating environments such as the one you describe
>> that would add cost across the board.
>
>
> How do you categorize autoneg in this aspect? Since it actually does
> announce capabilities and also tells somewhat the state of the other
> end, and as far as I understand, resides on the link layer?
>
> If we could include a generic communication link that could send data
> without the link being up, then this could be extended in the future
> by vendors that decide to support it (I do not propose to make optical
> monitoring a requirement in the standard, I propose to make it at all
> possible for a vendor to support it within the standard).
>
> End customers as me are putting DOM (or equivalent optical monitoring)
> into RFQs as "should" requirements for higher end platforms nowadays,
> and if a vendor added the capability I described in earlier email,
> that vendor would definately have a big operational plus in an RFQ
> response due to the operational savings of such capabilities.
>
> It really would sadden me if we missed this opportunity to add a
> communication channel to the standard now that could be used in the
> future for all kinds of communication, perhaps something we can't even
> think of today.
>
> I am an end user, I do not know exactly how to implement this, I'm
> just saying that it would be extremely useful for us to have this
> capability.
>