Thread Links Date Links
Thread Prev Thread Next Thread Index Date Prev Date Next Date Index

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)&not(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