Re: [HSSG] fault signalling
Hi, All
for 802.3ah, there mught be somewhat different from 802.3ae RF/LF.
we can see these PHY layer OAM like signaling had been described in 802.3ae.
for the 64/66b block codewode types Table, Ordered_set is for transmit these signals "Remote Fault" and "Local fault" for Link Monitoring at Pisacal layer.
this might be somewhat closer to Mikael's idea.
and I agree with Mikael that we might need to introduce some PHY enhancement for 100GE and even 40GE for supporting pure packet transport over optical bypass OTN and other TDM technologies.
bur in the core of the network, we do not want a per packet base OAM. It was Impossible/ Quite difficult for NP or other ASIC to detect the OAM Packet in one 100Gbps and even greater packet data flow. we would like to treat a total 100GE as a granularity for Operation and grooming.
----- Original Message -----
From: "Hugh Barrass" <hbarrass@CISCO.COM>
To: <STDS-802-3-HSSG@LISTSERV.IEEE.ORG>
Sent: Wednesday, September 19, 2007 12:23 AM
Subject: 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.
>>
>