Re: Link Status encodings
Pat,
Rhett Brikovskis and I have modified Clause 48 Receive and Transmit
state machines, which are also used by Clause 47 XAUI/XGXS, to support
Link Status reporting. One of the true advantages of combining all of
the 10GBASE-X and XAUI/XGXS receive and transmit protocol in Clause 48
is the inherent simplification realized when multiple instances (of
Clause 48) are employed in a link. This is exactly the situation
applicable to your example which I'll re-illustrate:
Node A
RS (XGMII) DTE XGXS - XAUI - PHY XGXS - 64b/66b PCS >>>>>>>
V
Node B V
RS (XGMII) DTE XGXS - XAUI - PHY XGXS - 64b/66b PCS <<<<<<<
Using your example of the Node A Reconciliation sublayer (RS) sending
Remote Fault (RF), this is what proposed D2.0 Clause 48 state machines
will do:
1) Since Link Fault and Packet transmission is mutually exclusive per
taborek_2_1100.pdf, the Node A RS always alternates RF with Idle;
2) The RF/Idle sequence is passed to the Node A DTE XGXS which utilizes
a Clause 48 Transmit process. The Transmit process enters Idle mode, if
not already in Idle mode, and forwards the RF as normal Data over its
PMA and on to its XAUI. Note that a link fault condition has not been
recognized by the Transmit process at this point;
3) After the detection of three RF indications (columns of
/9C,1/00,0/00,0/02,0/ across the XGMII from the RS), the Clause 48
Transmit process in the Node A DTE XGXS recognizes a link_fault
condition and alters its output to a Pulse sequence. The Pulse sequence
is identical to the Idle Sequence except that the Pulse ordered-set,
||P|| follows every ||A||. The primary distinction of the Pulse protocol
is to keep EMI low while reliably and continuously transporting a single
message easily distinguishable from Idle, in this case, RF. The Pulse
sequence is forwarded by the PCS Transmit process over its associated
PMA and on to its XAUI;
4) The Node A PHY XGXS utilizes a Clause 48 PMA, Synchronization, Deskew
and Receive process. Assuming that the underlying XAUI, associated PMA,
PCS Synchronization and PCS Deskew process is operational, the PCS
Receive process will recognize a link_fault condition after the
detection of three RF indications (columns of /K28.4/D0.0/D0.0/D2.0/
across the XAUI). Upon the recognition of a link_fault condition, the
PCS Receive process forwards an alternating sequence of Pulse and Idle
control columns to its PCS client. In this case, the client of the Node
A PHY XGXS is the 64b/66b PCS;
5) Note that to this point, the Pulse sequences use to convey the RF
indication across the XGMII (or directly between the RS and DTE XGXS in
the absence of an XGMII) and the Pulse sequences over XAUI are
different. The XGMII Pulse sequences over XAUI are necessarily different
to minimize EMI over this typically extended interface. However, there
is no reason to differentiate or further complicate the Pulse sequence
protocol over all interfaces other than XAUI beyond that agreed to in
taborek_2_1100.pdf. Specifically, slide 12 says: "RS Alternates Signal
With Idle Continuously". The same Pulse signaling is applicable to the
XGMII, across 64b/66b, XSBI, SUPI and the WIS. We've been through this
exercise once before with respect to passing XAUI specific codes such as
/A/, /K/ and /R/ over the XGMII. For exactly the same reasons, and for
reasons of keeping the Link Status reporting protocol throughout all
elements of a P802.3ae link, I strongly suggest that all P802.3ae
sublayers and interfaces other than those specified in Clause 48 signal
link fault conditions by continuously alternating Pulse with Idle;
6) Steps 2 through 4 are equivalently applicable to all sublayers and
interfaces in Node B. Note that the direction of the Clause 48 processes
are opposite to that in Node A.
The protocol description should alleviate any concerns with non
deterministic RF indication spacing outlined in your previous note on
this thread.
P.S. Clause 48 ||A|| spacing is not ambiguous and is specified in D1.1
page 148, line 11 as:
e) ||A|| spacing is randomized in the range of 17 columns minimum and 32
columns maximum. A 17 column minimum ||A|| spacing provides an 85-bit
deskew capability;
Best Regards,
Rich
--
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.
>
> -----------------------------------------
> 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
> -----------------------------------------
-------------------------------------------------------
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