Re: WIS OH
It seems that there are a couple of issues within this thread:
1) SONET "remote fault" indication to an Ethernet PHY;
2) Separate operation of the 10 GbE MAC and PHY;
For issue (1) it seems that the WIS and Ethernet PHY should react as follows:
a) Convert the SONET Line/Path AIS into an Ethernet remote fault indication;
b) Convert the received data into an error indication. This can be done through
the generation of 64B/66B error frames as well as error codes over XAUI and the
I don't recommend disabling the 64B/66B CODEC due to a SONET side fault. Doing
so would compromise fault isolation.
For issue (2) I don't recommend separating the operation of the Ethernet MAC and
PHY. The operational state of the MAC should match that of it's associated PHY.
Device management should coordinate layer operation stated to ensure
consistency. If the PHY goes down, the link, including the MAC should be shut
down. This means that an Ethernet PHY should not remain operational if its
associated MAC, or XAUI, or XGMII is broke.
Osamu ISHIDA wrote:
> Dave, Pankaj,
> Thanks for your information. Yes, that is exactly what I wanted
> to know. I think that these alarming reactions in WIS should also
> be documented in 802.3ae.
> I asked the question since I was not sure whether ELTE on the
> Ethernet side is lit on or not when its SONET side receives
> such AIS signals. Shutting down the light is the simplest
> way to notify the remote fault to WIS, but it prevents WIS
> from localizing the fault location.
> Here I see the similar issue in 40km+ LAN-PHY Link, especially
> when implemented with optional XAUI interface.
> Let me assume that the far-end (remote) PHY is implemented as
> an independent PHY package connected with a MAC/router package
> via backboard XAUI interface.
> Then what happens if the MAC/router package is shutting down or
> broken down? Should the PHY package be shutting down at the
> same time? Or can we design the PHY package to be kept lit on
> and just sending the AIS (Alarm Indication Signal) without
> breaking the Layer-1 connection?
> >From the view point of fiber plant management, I hope that the
> latter implementation, the PHY package beeing kept lit on
> regardless of its valid XAUI connection or not, would be allowed
> in the 802.3ae standard. This helps us to localize the fault
> location; Layer-1 link or far-end MAC. Also Layer-1 link
> performance can be monitored continuously if it is required
> for our SLA.
> However, I am not sure that this implementation is allowable
> or not in 802.3 tradition/standardization. If you see some
> issues in this type of implementation, please let me know the
> Best Regards,
> At 09:34 00/06/09 -0700, Pankaj Kumar wrote:
> > In the WAN PHY, Beside the line AIS ( With K2 byte processing )
> > and path AIS ( Pointer bytes processing ), Other SONET/SDH higher
> > layer ( Section, Line ) alarms like Loss of signal ( LOS), Loss of
> > Sonet/SDH frame etc should Disable the 66/64 Decoder and the Loss
> > of Delineation defect should be detected , Then MAC will discard
> > frame.
> At 09:57 00/06/09 -0400, David Martin wrote:
> > Your description is correct. If you're asking how the WAN PHY
> > will react to Line/Path AIS, the pointer processor will detect
> > AIS-P and the all ones signal will be passed from the WIS up to
> > the 66/64 decoder, which will lose sync (e.g. LOD defect, Loss
> > Of Delineation), then the MAC will see the ReceiveDataValid
> > line inactive & discard frames.
> At 19:24 00/06/09 +0900, Osamu ISHIDA wrote:
> > Could you help me to understand how WAN-PHY and ELTE would react on
> > SONET AIS (Alarm Indicaton Signal)?
> > When we have cable cut in SONET infrastructure, the SONET side of
> > the ELTE will receive either Line-AIS or Path-AIS.
> > Line-AIS: all '1' in Line OH and SPE payload.
> > generated by the regenerator who detect upstream cable cut.
> > detected by the last 3 bits in K2 (at least 3 consecutive '111')
> > Path-AIS: all '1' in AU pointer and SPE payload.
> > generated by LTE who detect upstream cable cut.
> > detected by the all '1' in H1&H2 at least 3 consecutive frames.
> > Thank you,
> > Osamu
> Osamu Ishida,ishida@xxxxxxxxxxxxxxxxxxx
> NTT Network Innovation Laboratories
> TEL:+81-468-59-3263 FAX:+81-468-55-1282
Richard Taborek Sr. Phone: 408-845-6102
Chief Technology Officer Cell: 408-832-3957
nSerial Corporation Fax: 408-845-6114
2500-5 Augustine Dr. mailto:rtaborek@xxxxxxxxxxx
Santa Clara, CA 95054 http://www.nSerial.com