Re: [HSSG] fault signalling
detect and process OAM Packet
----- Original Message -----
From: "Zhong Qiwen" <firstname.lastname@example.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.
>> 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:
>> 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.
>> 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