Re: [HSSG] fault signalling
should be:
detect and process OAM Packet
----- Original Message -----
From: "Zhong Qiwen" <zhongqiwen52504@huawei.com>
To: <STDS-802-3-HSSG@LISTSERV.IEEE.ORG>
Sent: Wednesday, September 19, 2007 1:55 AM
Subject: 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 and process 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.
>>>
>>
>