Re: AIS
Rich,
Then why have you been unable to make any presentations that cover remote trouble shooting functionality at the level I have
recommended? Why was the comment made about the inability of GbE to support it made by Howard Frazier at the Ottawa meeting?
I am unable to repeat the comment word for word. The gist of it was that it was proposed and partially attempted, then abandoned in
the P802.3z TF. What the details of that were, he did not go into. I am reading into it that it was so difficult that it was
abandoned as not be worth the effort. Perhaps I am wrong. Perhaps, several people that participated in the P802.3z TF could
enlighten us. I will expect that it will be played down because of the pre-commitment made by several people to block coding before
wide area networking became an issue and an alternative technology was proposed.
Thank you,
Roy Bynum
----- Original Message -----
From: "Rich Taborek" <rtaborek@xxxxxxxxxxxxx>
To: "HSSG" <stds-802-3-hssg@xxxxxxxx>
Sent: Sunday, June 11, 2000 1:03 AM
Subject: 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