Conference 7.286::fddi

If those questions are in response to some customer queries we'd be 
interested in finding out more about why those questions are being asked.

Anyway, some answers:

>Elasticity


>Q's.  	What size buffer do we use in our equipment ?
I don't remember -- but it's bigger than the standard requires.
      
>	How does the action of elasticity cause preamble to 'shrink' ?
If my transmit clock is slower than the one of the station upstream,
then when I repeat a frame the symbols go out a bit slower than they
arrive.  If you send me a steady stream of frames, I have to delete a
symbol of preamble every once in a while to avoid falling behind too much.

>      	What size preamble (number of idle symbols) do we use in our equipment?
We do what the standard says.  Specifically, it requires you to originate
frames with 16 symbols of preamble.

>Smoothing 

>Q's.  	I quess the smoother must be based on a buffer. What size of buffer ?
Right.  Actually, it uses the elasticity buffer.

>      	When adding idle symbols, what is the minimum number of idles we will
>      	send to the MAC ? Is there a maxmimum ?
I'm not sure about the minimum.  The maximum is very large since the ring
can be idle for quite a while.

>      	How does the smoother delete idles; does this cause 'gaps' in the
>	symbol stream to the MAC ?
The Ebuf is essentially a circular buffer with two pointers.  One pointer
points at the place where received symbols are written; the other points
where symbols are read out and passed on to MAC.  The first pointer runs
off the received symbol clock (recovered from the incoming bistream).  The
second pointer runs from the local clock (the transmit clock).  Both normally
step continuously on the clock pulses.

If the received symbol rate is higher than the local (transmit) rate, then
the receive pointer slowly moves ahead of the local pointer.  If this could
go on indefinitely, it would eventually overtake ("lap" as car racers would
say) the local pointer, at which point data has been lost.

To avoid this, the smoother watches the distance between the two pointers,
and tries to keep that within a certain range.  If the receive pointer
moves too far ahead, the smoother reduces the preamble by having the
local pointer skip over one or more Idle symbols.  This makes it catch up
with the receive pointer.

Conversely, if the local pointer is moving too close to the receive pointer
(which happens if the local clock is faster than the receive data rate) the
smoother will insert additional Idle symbols at the receive pointer position
and advance the receive pointer.

Note that smoother adjustments are done ONLY in between frames.  This is
why there is a limit on the frame length: together with the clock frequency
tolerance it ensures that the pointers can't get far out of step even during
a maximum length frame.

If one of the clocks is way out of tolerance, then it IS possible for the
pointers to get too far out of step during a long frame.  This event is
an "Elasticity buffer error" which is counted.  It causes loss of the
frame in question.  If you see that counter count, it indicates a serious
hardware problem in one of the stations.  Note that it is not necessarily
in the station that is counting...

>The claim process

>Q's.	Do changes in the ring cause a claim process to occur, eg 'station
>	leaving the ring' or 'ring wrap on dual ring' or 'when the ring
>	un-wraps after the fault is corrected' ?
>        (I've been looking at the MAC spec and believe such changes
>        will not cause a claim, but I don't feel sure that I'm correct).
MAC wouldn't say that.  However, as you will find in SMT, when a ring
configuration change occurs the station "scrubs" the ring to avoid the
risk of corrupting frames.  This is normally done long enough that the
MAC times out (on the TVX timer) and claim occurs.

>        Is it timing related (eg if a cable fails as the token is going along
>        it we'll get a timout causing a claim, but what if only a data frame
>        was lost) ? 
Normally loss of a single data frame will not cause claim.  Loss of multiple
data frames can cause claim, since MAC expects to see good frames or
tokens at least once per TVX (around 3 ms).  However, apart from 
reconfiguration, loss of the token itself is the normal cause of claim.

	paul

    	Hello Steve,
    
    More info: Pull over the System Level Description (see note 44.5), then
    read sec. 2.4.5 for Elasticity buffer (4.5 code bits), and 2.9 - 2.10
    for claim process info. As Paul said, the ANSI specs are the final
    word, but the SLD has good stuff.
    
    Re: Claiming in response to a wrap of the dual ring, should be YES
    regardless of Frame type trashed (please, someone slap me silly if I'm
    wrong...) Failure of primary path should cause BEACON process to be
    initiated, which is followed by TRACE, then CLAIM to reinitialize ring,
    n'est pas?
    
    Also, CLAIMing in response to a node's leaving the ring makes sense...
    Assume that a ring consists of n nodes, 1 of whom requires a 4 ms TTRT
    (maybe real-time lab goodies), all other nodes prefer to xfer large
    data chunks less frequently, and are happy with a 20ms TTRT. If the 4ms
    node leaves the ring, it makes sense that we re-enter the claim
    process, so's we can agree on a new TTRT of 20ms.
    
    			Chuck Ouimette CSC/CS
    

