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

RE: Link Status thoughts


The answer to your question depends partly on what we decide to do about
Remote Fault, Break Link and Local Fault. One of the open issues in the
RF/BL is where the RF/BL state machine resides. Is it in each sublayer
or is there one machine at the top of the stack?

If the receive link is down, then my feeling is that the signal sent up
the link should either be Idle or it should be the Local Fault signal.
Which one depends upon whether we decide we will:
	signal local fault up the link as an inband signal, 
	send local fault as a separate signal line, or 
	not send any local fault signal up through the physical layer

On the transmit side of the link (PCS and above) when the 
receive link is out of lock, there are three choices: 
	send idle
	send remote fault 
	continue to transmit normally
The latter is what one would do if the RF/BL state machine
resides at the top of the physical layer. It would generate
the RF signal and the XGXS would just relay it.

In regard to /E/ and XAUI, it is entirely possible to get
a control byte from the XGMII that does not correspond
to the defined encodings and that should result in an
/E/ on XAUI. I don't think we can say that XGMII will
never have an error.


-----Original Message-----
From: Lior Reem [mailto:LReem@xxxxxxxxx]
Sent: Wednesday, November 01, 2000 1:57 AM
To: 'THALER,PAT (A-Roseville,ex1)'
Cc: 'HSSG'
Subject: RE: Link Status thoughts


Thanks for the answers.
One more question to complete the picture.
What should the XGXS transmit onto the XAUI interface when the link is down
- the regular data stream, or idle patterns (or other)?

By the way - if /E/ can be transmitted into the XAUI/PCS, then Figure 48-8
should include this case, and hence, the relevant state machine diagrams.


Lior Re'em
Avaya Inc.

Tel :  +972 3 6457608
Email : lreem@xxxxxxxxx

> -----Original Message-----
> From:	THALER,PAT (A-Roseville,ex1) [SMTP:pat_thaler@xxxxxxxxxxx]
> Sent:	&dalet; &nun;&vav;&bet;&mem;&bet;&resh; 01 2000 2:03
> To:	Lior Reem; 'rtaborek@xxxxxxxxxxxxx'
> Cc:	'HSSG'
> Subject:	RE: Link Status thoughts
> Lior,
> /E/ would normally be transmitted when any of the physical sublayers (e.g.
> a PCS or an XGXS) receives bytes that it cannot encode. For instance, if
> a DTE XGXS got a byte from the XGMII that was a control byte but did not
> have a valid control code or if the 10GBASE-X PCS received a byte that
> had a code violation. They are normally caused by bit errors. 
> Also, if a sublayer receives an /E/, it will transmit an /E/. 
> The purpose of /E/ is to protect against an error getting turned into
> a valid code that might end up producing a packet with an undetectable
> error.
> There are two proposals for break link and remote fault siganlling. The
> 802.3ae task force has not made any decision on the matter yet. By the
> way,
> since
> we have an approved project, the group is no longer called HSSG, High
> Speed Study Group. A study group exists to study what project if any
> should be initiated. Once the project is approved, it isn't a study 
> group any more.
> 802.3ae has not adopted any objectives for any kind of auto negotiation
> protocol. All the links we have defined will initialize using the 
> normal data signals -- no training signals are needed.
> Pat Thaler
> -----Original Message-----
> From: Lior Reem [mailto:LReem@xxxxxxxxx]
> Sent: Monday, October 30, 2000 7:23 AM
> To: 'rtaborek@xxxxxxxxxxxxx'
> Cc: 'HSSG'
> Subject: RE: Link Status thoughts
> Hi Rich,
> 1. Can you explain in which cases /E/ is transmitted onto the XAUI
> interface, and how should the receiver react in these cases?
> 2. Are there any agreements in the HSSG about Remote Fault and Break Link
> signaling?
> 3. Any thoughts about Link Initialization?
> These questions are mainly a concern for cross-connect equipment which
> work
> in low levels, but need to supply solutions in broken link cases.
> Thanks,
> Lior.
> ~~~~~~~~~~~~~~~~~~
> Lior Re'em
> Avaya Inc.
> Israel
> Tel :  +972 3 6457608
> Email : lreem@xxxxxxxxx
> ~~~~~~~~~~~~~~~~~~
> > -----Original Message-----
> > From:	Rich Taborek [SMTP:rtaborek@xxxxxxxxxxxxx]
> > Sent:	ℷ &alef;&vav;&qof;&tet;&vav;&bet;&resh; 31 2000 10:53
> > To:	HSSG
> > Subject:	Re: Link Status thoughts
> > 
> > 
> > Isaac,
> > 
> > P802.3ae has no Auto-Negotiation objective and Auto-Negotiation was
> > voted down at the September, 2000 meeting. Current P802.3ae definitions
> > set Link Status = OK when the transmitter is operational and the
> > receiver can synchronize to the incoming bit stream and signal detect is
> > OK. Any "close loop" or handshaking of the two simplex links must be
> > initiated at the MAC level or above. This is true for all P802.3ae
> > variants including LAN and WAN and is independent of coding and the
> > presence or absence of any interfaces or extensions.
> > 
> > Best Regards,
> > Rich
> >      
> > --
> > 
> > Isaac Fuchs wrote:
> > > 
> > > Hi Rich
> > > As I know from 802.3z  link_status is a close loop
> > > information. It's mean that link_status is up only when
> > > both sides transmit and also receive  right symbols (c1,c2)
> > > [I know that 802.3z includes also auto_neg.].
> > > Is there  in P802.3ae any close loop (LAN application)?
> > > I mean  when I transmit after powering on /K/R/.. from XGXS layer how
> > can I
> > > know that the remote receive this information?
> > > Regards
> > > Isaac Fuchs
> >                                  
> > ------------------------------------------------------- 
> > 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