Conference 7.286::fddi

375.0. "SIF Request from DECbridge500" by EWBV06::IDO () Thu Oct 24 1991 12:03

I attempted a SMT SIFrequest to an other vendor station throughout DB500 and 
DC500.
I received a SIFresponce properly from the vendor when I sent a SIFrequest from 
DC500, however I got an error message "illegal length" if I sent the request 
from DB500.
I confirmed that a response on  the question was SMT RDF frame indicated  
a length error with  SHOW SIF  ....  RAW command.
I didn't understand  why the vendor returned a RDF to a SIFrequest only from 
DB500.  
I compared both SIFrequest frames from DB500 and DC500 with CAMELAN and I found 
the difference. It is that only DB500 adds 23 bytes of extra zeros the back of
SMT header field in the it's MAC frame.

SIFrequest from DB500
+----------+-----------+---------------+-----+---+---+
|MAC header|SMT header |23 bytes zeroes|FCS  |ED |FS |
+----------+-----------+---------------+-----+---+---+

SIFrequest from DC500
+----------+-----------+-----+---+---+
|MAC header|SMT header |FCS  |ED |FS |
+----------+-----------+-----+---+---+

Since SIFrequest has no information field, it's MAC frame includes a SMT header
only. 

We are now in the discussion wethere FDDI standard allows us this zero padding.
The vendor checks the frame integrity of a SIFrequest with a preset constant
value specified the total MAC frame length { = SIZE of (SMT SIF header+  MAC 
header+FCS+ED+FS)}.  
The vendor returns a RDF with a length error due to DB500 sends a SIFrequest 
included 23 bytes of extra zeros in it's MAC frame.

I think the client (SMT in this case) doesn't care about MAC level because 
SMT has own INFO_LENGTH parameter. However, I also think any padding is not 
allowed in MAC frame because there is no PAD flag in MAC header.  Since DC500
sends a correct SIFrequest, DB500 also seems to have a bug or something like 
that.

What do these zeros in the MAC frame of SIFrequest from DECbridge500 mean ???

Thanks in advance,
Naoki
           

    This issue was discussed at ANSI last August.  If I remember correctly,
    the decision was that what the bridge does is NOT correct, but that
    stations are allowed to accept such messages.  (In other words, the
    bridge is wrong, and rejecting the request is permitted.  However,
    accepting it -- by ignoring the padding -- is also permitted.)
    
    Too bad we didn't know about this before, or we could have tried to
    have the rules be different.  As it is, the bridge will have to be
    fixed.  I think the cause has something to do with the internal
    structure of the bridge and where it generates these frames.
    
    	paul

I checked the notes... ANSI FDDI meeting, June 18: padding on transmit
is not permitted, however nodes may optionally accept padded frames on
receive.  

	paul

    According to the Software Project Manager, the SMT padding problem will
    be fixed in the next release of microcode for the DB500. The problem
    does not exist in DB5xx/6xx.
    

RE: .1, .2, and .3

Thank you for your very quick responses and the solution.

Regards,
Naoki