RE: Link Status encodings
Some comments:
1) Since packet transmission process and Link Fault event are mutually
exclusive, it may happen that the RF Pulse ordered set (POS) must be
transmitted within a minimum size IPG. Such an IPG is composed of either /K/
or /A/ in the first column, and /R/ in the second. As it stands now, there
is no place for POS there. As a result, the number of packets or time until
the next POS is transmitted is not bounded.
2)A possible solution may be to transmit POS instead of the first /R/. If it
has a neutral disparity it can be removed from the data stream as a result
of clock tolerance
3)Another way is to choose either /A/ or /K/ for the first IPG column using
a Round Robin scheme, so /A/ will appear every second packet and so is the
POS.
4)Yet another way is to say that the MAC/RS layers stop transmission of
packets (i.e. transmit /I/ columns) as soon as LF is detected. This solves
the above case, because the DTX XGXS transmits only IDLE pattern, so that
the distance between two adjacent /A/ (And there fore POS) is bounded.
However, I think that in this case you cannot ay that "packet transmission
process and Link Fault event are mutually exclusive".
Boaz
> -----Original Message-----
> From: Rich Taborek [mailto:rtaborek@earthlink.net]
> Sent: Wednesday, November 29, 2000 9:10 AM
> To: HSSG
> Subject: 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@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
>