Conference 7.286::fddi

    Note 319 only states what should be done.  It does not state what VMS
    does.
    
    What VMS does is documented in the I/O User's Manual (LAN chapter).
    VMS allows the application to specify the priority bit value to be
    used on either a per-channel basis or on a per-transmit basis (or to
    not specify at all).  If the application does not specify a method,
    then the VMS FDDI drivers will use a default value of 0 for the
    priority bits on every transmit.
    
    The original FDDI architecture from NAC stated that the default should
    be 4.  However, this was not conducive to having applications
    eventually switch from the smaller Ethernet sized packets to the
    larger FDDI sized packets.  So we convinced the NAC architects that the
    default should be zero.
    
    Also note that just because a node uses a priority value of zero does
    not mean that it has to use small packets.  If the application wants to
    transmit large packets with a priority field of zero or if an
    application wants to send large packets to a node that is sending
    packets with a priority value of zero, it may do so.  The VMS FDDI
    drivers do not force a packet to be 1500 bytes if the priority value is
    zero.  As mentioned in note 319, the problem of making the application
    work on both Ethernet and FDDI is left up to the application.  The VMS
    FDDI driver is just providing the information to make that job easier.
    
    David Gagne

    re -1
    	You don't quite answer my question .
    
    	Statement :- Cabletron have designed their FDDI bridge to
    dymamically set the LLC frame priority bit depending on resources on
    the bridge.
    
    Question) Are Cabletron Violating the standard by setting a priority on
    ETHERNET origionated packets.
    
    Question) are the FDDI bridges & routers allowed to assign priorities
    to FDDI frames ?.
    
    
    				Thanks
    
    
    		Steve C

[and people wonder why I never delete mail...]

From NACTO::[email protected] Tue Oct  5 09:56:51 1993
Received: by netrix.lkg.dec.com; id AA24384; Tue, 5 Oct 1993 09:56:49 -0400
Date: Tue, 5 Oct 93 09:56:49 -0400
Message-ID: <[email protected]>
From: NACTO::[email protected] (Floyd Backes)
To: NETRIX::[email protected] (Matt Thomas)
Subject: Re: FDDI to switched ethernet correctly - comp.dcom.lans.fddi #1800

Passage and verse:

IEEE Std 802.1i-1992 (Supplement to IEEE Std 802.1D-1990)

Section 3.7.4, second paragraph:

"Add an entry to table 3-1 to show that the outbound user priority for
FDDI (when the frame is received from a CSMA/CD LAN) has a default
value of 0 and a range of 0-7, as follows:"

[table containing the Recommended or Default Value follows]

Hope this helps,

floyd. 

> Floyd,
> 
> do you know the relavent parts of 802.1 bridging to refute this?
> 
> Thanks,
> 
> -- 
> Matt Thomas                            Internet:   [email protected]
> U*X Networking                         UUCP:       ...!decwrl!thomas
> Digital Equipment Corporation          Disclaimer: This message reflects my ow
n
> Littleton, MA                                      warped views, etc.
> 
> In article <[email protected]>, [email protected] (Vernon Sc
hryver) writes:
> 
> In article <[email protected]> [email protected]
 () writes:
> >
> >    No, Vernon, I'm not joking and your reply is inappropriate.
> >
> >    As I understand the rule, DEC bridges do this:
> >    If a frame goes from FDDI to FDDI (or TRN to TRN), the Frame Control
> >    byte is copied as-is.  If a frame goes from Ethernet to FDDI, one well-
> >    known Frame Control value is placed in the FDDI frame.  I believe it's
> >    the lowest of the eight encodings of "LLC-type frame".
> >
> >    Presumably, if one bridged TRN to FDDI for a DEC protocol (such as
> >    DECnet or LAT) that supports TRN (and they don't yet, I believe),
> >    the protocol stack would use FDDI's max. frame length, and the bridge
> >    would pass the Frame Control field with some mapping that avoids the
> >    well-known "it traversed an Ethernet" code point.  Since no DEC protocol
> >    would try to exceed the FDDI max. frame length when using TRN, there's
> >    no fragmentation issue in that case.  The issue arises only when
> >    bridging through Ethernet.
> >
> >    As you can see, the bridge's rule for FC is simple and not offensive
> >    to any protocol stack.  The coding assumptions for FC are primarily
> >    contained in the host software.  DEC protocols running on FDDI use a
> >    particular value for the FC byte, and this value is distinct from the
> >    one used by bridges when translating from Ethernet to FDDI.  If the FDDI
> >    hosts agree never to use the lowest-numbered "LLC-type frame" code point,
> >    then you can see that DEC protocols can discover whether the MTU through
> >    a series of bridges is smaller than FDDI.  (Like I said, DEC protocols
> >    make no effort to detect a larger MTU than FDDI's until we deploy protoco
ls
> >    for bridged ATM-FDDI environments.)
> >
> >    I believe this scheme addresses your concerns for DECnet over bridges.
> >    MTU discovery through a router is another problem.  (But not a problem
> >    for LAT! 8^).)  Kindly stop implying that DECnet can't sense the MTU
> >    in a bridged LAN.
> >
> >    NB: I don't implement the network stacks in hosts.  What you read above
> >    is my understanding of what the hosts do with the FC byte.  Note that
> >    a correct FDDI-FDDI bridge would not alter the value of FC, so third-part
y
> >    FDDI bridges should also allow DECnet to sense the MTU of a bridged path.
> 
> 
> Well, I really thought you might have been joking.  If you are serious,
> how do you resolve the problems?
> 
> There is no multi-vendor standard for setting FC LLC priority values to
> indicate the origin of bridged frames.  You cannot simply assume that an
> LLC priority of 0 means a frame came from an Ethernet bridge and a priority
> of 7 means it came from an FDDI host.  There is a standard for LLC priority
> values, and it says to do something different.  There is only one "LLC-type
> frame".  There are eight "priorities" that such a frame might carry.
> 
> Does Digital Equipment Corp. publically describe this re-interpretation
> of the LLC priority?  What does DEC tell (the very few) customers who want
> to use async. priorities as the are described in the standards?
> 
> How do DEC hosts cope in rings bridged to Ethernets by non-DEC
> FDDI-Ethernet bridges that do not follow this practice?  What if the
> non-DEC bridge just happens to use the LLC priority that DEC hosts use
> to indicate FDDI frames?
> 
> Is the MTU of all bridge Token Rings greater than 4500?  I have the
> impression it can be less than 4K, but rarely is.
> 
> What if a bridge to some other medium is involved?  Say to an ATM or
> Frame Relay network, when an MTU less than 4500 but greater than 1500?
> 
> I do not mean to <<imply>> "that DECnet can't sense the MTU in a
> bridged LAN."  I mean to baldly say as much.  Please prove me wrong by
> addressing my technical objections, not just repeating your assertion
> that the LLC priority is used by DEC bridges and hosts.
> 
> 
> Vernon Schryver    [email protected]

     I would like to point Cabletron at someone within DEC who can 
    talk ISO standards ( OR ANSI), as they refuse to accept what they are
    doing is wrong
    
    				Any  Names ????
    
    
    
    
    			Steve C