G
Guest
Guest
Archived from groups: comp.dcom.lans.ethernet (More info?)
Gigabit Ethernet added _asymmetric_ flow control to the previous
(100Mb/s) symmetric version of the 802.3x standard. My concern is
about the related change in the autonegociation protocol for link
configuration.
Let me first take for a moment a purely "mathematical" point of view
about this negociation issue, ignoring compatibility. There are four
possible final link configurations: (-,-) (TX,-) (-,RX) (TX,RX). "TX"
means "I am sending you PAUSE frames and "RX" means "I am listening to
your PAUSE frames".
Being able to propose any *combination* of these four states (for
instance, to say: "I'm OK for (-,-) or (TX,-) and I reject the two others")
require no less than 4 bits, coding one "yes/no?" bit for each state.
An "optimization" to save a bit or two can be to order the proposals:
any proposition for one state implies acceptance of all inferior
states. Then you just have to propose a rank instead of a subset.
Partial orders may also help: for instance you can assume that
any subset implicitely includes the empty (_,_) proposition.
Admit in addition that the TX and RX negociations are independent
of each other, and then only 2 bits would be needed, one for proposing
(TX or -) and one for proposing (RX or -). Add a legacy, symmetric
bit for compatibility and 3 bits as a whole are enough.
----------------
Back to reality, with a legacy SYMmetric bit and _only one_ (why?)
extra ASM_DIR bit, I understand from reading the standard that we have
this (weird?) negociation code, that does not fit any of the schemes
above.
Reading table 3 of Annex 28B in 802.3
<http://standards.ieee.org/getieee802/802.3.html> (part 2)
I understood the following, please correct me if I am wrong.
for (SYM, ASYM) bits:
(0,0) still means:
"let's both do nothing, end of negociation".
(1,0) still means:
"depending on you,
- let's both control each other,
- or do nothing".
NEW!
(0,1) means:
"depending on you,
- I will asymmetrically control YOU,
- or we'll do nothing".
(1,1) means:
"depending on you, we will:
- you will asymmetrically control ME,
- or we will control each other,
- or we'll do nothing
Tabular representation of this code:
proposed states (TX,_) (_,_) (TX,RX) (_,RX)
sent codes
_____
(0,0)
OLD ----------------
(1,0)
_______________
(0,1)
NEW __________________________
(1,1)
Funny quote from here:
<http://www.ieee802.org/3/z/public/presentations/nov1996/RS8023x.pdf>
"One (possibly two?!) additional Auto-Negotiation capability bits
are needed to allow negotiation of symmetrical and asymmetrical flow
control with full backwards compatibility" -- Rich Seifert
I also noticed there is still a free reserved bit in the base page.
This was also discussed here:
<http://www.ieee802.org/3/z/public/minutes/San0197.txt>
but these quick notes do not bring much light.
Another funny thing is that most linux drivers propose free and
independent proposals of TX and RX in autonegociation... I wonder how
they implement it! In practice, I tend to manually configure
everything to avoid this complexity.
Thanks in advance for any explanation/pointer for this negociation
code. In particular from people that were in 802.3z at end of 1996!
Gigabit Ethernet added _asymmetric_ flow control to the previous
(100Mb/s) symmetric version of the 802.3x standard. My concern is
about the related change in the autonegociation protocol for link
configuration.
Let me first take for a moment a purely "mathematical" point of view
about this negociation issue, ignoring compatibility. There are four
possible final link configurations: (-,-) (TX,-) (-,RX) (TX,RX). "TX"
means "I am sending you PAUSE frames and "RX" means "I am listening to
your PAUSE frames".
Being able to propose any *combination* of these four states (for
instance, to say: "I'm OK for (-,-) or (TX,-) and I reject the two others")
require no less than 4 bits, coding one "yes/no?" bit for each state.
An "optimization" to save a bit or two can be to order the proposals:
any proposition for one state implies acceptance of all inferior
states. Then you just have to propose a rank instead of a subset.
Partial orders may also help: for instance you can assume that
any subset implicitely includes the empty (_,_) proposition.
Admit in addition that the TX and RX negociations are independent
of each other, and then only 2 bits would be needed, one for proposing
(TX or -) and one for proposing (RX or -). Add a legacy, symmetric
bit for compatibility and 3 bits as a whole are enough.
----------------
Back to reality, with a legacy SYMmetric bit and _only one_ (why?)
extra ASM_DIR bit, I understand from reading the standard that we have
this (weird?) negociation code, that does not fit any of the schemes
above.
Reading table 3 of Annex 28B in 802.3
<http://standards.ieee.org/getieee802/802.3.html> (part 2)
I understood the following, please correct me if I am wrong.
for (SYM, ASYM) bits:
(0,0) still means:
"let's both do nothing, end of negociation".
(1,0) still means:
"depending on you,
- let's both control each other,
- or do nothing".
NEW!
(0,1) means:
"depending on you,
- I will asymmetrically control YOU,
- or we'll do nothing".
(1,1) means:
"depending on you, we will:
- you will asymmetrically control ME,
- or we will control each other,
- or we'll do nothing
Tabular representation of this code:
proposed states (TX,_) (_,_) (TX,RX) (_,RX)
sent codes
_____
(0,0)
OLD ----------------
(1,0)
_______________
(0,1)
NEW __________________________
(1,1)
Funny quote from here:
<http://www.ieee802.org/3/z/public/presentations/nov1996/RS8023x.pdf>
"One (possibly two?!) additional Auto-Negotiation capability bits
are needed to allow negotiation of symmetrical and asymmetrical flow
control with full backwards compatibility" -- Rich Seifert
I also noticed there is still a free reserved bit in the base page.
This was also discussed here:
<http://www.ieee802.org/3/z/public/minutes/San0197.txt>
but these quick notes do not bring much light.
Another funny thing is that most linux drivers propose free and
independent proposals of TX and RX in autonegociation... I wonder how
they implement it! In practice, I tend to manually configure
everything to avoid this complexity.
Thanks in advance for any explanation/pointer for this negociation
code. In particular from people that were in 802.3z at end of 1996!