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@xxxxxxxxxxxxx]
> 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@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
>