Re: Link Status encodings
Boaz,
Idle mode is entered whenever any ||I|| (Idle column) is received.
Packet (i.e. data) transmission is aborted at this time. The ||I|| may
be the result of the beginning of fault message signaling, or the
beginning of an Idle sequence following a packet. At the Node A DTE XGXS
a link fault condition is recognized, and Fault mode is entered, after 3
RF Pulse ordered-sets are detected. Data/packet mode is mutually
exclusive with Idle and Fault modes.
Best Regards,
Rich
--
Boaz Shahar wrote:
>
> 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