Re: A Question about "Inter Packet Gap and SOP Lane alignment"
Sanjeev,
Thanks for your clarifications. Please allow me to answer your initial
question succinctly:
An LSS message encoded over either XAUI or the 8B/10B PCS has the
general format LDDD. LSS messages are standalone in an Idle stream and
are completely independent of /T/. /T/ is always associated with an EOP
delimiter and has the general format TDDD. Think of LSS messages as
"primitives" rather than "mini-frames".
As for the second part of your question, DIII is not a valid word format
to be passed to/from a 64B/66B CODEC. I guess I don't understand the
context of this part of the question either. Can you please elaborate?
Best Regards,
Rich
--
Sanjeev Mahalawat wrote:
>
> Rich,
>
> >Hopefully, this answers your questions with the exception of the /E/,
> >which I don't understand.
>
> >> I do not see any /E/ after LDDD and I do not see any 64/66B encoding for
> >> DIII also?
>
> My mistake, I meant to say /T/ EoP delimiter not /E/. So I should have said
> "I do not see any /T/ after LDDD and I do not see any 64/66B encoding for
> DIII also?"
>
> Thanks
> -Sanjeev
>
> At 11:49 PM 07/19/2000 -0700, you wrote:
> >
> >Sanjeev,
> >
> >Your questions are very good ones. It's difficult to balance trying to
> >stick to a single issue in a thread without having questions like yours
> >come up. This is especially true when multiple issues are being
> >discussed in this single email thread already as I'm hesitant to address
> >any more. The issue of who inserts and removes LSS information is yet
> >another issue. Since you asked, I'll address it.
> >
> >1) LSS is proposed as a LAN PHY layer transport for management
> >information including Break Link, Remote Fault and SONET compatible
> >OAM&P.
> >
> >2) LSS information is architected to be transported over all LAN PHY
> >interfaces including the XGMII, XAUI, XBI and the medium (did I get all
> >of them?). This means that all encoded interfaces need to be able to
> >encode, decode LSS information.
> >
> >3) Exactly where LSS information is inserted and removed from the PHY is
> >implementation dependent.
> >
> >4) All LSS information for transport is generated by management and not
> >the Physical or Data Link layers. For example, Remote Fault is sensed by
> >management as a fault condition on the incoming link and reported as a
> >message to be transported by LSS on the outgoing link. This is followed
> >by the recognition of the LSS message containing Remote Fault by the
> >remote device and an indication of the Remote Fault report to management
> >entity at the remote device.
> >
> >5) LSS information may be inserted and removed at any LAN PHY sublayer
> >including the Reconciliation Sublayer, XGXS, PCS, PMA and even the PMD.
> >
> >6) All LSS information must be removed from the Idle stream before
> >Idles, in the form of IPG, are passed to the MAC. The obvious "firewall"
> >for LSS information is the Reconciliation sublayer.
> >
> >7) LSS information may be inserted and removed into a LAN PHY link more
> >than once between Ethernet devices in order to manage complex fiber
> >optic cable plants which may include elements such as media converters,
> >wavelength converters, amplifiers, signal regenerators, optical
> >switches, etc.
> >
> >Now... back to your specific question:
> >
> >Let's use the Remote Fault example I started with in bullet item #4
> >above and consider a Serial LAN PHY with XGMII, XAUI and XBI interfaces
> >on both link ends. Lets also introduce the Remote Fault LSS message at
> >the Reconciliation sublayer in Device A. The configuration looks like
> >this and is identical for both Devices A and B:
> >
> >+------+
> >| STA | STA = Station Management
> >+------+ +----+ +----+ +---+ +---+
> >| |===>| |========>| |==>| |-->| |----->
> >| MAC |--->|XGXS| |XGXS| |PMA| |PMD|
> >| RS |<---| | |PCS | | | | |
> >| |<===| |<========| |<==| |<--| |<-----
> >+------+ +----+ +----+ +---+ +---+
> > XGMII XAUI XBI Medium
> > b'01'
> > x'1C,1' K28.1 x'4B52'
> > x'52,0' D18.2 x'52CE' x'14B5252CE0000'
> > x'52,0' D18.2 x'0000'
> > x'CE,0' D14.6 x'0000'
> >
> >
> >The Remote Fault message is shown in its appropriate format at every
> >point along its journey from Device A management to the medium. The RF
> >message is extracted by the RS in Device B and passed to its management
> >entity. For purposes of 64B/66B coding for the Serial PHY PCS I've used
> >the LSS message followed by an /R/ column encoded within one 66B frame.
> >
> >Hopefully, this answers your questions with the exception of the /E/,
> >which I don't understand.
> >
> >Best Regards,
> >Rich
> >
> >--
> >
> >Sanjeev Mahalawat wrote:
> >>
> >> Rich,
> >>
> >> I have couple of questions regarding LSS.
> >> In the absence of XAUI who is going to insert LSS as XAUI is optional, the PMD?
> >> If PMD then why you have shown LDDD coming out of 8B/10B encoder?
> >>
> >> I do not see any /E/ after LDDD and I do not see any 64/66B encoding for
> >> DIII also?
> >>
> >> May be I am missing someting here and you sure could clarify that.
> >>
> >> Thanks
> >> -Sanjeev Mahalawat
> >>
> >> At 05:54 PM 07/19/2000 -0700, you wrote:
> >> >
> >> >Jonathan,
> >> >
> >> >I absolutely agree with you about the advantages of having the same primitive
> >> >link protocol, components, measurement and compliance techniques, etc. be
> >> >applicable to Ethernet, Fibre Channel, InfiniBand, OIF, proprietary backplane,
> >> >etc. applications.
> >> >
> >> >Boaz,
> >> >
> >> >As I pointed out in a prior note on this thread, lane-to-lane deskew CANNOT be
> >> >performed with the SOP column, and therefore, with LSS columns since there the
> >> >spacing of the alignment reference is less than the maximum lane-to-lane skew in
> >> >some environments. The specific environment which breaks your suggestion is 1550
> >> >WDM with its large lane-to-lane skew. Please consider the following:
> >> >
> >> >8B/10B encoded stream at transmitter:
> >> >
> >> >.....KRLRRKRLKSDDDDDDDTKRSDDDDDDDTKRSDDDDDDDTKRLKRRR.....
> >> >.....KRDRRKRDKDDDDDDDDKKRDDDDDDDDKKRDDDDDDDDKKRDKRRR.....
> >> >.....KRDRRKRDKDDDDDDDDKKRDDDDDDDDKKRDDDDDDDDKKRDKRRR.....
> >> >.....KRDRRKRDKDDDDDDDDKKRDDDDDDDDKKRDDDDDDDDKKRDKRRR.....
> >> >
> >> >8B/10B encoded stream at receiver:
> >> >
> >> >KRLRRKRLKSDDDDDDDTKRSDDDDDDDTKRSDDDDDDDTKRLKRRR................
> >> >...........KRDRRKRDKDDDDDDDDKKRDDDDDDDDKKRDDDDDDDDKKRDKRRR.....
> >> >...........KRDRRKRDKDDDDDDDDKKRDDDDDDDDKKRDDDDDDDDKKRDKRRR.....
> >> >..KRDRRKRDKDDDDDDDDKKRDDDDDDDDKKRDDDDDDDDKKRDKRRR..............
> >> >
> >> >My question to you is how the receiver is supposed to align to/deskew if it is
> >> >using either LSS or packet data columns, even consecutive columns? Since the
> >> >receiver starts out with no lane sync and with lanes significantly skewed, what
> >> >is the receivers reference point (i.e. which code-groups in each lane at the
> >> >receiver are related)? Note that the same problem exists in the absence of LSS
> >> >words, rendering LSS an orthogonal issue to lane-to-lane deskew.
> >> >
> >> >The simple and accepted P802.3ae /A/ spacing proposal solves this problem by
> >> >providing a minimum guaranteed /A/ column spacing. This minimum /A/ spacing is
> >> >flexible and can easily accommodate the maximum skew of any proposed PMD. Using
> >> >/A/ columns (extending the spacing to 32 min), the 8B/10B encoded stream at
> >> >receiver would look something like this:
> >> >
> >> >KRLRRARLKSDDDDDDDTKRSDDDDDDDTKRSDDDDDDDTKRLKRAR................
> >> >...........KRDRRARDKDDDDDDDDKKRDDDDDDDDKKRDDDDDDDDKKRDKRAR.....
> >> >...........KRDRRARDKDDDDDDDDKKRDDDDDDDDKKRDDDDDDDDKKRDKRAR.....
> >> >..KRDRRARDKDDDDDDDDKKRDDDDDDDDKKRDDDDDDDDKKRDKRAR..............
> >> >
> >> >Note that there is NO ambiguity as to which code-groups in each lane are related
> >> >(i.e. were simultaneously transmitted) even in the presence of LSS and standard
> >> >minimum size Ethernet packets.
> >> >
> >> >Please tell me if there is a flaw in my logic somewhere because I am anxious fix
> >> >it if there is. I'm also very interested to any simplifications to the P802.3ae
> >> >baseline proposals which work.
> >> >
> >> >Best Regards,
> >> >Rich
> >> >
> >> >--
> >> >
> >> >Jonathan Thatcher wrote:
> >> >>
> >> >> There is one clear reason to me. The magnitude of the quote-benefit-unquote
> >> >> does not overcome the advantage of having common core definitions with Fibre
> >> >> Channel and potentially Infiniband.
> >> >>
> >> >> jt
> >> >>
> >> >> >-----Original Message-----
> >> >> >From: Boaz Shahar [mailto:boazs@xxxxxxxxxxxx]
> >> >> >Sent: Wednesday, July 19, 2000 12:38 AM
> >> >> >To: 'rtaborek@xxxxxxxxxxxxx'; HSSG
> >> >> >Subject: RE: A Question about "Inter Packet Gap and SOP Lane alignment"
> >> >> >
> >> >> >
> >> >> >
> >> >> >Hi,
> >> >> >I agree with Howard: Why do you need to be aligned during the IDLE?
> >> >> >And about the technical problems:
> >> >> >
> >> >> >1.Whats the problem to do alignmenet on the LSS column as well?
> >> >> >And if you want to avoid it:
> >> >> >2.You can avoid Doing alignement on LSS column, and do very
> >> >> >robust scheme a
> >> >> >sfollows:
> >> >> >
> >> >> >Just do alignement on two (Or even three) consequtive Data
> >> >> >columns. Minimal
> >> >> >packet is about 16 data columns.
> >> >> >
> >> >> >Boaz
> >> >> >
> >> >> >
> >> >> >> -----Original Message-----
> >> >> >> From: Rich Taborek [mailto:rtaborek@xxxxxxxxxxxxx]
> >> >> >> Sent: Wednesday, July 19, 2000 2:28 AM
> >> >> >> To: HSSG
> >> >> >> Subject: Re: A Question about "Inter Packet Gap and SOP Lane
> >> >> >> alignment"
> >> >> >>
> >> >> >>
> >> >> >>
> >> >> >> Howard,
> >> >> >>
> >> >> >> I believe that you realize full well that your suggestion is
> >> >> >> a subversive maneuver to derail LSS whose "words" have a
> >> >> >> similar "look and feel" to a Start-of-Packet delimiter.
> >> >> >>
> >> >> >> The format of an LSS word is /K/D/D/D/ where K is a special
> >> >> >> character with the meaning LSS. The format of a
> >> >> >> Start-of-Packet delimiter is anSOP word /K/D/D/D/ where K
> >> >> >> is a special character with the meaning SOP. The same
> >> >> >> general encoded format is defined for transport on the
> >> >> >> XGMII, XAUI, the 8B/10B PCS and the 64B/66B PCS. The reason
> >> >> >> for this format is it allows a single LSS word to carry
> >> >> >> three bytes of data, plenty enough to function as an OAM&P
> >> >> >> transport.
> >> >> >>
> >> >> >> Your proposal to reconsider the use of /A/ for alignment and
> >> >> >> instead perform the alignment on the Idle-to-Data transition
> >> >> >> is not sufficiently robust due to the potential presence of
> >> >> >> LSS words in the Idle stream and insufficient hamming
> >> >> >> distance between the special characters for the various
> >> >> >> interfaces which may be traversed.
> >> >> >>
> >> >> >> Additionally, alternative PMDs such as the 1550 WWDM proposed
> >> >> >> by Mr. Michael Fisk of Luminent and Mr. Fred Mohamadi of
> >> >> >> Broadcom in May in Ottawa may impart significantly more skew
> >> >> >> between lanes than can be handled by the current and simple
> >> >> >> /A/ spacing. The spacing may need to be increased
> >> >> >> significantly for the 50 km 1550 WWDM links proposed in that
> >> >> >> presentation and publicly exhibited at N+I in May by you know
> >> >> >> who. It is a simple matter to increase the /A/ spacing
> >> >> >> since we currently use a simple counter. However, it is not
> >> >> >> possible to use Idle-to-Data transitions as you propose since
> >> >> >> the skew (I'm still trying to assess the exact number) may be
> >> >> >> larger than the minimum Ethernet frame size spacing.
> >> >> >>
> >> >> >> What is it about this "/A/K/R/O/ stuff during IDLE" that is
> >> >> >> getting out of hand? This sounds like more FUD. I still
> >> >> >> haven't heard a valid technical argument against LSS, only
> >> >> >> FUD. I also have not seen any robust counter proposals.
> >> >> >>
> >> >> >> It is true that the current initialization protocol (for
> >> >> >> 8B/10B based links) allows for a link to initialize only
> >> >> >> when a packet occurs. However, I hope that the reader
> >> >> >> recognizes that this will result in needlessly dropped
> >> >> >> packets and that link initialization does not require
> >> >> >> packets. 8B/10B links are continuously signaled whenever the
> >> >> >> link hardware is powered. The continuous signal is Idle.
> >> >> >> The link initializes during Idle and is ready to go when a
> >> >> >> packet arrives. Whenever a packet transfer is requested by the
> >> >> >> MAC, the Idle stream is interrupted. This operation is as simple,
> >> >> >> straightforward and robust as can be.
-------------------------------------------------------
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