Re: A Question about "Inter Packet Gap and SOP Lane alignment"
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.
> >> >>
> >> >> Howard Frazier wrote:
> >> >> >
> >> >> > Maybe we should reconsider the use of /A/ for alignment. We don't
> >> >> > really need to use a special character for lane alignment.
> >> > We could
> >> >> > just as well perform the alignment on the IDLE->DATA transition at
> >> >> > the start of each packet.
> >> >> >
> >> >> > All of this /A/K/R/O/ stuff during IDLE is getting out of hand.
> >> >> > We would be better off with simpler rules for IDLE, like a
> >> >> randomized
> >> >> > sequence of Ks and Rs.
> >> >> >
> >> >> > In fact, if we did the alignment based on the transition from
> >> >> > lane[0:3]=IDLE to (lane[0]=SOP & lane[1:3]=data), then we wouldn't
> >> >> > need to maintain columns of Ks and Rs during IDLE. We
> >> >> would just need
> >> >> > to send a complete column of R once during IPG, for
> >> >instance, on the
> >> >> > column immediately following the T. IDLE could be random
> >> >per-lane Ks
> >> >> > and Rs at all other times.
> >> >> >
> >> >> > The IDLE insert/delete rules would remain unchanged.
> >> >> >
> >> >> > We don't really need to be aligned until there is a packet
> >> >> to receive,
> >> >> > and the first packet that a receiver gets can be used to
> >> >> establish the
> >> >> > lane alignment. If a receiver looses alignment, it will
> >> >re-establish
> >> >> > the alignment at the next start of packet.
> >> >> >
> >> >> > Howard Frazier
> >> >> > Cisco Systems, Inc.
-------------------------------------------------------
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