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

Re: headless chicken





Corrections to Rich's corrections to Osamu's proposal:

>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 is incorrect.  Bit 1.2 is clearly defined as a latching low (LL) bit.
See table 22-8 of IEEE Std 802.3-1998 edition.

>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.

This does reflect the state of the Physical link.  The MAC has no up/down
state, because the MAC receives bit by bit and transmits bit by bit to
the Physical layer.  There is no concept of link up/down at the MAC.

>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.

Remote fault indicates that a problem has been DETECTED by the remote
receiver.  The fault could occur at the Local Transmitter, the interconnecting
channel, or the Remote Receiver.

>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.

Break Link = Reset.  You send Break Link when everything has gone south and
your only recourse is to Reset and try again from square zero.  You send
Break Link to let the remote end know that you have pushed the reset button,
and the remote end should do the same.

Let's banish all of the AN related bits from our
thoughts, and never mention them again.  Isolate has nothing to do with
the behavior at the MDI.  Don't overload this bit with new meaning.
All that Isolate does is to invoke electrical isolation from the XGMII.

>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.
>
>4) I agree that both RF and BL can be signaled simultaneously. My point about
>priority is that a recipient of an LSS message indication both RF and BL should
>Break the Link rather than report Remote Fault and remain in operation. Perhaps
>this is too obvious and need not be stated.

There is no AN in 10 GigE, so there is no need to implement ANY of the
AN bits or registers in 10 GigE. 

>This is looking very solid, compatible and simple!

This is looking like anything but a solid, compatible and simple scheme.
Indeed, it is looking more like AutoNegotiation every day.

We need two and exactly two primitives:  Remote Fault, and Break Link.
These primitives WILL NOT be sent during normal data transfer, so there
is no need to use a signaling mechanism that slips them into the IPG.
These primitives indicate the occurrence of serious problems which 
totally preclude data exchange.  They should be low-level, continuous
signals.

I propose that we use K28.7 across all four XAUI lanes to signal Break
Link in 8B/10B land, and map this into a control frame in 64B/66B
land.  This is a simple, readily recognizable code.

Break Link is sent for time T (~10 mS) following reset.

The response to receipt of Break Link is to set the link status to
down, and reset the link synchronization state machine and deskew logic.

I propose that we use K28.1 across all four XAUI lanes to signal Remote
Fault in 8B/10B land, and map this into a control frame in 64B/66B
land.  This is a simple, readily recognizable code.

Remote Fault is sent whenever the Local Receiver status is not
rx_in_sync.  For XAUI I see this as a combination of:

   rx_in_sync = signal_detect & pll_lock & lane_rx_in_sync[0:3]

Starting from reset, the sequence is:

      RESET -> Send Break Link for T ~= 10 mS
        |
        V
   WAIT_FOR_SYNC -> Send Remote Fault until rx_in_sync
        |
        V
     IN_SYNC -> Send Idle for T ~= 10 mS
        |
        V
     LINK_UP -> set link_up bit in status register, accept data from MAC


The transition from LINK_UP to RESET would be a combination of

    break_link_received | rx_lost_sync

The term rx_lost_sync is derived from a timer that is retriggered by
rx_in_sync.  It's a watchdog timer that expires if the receiver looses
sync for greater than 5 mS.

The response to the receipt of Remote Fault is to set the Remote Fault
bit in the status register.

Howard Frazier
Cisco Systems, Inc.