The IP Over NBMA (ION) Archive

Cell Relay Retreat>ION Archive>month:1998-Sep> msg00001



[Date Prev][Date Next][Thread Prev][Thread Next]  
  [Date Index][Thread Index][Author Index][Subject Index]

RFC 1483 update

  • From: "Albert Manfredi" <manfredi@arl.bna.boeing.com>
  • Date: Fri, 4 Sep 1998 19:11:34 -0400

-----Original Message-----
From: Eiji Tomimura <tomimura@sumitomo.com>
Date: Friday, September 04, 1998 7:04 PM
Subject: Re: (ION) RFC 1483 update


>Dear all,
>
>After the IETF ION Meeting, I've come to mind one
>interoperability issue concerning RFC1483,
>which I met a few years ago.
>
>The problem come from the definition of minimum
>frame length of Bridged Ethernet/802.3 frame format.
>My question is that minimum frame length of Ethernet
>(=64byte) is also applied to this format or not.
>
>Personally, I don't think it is a good idea to apply
>minimum frame length of Ethernet to ATM environment
>for the efficiency of the bandwidth.
>
>
>---
>The problem occurred in following environment:
>
>Host 1 ----< FDDI >---- Bridge A ---< ATM-PVC
>                                       |
>Host 2 --< Ethernet >--- Bridge B --< ATM-PVC
>
>The bridge A translate FDDI format to Bridged
>Ethernet/802.3 format used on the ATM PVC. The
>bridge A don't add a padding field if FDDI frames
>are less than 64byte. (i.e. The bridge A assumes
>padding field should be added at the other side
>of the edge.)
>
>The bridge B drops frames which are less than
>the minimum length of Ethernet.


Seems to me that it's the responsibility of Bridge B, not ATM or RFC
1483, to adjust the minimum length _if_ this is a problem for the
guy on the non-ATM side of the bridge. I mean, RFC 1483 cannot be
clairvoyant. (On the other hand, since all broadcast LANs except for
Ethernet seem be be dying a slow death, ...)

Bert
manfredi@arl.bna.boeing.com


X-Info: To unsubscribe, email 'majordomo@sunroof.eng.sun.com' with
X-Info: 'unsubscribe ion' in the body of the message.