RE: Link Status encodings
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
-----------------------------------------