Paul, Chuck,

Thanks for the answers. These are 'for my own education' rather than customer
queries. I have the SLD (its quite good) and some specs, but the SLD doesn't
get detailed enough and the specs aren't very friendly :-)

A couple of extras from your replies;

Paul; you say the smoother uses the elasticity buffer. In the PHY spec it lists
3 functions, elasticity, decode and smoothing, where the decode function seems
mainly to establish the symbol clock and keep it accurate. Am I correct to 
assume this function is included in our 'elasticity' function (or else how can
smoothing share the same buffer).

Re the scrub process; When the scrub process occurs, the maximum time scrub can
continue for is 2*TVX (and hence cause a claim to start), BUT as this is a
MAXIMUM, does this imply that sometimes the station who experiences a problem
will timeout/claim but at other times it will not claim, or do we enforce a
minimum scrub to be equal to the maximum (ie. is a timeout/claim quaranteed
after any ring change)?

Chuck;  > Failure of primary path should cause BEACON process ....
This implies that SMT requests the MAC to beacon, as the normal path into
beaconing is after a claim fails. Is this really true, ie ring wrap causes
SMT request for MAC to beacon, as this seems to go against what is happening
in the scrub process ? (I am looking at the spec, but if you know the answer
it'll save a lot of time)

Thanks again,

Steve

We scrub long enough for TVX to time out.  It's possible that not everyone
will do so.  If not, then reconfigurations involving those nodes only
wouln't result in Claim.  As .2 points out, there are very good reasons
for wanting Claim on reconfiguration.

On the other hand, loss of "any frame" doesn't cause beacon.  Beacon occurs
for two reasons: (1) because SMT asks for it (which it mighe on insertion
into the ring, though we don't -- we go straight to Claim instead to save time)
(2) when Claim times out, after about 160 ms.  Case (2) indicates a fault,
case (1) doesn't.

Re .3: the decode function recovers the data clock.  That clock and the
local clock are then inputs to Ebuf/smoother.  One reason the smoother is
described separately from the Ebuf is that it wasn't originally in the
standard: it was added when the rest of PHY was finished because we at
DEC did a lot of simulation and discovered that a ring without smoothers
will not work!

	paul

    	Re: Claim due to primary/secondary failover:
    
    In my little lab ring (2 DEFCN's, 2 DEFEB's), every time I force
    failover (pull either A or B port), the "ring initialization received"
    counter increments on all nodes in the ring. When I restore the primary
    path, it increments again, i.e., 2 initializations for each
    failover/recovery. I just did this 15 or so times, got 2 inits for each
    break/restore.  (Unfortunately, the "ring initialization initiated"
    remains at 0 on all 4 nodes, so it looks like ELMS has some problems
    :-)  ).
    
       I had *thought* that the concentrators initiated Beacon/trace/claim
    as the result of loss of optical signal on an "A" port's primary input,
    instead of just wrapping & continuing on it's merry way, and the above
    tests seem to bear this out (Claim process, anyhow), but I'm bereft of
    documentation which describes this. (when lacking proof, quote
    statistics!)
    
       In the SLD, sec. 3.2.3, it's described how the concentrator will
    scrub the ring when a reconfiguration is detected. Since (.4) the scrub
    lasts long enough to time out TVX, reinitialization should occur. 
    
       Perhaps someone can jump in & quote chapter & verse to clear up
    wether or not ALL DAS's must do this per the specs, or verify
    that it's something which we did because "It's the Wilford Brimley
    thing to do..."
    
    				Chuck
    

In general, no.

The chip specs are presumably on-line somewhere, but they are not available
for general reading and in any case are likely to go into a whole lot more
detail than most people want.

The ANSI standards are typically more suitable (although as standards go
their quality is low).  However, those are not on-line, and cannot be,
since they are copyrighted documents.  If you want a copy you have to buy
it.

The DNA FDDI Data Link architecture spec is on-line.  Currently it is
in "fieldtest" and therefore its distribution is somewhat limited.  That
will change soon.

	paul

    please post a pointer to whatever spec/docs are available, WHEN they
    are available.
    
    thanx
    hw