Re: Link Status encodings
Pat,
I'll make one modification:
pat_thaler@xxxxxxxxxxx wrote:
>
> Perhaps once the count has reached 3, it should take a longer duration
> without an ordered set to clear the state.
>
Once the count has reached 3, it takes at least 256 columns without
an ordered set or the reception of a different ordered set to clear
the state.
Ben
pat_thaler@xxxxxxxxxxx wrote:
>
> Ben,
>
> By my calculations, at the receiving RS there can be up to 64 columns
> between ordered sets. Take the instance where an RS is sending RF.
>
> The signal can go through
> Node A
> RS - DTE XAUI - PHY XAUI - PCS >>>>>>>
> V
> Node B V
> RS - DTE XAUI - PHY XAUI - PCS <<<<<<<
>
> At Node A's RS, it will start out being transmitted every other column.
> Node A's DTE XAUI will transmit it after each A because it always sees at
> least on occurance of RF between each pair of As. Therefore, RF will be sent
> by the Node A DTE XAUI every 16 to 32 columns.
>
> Node A's PHY XAUI and PCS will send the RF every time that they get one so
> it will still be sent every 16 to 32 columns. The same is true for Node B's
> PCS.
>
> If the PCS's are 10GBASE-R, then Node B's PHY XAUI will be creating AKR with
> its own randomizer. Therefore the following may happen:
>
> Incoming RFs: RF -----32 columns------ RF
> Node B PHY XAUI /A/ and RF: /A/ RF ---30 columns--/A/----32
> columns--/A/RF
>
> Therefore, there may be nearly 64 columns between RFs at the receive RS.
>
> By the way, in researching this, I tried to find out whether As are sent
> with 16 to 32 columns between them or with 15 to 31 columns between them.
> That is ambiguous in clause 48 and should be clarified.
>
> If the PCS is 10GBASE-X and the implementation actually converts to XGMII
> between the PHY XAU and the PCS, then the spacing could be 32 columns more.
> This is a legal though rather unlikely implementation.
>
> Also, it wasn't clear to me from your description that there would be a
> check to see that the three ordered sets received were the same. Such a
> check is necessary to ensure error protection. Of course, there isn't much
> harm in briefly thinking one has gotten RF when one is really getting LF but
> one doesn't want to decode Break Link by mistake.
>
> What I would suggest is that the receiving RS stores an ordered set when it
> receives one. If it gets another ordered set within 100 columns, then it
> checks whether the three data bytes are the same. If they are it counts up.
> If they are not it stores the new value and sets the count back to 1. If
> there is no ordered set for some number of columns such as 128, then it
> clears the stored value and count. If the count reaches 3, then it goes into
> the appropriate state for the received message.
>
> Perhaps once the count has reached 3, it should take a longer duration
> without an ordered set to clear the state.
>
> Pat
>
> -----Original Message-----
> From: Ben Brown [mailto:bbrown@xxxxxxxx]
> Sent: Thursday, November 16, 2000 4:55 AM
> To: 802.3ae
> Subject: Re: Link Status encodings
>
> Rich,
>
> Thanks so much for keeping this issue moving forward.
> Let me pick up the ball a moment and run, if I may.
>
> You mention that
>
> > 3) The choice of data codes need not satisfy any hamming distance
> > requirements if the rule requiring the recognition of 3 successive Pulse
> > Ordered-Sets is observed.
>
> When a XAUI link is used between 2 DTEs, there is no
> guarantee of getting Pulse Ordered-Sets (POS - oh,
> this shouldn't cause too much confusion for all the
> WAN folks :) more often than every 32 columns. This
> is due to the fact that POSs can only follow As and
> As can randomly occur from 16 to 32 columns apart.
> I propose the following for detection methodology at
> the RS:
>
> 1) Detection of LF/RF is true when at least 3 LF/RF
> POSs occur within 96 columns. Reception of the
> RF/LF POS or a packet resets the counter. This
> could also be changed to any data or control
> character other than an LF POS or Idle. Upon
> detection of 3 LF/RF POS, the RS transitions
> to the LF state or RF state. While not in the
> LF or RF states, the RS strips POS and replaces
> them with Idle to the MAC.
>
> 2) While in the LF state, the RS responds by
> sending the RF POS and ignoring MAC data. It
> also sets LINK STATUS = False. It stops sending
> data to the MAC.
>
> 3) While in the RF state, the RS sets LINK
> STATUS = False. It stops sending data to the MAC.
>
> 4) To remain in the LF/RF state, the RS must receive
> at least 1 LF/RF POS every 64 columns. This allows
> for noise to corrupt, at worst, every other LF/RF
> and the RS will remain in this state.
>
> Comments?
>
> Ben
>
> Rich Taborek wrote:
> >
> > Pat,
> >
> > I was actually working on this per request from Ben Brown. I'd like to
> > discuss agreements reached in Tampa followed by proposed criteria for
> > code selections and then should all encodings for all interfaces. Please
> > note that I was developing the /K/D/D/D/ structure "on-the-fly" in Tampa
> > and acknowledge several inconsistencies as you point out. I apologize
> > for the errors.
> >
> > Agreements reached in Tampa from taborek_2_1100:
> > - Leveraging 10GFC Signal Ordered-Set
> > - Same Format As Start Delimiter: /K/D/D/D/
> > - RS Alternates Signal With Idle Continuously
> > - 8b/10b Continuous Signal after every ||A||
> > - Recognized Upon 3 Consecutive Signal Occurrences
> > - 8b/10b, 64b/66B, XGMII, XSBI, SUPI, WIS, etc. Compatibility
> >
> > Proposed criteria for code selection:
> >
> > 1) The proposed protocol neither matches 10GFC Signal nor Sequence
> > protocol. 10GFC Signal is signaled once, at any time during Idle.
> > Sequence is signaled continuously and alternatively with Idle and is
> > mutually exclusive with frame transmission. Therefore, it should be a
> > third Ordered-Set type, I'll call it Pulse for lack of a better name for
> > the moment. Please feel free to submit your choice of name.
> >
> > 2) The choice of value of /K/ should not conflict with values chosen for
> > any other Ordered-Set or the Start Delimiter. This leaves out
> > /K28.7/=Start, /K28.2/=FC Signal and /K28.6/=FC Sequence. To prevent
> > confusion with all other Ordered-Sets used by 10GE, the value of /K/ for
> > Pulse should also not use: /K28.5/=/K/, /K28.0/=/R/, /K28.3/=/A/,
> > /K29.7/=/T/ and /K30.7/=/E/. Please note that the /K28.6/=FC Sequence is
> > new for 10GFC and is a change from the baseline proposal.
> >
> > I'd like to propose /K28.4/ to identify the Pulse Ordered-Set. It's
> > really a toss up between /K28.4/ and /K23.7/. Both codes are balanced,
> > allowing them to be added or removed from a 10-bit stream without
> > affecting the running disparity of the stream (e.g. can replace an /R/
> > if need be). Please note that the same must be true of all data codes
> > code the Pulse Ordered-Set to achieve full functionality. /K28.4/ comes
> > first in the list, so my choice is /K28.4/ and is a code previously
> > reserved for LSS in walker_1_0700.
> >
> > 3) The choice of data codes need not satisfy any hamming distance
> > requirements if the rule requiring the recognition of 3 successive Pulse
> > Ordered-Sets is observed.
> >
> > For data codes, I'd like to be as simple as possible. Given that the
> > Pulse Ordered-Set can be denoted as /K28.6/D2/D2/D3/,
> > I propose the following encodings for D1 through D3:
> >
> > D1 - x'00' --|
> > D2 - x'00' --V-> Fault Message
> > D3 - bits 0-5: Reserved for future use (e.g. bit 5 = Break Link, etc.)
> > bit 6: Remote Fault
> > bit 7: Local Fault
> >
> > Encodings for all interfaces:
> >
> > +----------------------------------------------+
> > | | | | | 64b/66b |
> > | Lane | XGMII | XGMII | 8b/10b or | 10GBASE-R |
> > | ID | T/RXC | T/RXD | 10GBASE-X | x/y |
> > +------+-------+-------+-----------+-----------+
> > | 0 | 1 | 0x9c | K28.4 | 0b0000 |
> > | 1 | 0 | 0x00 | D0.0 | N/A |
> > | 2 | 0 | 0x00 | D0.0 | N/A |
> > | 3 | 0 | 0x0n | Dn.0 | N/A |
> > +----------------------------------------------+
> >
> > Notes:
> >
> > 1) The data value in lane 3 represents all possible encodings of the RF
> > and LF bits. Since these bits are mutually exclusive, the applicable
> > values are 0b00, 0b01 and 0b10.
> >
> > 2) x/y locations are illustrated in walker_1_0700 slide 19. Other values
> > reserved for x/y are as follows:
> > 0b1111 for FC Signal
> > 0b0101 for FC Sequence
> >
> > 3) Complete details on 64b/66b frames associated with Pulse, FC Signal
> > and FC Sequence Ordered-Sets are included in walker_1_0700 slide 19.
> >
> > 4) All encodings are transported transparently trhough the WIS, XSBI and
> > SUPI.
> >
> > --
> >
> > Best Regards,
> > Rich
> >
> > -------------------------------------------------------
> > 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
>
> --
> -----------------------------------------
> Benjamin Brown
> AMCC
> 2 Commerce Park West
> Suite 104
> Bedford NH 03110
> 603-641-9837 - Work
> 603-491-0296 - Cell
> 603-626-7455 - Fax
> 603-798-4115 - Home Office
> bbrown@xxxxxxxx
> -----------------------------------------
--
-----------------------------------------
Benjamin Brown
AMCC
2 Commerce Park West
Suite 104
Bedford NH 03110
603-641-9837 - Work
603-491-0296 - Cell
603-626-7455 - Fax
603-798-4115 - Home Office
bbrown@xxxxxxxx
-----------------------------------------