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

Re: AIS




Roy,

Why do you continue to make such wild and false assertions to confuse reflector
readers?

Both block CODECs proposed for 10 GbE, 8B/10B and 64B/66B, are fully capable of
supporting any of the remote troubleshooting functionality that service
providers are used to providing without breaking a sweat.

All we're talking about here is a simple remote fault indication. It appears
that the SONET Line/Path AIS indication is fairly convoluted. However, the WIS
can easily translate it into a simple remote fault indication on the 10 GbE
side.

Do you remember the comment that Mr. Howard Frazier made with respect to this
issue? I don't and I'd be interested in having my memory refreshed. As far as I
know, Mr. Frazier is a staunch supporter of 64B/66B as the PCS and packet
delineation scheme for providing 10 GbE SONET compatibility. 

Best Regards,
Rich
     
--

Roy Bynum wrote:
> 
> Ishida,
> 
> 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 http://grouper.ieee.org/groups/802/3/ae/public/may00/bynum_1_0500.pdf.
> 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:
> > http://grouper.ieee.org/groups/802/3/10G_study/email/msg02643.html
> > >     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:
> > http://grouper.ieee.org/groups/802/3/10G_study/email/msg02640.html
> > > 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:
> > http://grouper.ieee.org/groups/802/3/10G_study/email/msg02636.html
> > > 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