Thread Links Date Links
Thread Prev Thread Next Thread Index Date Prev Date Next Date Index

RE: Link Status encodings




A question:
When the DTE XGXS enters IDLE mode: Is it happens only after recognizing a
link fault condition? (3 times RF) or immediately after the first one? And
in this state: If the RS continue to transmit data, the DTE XGXS stays in
IDLE or transmits the data and only changes the idle pattern so that it
contains POS?
Boaz  

> -----Original Message-----
> From: Rich Taborek [mailto:rtaborek@earthlink.net]
> Sent: Friday, November 24, 2000 12:24 AM
> To: HSSG; Rhett Brikovskis
> Subject: 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@agilent.com 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@amcc.com]
> > 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@amcc.com
> > -----------------------------------------
>                               
> ------------------------------------------------------- 
> 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@nSerial.com
> Santa Clara, CA 95054            http://www.nSerial.com
>