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



Part of my presentation in Ottawa covered just such a scenario without the need for SONET overhead processing at the PHY.  Please
see "local and remote link failure indication" on page 9 of
Unfortunately, 64B/66B will not support this.  Block coding can not support any of the remote trouble shooting functionality that
service providers are used to have available.  Howard Frazier made a comment to this effect at the Ottawa meeting.  This lack of
functionality is one of the primary reasons that I continue to not support 64B66B.

Thank you,
Roy Bynum

----- Original Message -----
From: "Osamu ISHIDA" <ishida@xxxxxxxxxxxxxxxx>
To: "David Martin" <dwmartin@xxxxxxxxxxxxxxxxxx>; "Pankaj Kumar" <pkumar@xxxxxxxxxx>; <stds-802-3-hssg@xxxxxxxx>
Sent: Saturday, June 10, 2000 2:49 AM
Subject: AIS (RE: WIS OH)

> 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.
> All,
> 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
> problems.
> Best Regards,
> Osamu
> 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
> ---------------------------------------