Re: SV: Break Link and Remote Fault
Krister,
LSS transport on both sides of the 64B/66B PCS is already defined. This
addresses a small portion of the LSS transport. However, if the 64B/66B PCS is
the ONLY LSS transport, how do you then address Break Link and Remote Fault
signaling for LAN WDM links?
I may be out of line, but I fully expect that at least one of the current WDM
proposals will be accepted to fulfill at least one of the multimode HSSG
objectives. Since the logic for both is the same, there is in essence an
objective to signal Break Link and Remote Fault over 8B/10B encoded 4-lane
links. Note also that such signaling is directly applicable to XAUI and the
XGMII. I'll put forth several assumptions:
1) The HSSG multimode cable plant support objectives will be met by one or more
PMDs;
2) Break Link and Remote Fault signaling is considered to be an unwritten
objective for all P802.3ae links including multimode and single-mode;
3) LSS is a PHY transport and does not dictate the PHY sublayer at which LSS
information is inserted and removed from the Idle/IPG. This is an implementation
issue. I have previously proposed that the Reconciliation Sublayer act as a
firewall to guarantee that nothing but Idles are passed to the MAC.
Best Regards,
Rich
--
Krister Frojdh wrote:
>
> Hello Ben
> I propose that one define LSS as a part of the 64B/66B proposal and that the LSS information is added and removed at the 64B/66B codec.
>
> (As PMD guy and not knowing too much about the logic I hope I am excused if this is a stupid proposal or if I have misunderstood something).
>
> As I understand it, space is already reserved for LSS in the 64B/66B proposal and that uses some of the coding space that is made available by this coding. My proposal means that one really not do anything to the interpacket gap more that is already done by the 64B/66B coding.
> As the coding is removed at the 64B/66B decoding this information will not be seen at the XAUI level. Instead the information is transported over MDC/MDIO.
> The 64B/66B coding is used for all situations where I think Break Link and Remote Fault is really critical: all WAN and single mode LAN. The only exception could be if WWDM is adapted and used on single mode. Single mode fiber is however, as I understand it, not the main target for WWDM.
> Another advantage is that the BER-monitoring function that is included in 64B/66B could give input to the status of the link.
> As I see it, the accepted 64B/66B presentation already supports LSS why this could simplify the acceptance of LSS.
>
> A minimal solution would be that the LSS code space in 64B/66B is reserved for a future implementation of LSS and that 64B/66B decoders must accept all this codes and interpret it as a interpacket gap.
>
> Krister Frojdh
> (krister.frojdh@xxxxxxxxxxxxxx)
>
> ----- Original Message -----
> From: Brown, Ben [BAY:NHBED:DS48] <bebrown@xxxxxxxxxxxxxxx>
> To: 802.3ae <stds-802-3-hssg@xxxxxxxx>
> Sent: Saturday, July 15, 2000 5:20 AM
> Subject: Break Link and Remote Fault
>
> >
> >
> > Hi,
> >
> > The LSS proposal was not initially accepted to be part
> > of draft D1.0. The opponents of this proposal felt that
> > this was too complicated a method for reporting Break
> > Link and Remote Fault. Since I've heard many times on
> > this reflector and in the meetings that, if a proposal
> > is going to be shot down a substitute should be made to
> > take its place, I'd like to request just such a substitute.
> >
> > Another thing to remember. According to Jonathan's
> > schedule, this was the "last new proposals" meeting.
> > I'll be interested to hear proposals for break link
> > and remote fault reporting that do not include major
> > new ideas.
> >
> > Thanks,
> > Ben Brown
> > P802.3ae Logic Track Chair
> >
> > --
> > -----------------------------------------
> > Benjamin Brown
> > Router Products Division
> > Nortel Networks
> > 1 Bedford Farms,
> > Kilton Road
> > Bedford, NH 03110
> > 603-629-3027 - Work
> > 603-624-4382 - Fax
> > 603-798-4115 - Home
> > bebrown@xxxxxxxxxxxxxxxxxx
> > -----------------------------------------
-------------------------------------------------------
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