Thread Links Date Links
Thread Prev Thread Next Thread Index Date Prev Date Next Date Index

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.
>>>
>>
>