Conference 7.286::fddi

    The priority bits are used in VMS/FDDI to determine the origination
    of the frame. Frames that originate on the FDDI should (according
    to DNA for FDDI) have a priority value of 4. Frames that originated
    on something other than the FDDI ring and were put on the FDDI ring
    via a bridge should (according to an as yet unpublished revision to
    the IEEE 802.1d bridge spec, and DNAFDDI) have a priority value
    of zero.
    
    	So I guess the answer is yes, our products do use the priority
    field.
    
    							/Bill
    

ANSI does not specify any use for those bits.  They are simply passed to and
from the data link user.

The IEEE bridge standard addendum for FDDI says that you propagate these
bits, except on frames coming from Ethernet, in which case 0 is used.

DEC products use this rule to recognize the situation where traffic has 
crossed an Ethernet (i.e., Ethernet/FDDI bridges).  The basic idea is that
you send a non-zero value (4 is used) in the priority bits.  If the frame
had to go across an Ethernet on its way to the destination, then the
destination will see 0 in the priority bits.  If not, it will see the 
non-zero value.

The destination remembers which it saw.  If it wants to send traffic back,
and it had previously seen 0 for the priority value, the traffic is sent
in Ethernet-size frames to make sure it can get there.  Otherwise, it can
be sent in FDDI-size frames.

Note that this still works if the other node is a non-DEC node that happens
to send FDDI frames with priority bits = 0; all that happens it that smaller
frames are used than might have been possible.

	paul

    	It's true this will work even if the station is a non-DEC,
    but in case of a "non-proprietary" protocol as IP, does it means
    our VAX/VMS (it doesn't seem to be the case of Ultrix 4.2) will
    limit their maximum data link SDU to 1518 bytes, just because
    FC = 50.
    	As only DEC uses FC = 54, we'll decrease our peformances
    when transmitting TCP/IP frames to an non-DEC station installed
    on the same ring as us but which set FC = 50
    
    	Is there any "workaround" ?
    
    	Best regards
    

    It all depends on the implementations at both ends. We have told
    FDDI datalink users that a non zero FC value means thet frame
    did originate on FDDI and never crossed the Ethernet. The UCX
    applications (or any other applications) can make use of the
    received FC to decide on buffer size that can be used. The
    application has to be reprogrammed to have larger buffers
    before it can effectively use the FC and implement large buffers.
    
    What we have provided is the means for applications to determine this.
    It is still up to the application to look at the FC,.,. and perhaps
    make use of larger buffers if possible. In the case of IP,.. that
    means UCX if its DEC,.. or it means third party. Most likely small
    buffers wil prevail until everybody has had a chance to reprogram
    for large buffers.
    
    Hope this helps
    
    							/Bill
    

    ... and a quick question for Paul...
    
    Back there when you spoke about the IEEE's bridging spec addendum,
    you said that the FC would be set to 50 only if the frame
    was being nridged from Ethernet to FDDI. Isn't it true even if
    you arew bridging from another medium (e.g. 802.5,.. 802.4,...)?
    
    Wouldn't a token ring to FDDI bridge (if such a thing existed) be 
    required to set the FC to 50 on the FDDI?
    
    Thanks
    
    							/Bill
    
    
    

Nope.

FC, with its "priority" field, exists in all the other 802 LANs, and the
rule is to carry it across a bridge.  Only for 802.3, where that field does
NOT exist, is the default of 0 needed.

Fortunately for us, all the other 802 LANs have a maximum frame size GREATER
than FDDI.  So the purpose of the algorithm (which is to detect the case
where you should send frames smaller than the FDDI limit) is taken care of.

	paul

    Thanks
    
    							/Bill
    

    	Thanks 
    
    	Patrick