Link status register mapping (Re: headless chicken)
Rich,
I am now fully convinced that you and I see the same link
startup protocol :-).
Thanks for your precise proposals for management register bit
allocation, while I feel I have no right to discuss its validity
since I am not familiar with the Ethernet tradition.
I see two possibilities for management register bit allocation;
one is preserving 10M - 1Gb/s tradition like your proposal, and
the other is re-design concise register set for 10GbE.
Here I would like to summarize the management register bits related
to the LSS Link Status code. I see little issue with your allocation,
while I feel we had better listen to other proposals as well.
Link Status Advertisement
(LS1) Local Sync Up ReadOnly (Status bit) 4.13 ?
(LS2) Local Break Link ReadWright (Control bit) 0.10 ?
Link Status Advertised by Link Partner
(LS3) Remote Sync Up ReadOnly (Status bit) 1. 4 ?
(LS4) Remote Break Link ReadOnly (Status bit) (5.13 ?)
Duplex Link Up with valid MAC partner = (LS1)&(LS3)¬(LS4)
(LS5) Link Up/Down ReadOnly (Status bit) Latching Down 1. 2 ?
Please find a minor correction and my comments below.
At 14:07 00/06/29 -0700, Rich Taborek wrote:
http://grouper.ieee.org/groups/802/3/10G_study/email/msg02837.html
> 1) Link Status is already defined in clause 22 (table 22-8) as
> Status register bit 1.2. Its definition is:
> 1 = link is up
> 0 = link is down
> Read only; Latching high
This should be Latching LOW; the link down must be notified to MAC.
> I believe that this definition goes way back in Ethernet history.
> For compatibility reasons, I assume that your condition: "Duplex
> Link Up with valid MAC partner" is equivalent to "link is up".
> In general, this bit reflects PHY and not MAC state. I'd like to
> propose that we leave this bit defined as is and not add any
> related bits or sub states. I'd be very happy to listen to proposals
> to augment this bit and state. However, starting out as simple and
> compatible as possible seems to be appropriate.
I am not sure that, in Ethernet history, the Link Status is used for
'Local Sync Up' or 'Duplex Sync Up'. 22.2.4.2.13 Link Status only
describes that 'the link validity is PHY specific'.
My previous note to ADD 'Duplex Link Up with ...' was based on my
assumption that the traditional Link Status corresponds to 'Local
Sync Up'.
> 2) Remote Fault is already defined in clause 22 (table 22-8) as
> Status register bit 1.4. Its definition is:
> 1 = remote fault condition detected
> 0 = no remote fault condition detected
> Read only; Latching high
>
> Your note proposes that Remote Fault indicates "Local Sync Up/Down".
> However, I believe that the Remote Fault Status bit reflects the
> status of the remote end of the link, specifically a fault with the
> remote receiver. In your words, the Status bit corresponds more
> appropriately to "Remote Sync Up/Down". I would propose that we
> leave the current Remote Fault Status bit definition exactly as
> is.
Agreed.
> Your note also proposes an a management register bit advertising
> Remote Fault for signaling by LSS. I agree with this. I propose
> that Register 4, Advertisement, bit 13 be defined as Remote Fault
> as already defined in clause 28 (table 28-2).
No problem, while there will be discussion whether 802.3ae should
follow 10/100 Auto-Negotiation register mapping in Clause 28.
> 3) Break Link is a bit more interesting as I don't see a Control
> register bit already defined that maps exactly to this function.
> The ones that come close are:
>
> 0.15 Reset
> 0.12 Auto-Negotiation Enable
> 0.10 Isolate
> 0.5:0 Reserved
>
> I'd have to agree with you that the best choice seems to be to
> additionally define 0.10 as Break Link for 10GBASE-X.
>
> Your note also proposes an a management register bit advertising
> Break Link for signaling by LSS. I agree with this. I propose
> that a Register 4, Advertisement bit 13 be additionally defined
> as Break Link.
I don't see any requirement to define the Advertising bit if we
define 0.10 as Break Link for 10GBASE-X. Is there any issue if
LSS directly refers to the control bit 0.10 and advertises it?
On the other hand, I want to have a status bit for the Remote Break
Link advertised by the Link Partner. Link Partner ability register
(Register 5) in Clause 28 might be a candidate while this is again
open to discussion.
> This is looking very solid, compatible and simple!
I believe this is the most straightforward PHY protocol for
duplex point-to-point link up/down, while I'd be very happy
to listen to proposals to augment this protocol.
> Best Regards,
> Rich
Best Regards,
Osamu
> --
>
> Osamu ISHIDA wrote:
> http://grouper.ieee.org/groups/802/3/10G_study/email/msg02834.html
> >
> > At 18:54 00/06/27 -0700, Rich Taborek wrote:
> > http://grouper.ieee.org/groups/802/3/10G_study/email/msg02825.html
> > >
> > > Osamu ISHIDA wrote:
> > > http://grouper.ieee.org/groups/802/3/10G_study/email/msg02810.html
> > > >
> > > > Local Device #1 Remote Device #2
> > > >
> > > > MAC MAC
> > > > | STA #1 STA #2 |
> > > > PHY Register Register PHY
> > > > | Local State #1 State |
> > > > | Sync Up/Down --(RemoteFault#1)----> |
> > > > | Isolate ---(BreakLink#1)-----> |
> > > > | Remote State #2 State |
> > > > | <----(RemoteFault#2)-- Sync Up/Down |
> > > > | <-----(BreakLink#2)--- Isolate |
> > > > |_________________________________________________|
> -------------------------------------------------------
> 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
-----------------------------------------
Osamu ISHIDA
NTT Network Innovation Laboratories
TEL +81-468-59-3263 FAX +81-468-55-1282