RE: [RPRWG] RE: payload length and padding and stuff
"Romascanu, Dan (Dan)" <[email protected]> Wed, 4 Dec 2002 18:25:20 +0200
| Newsgroups | gmane.ietf.iporpr |
|---|---|
| Message-ID | <AAB4B3D3CF0F454F98272CBE187FDE2F017B741E@IS0004AVEXU1.global.avaya.com> |
Nader, There are actually two different layers here. 802.3 MACs and PHYs MUST support a max frame length of 1522. You may find implementations that are both standard compliant and support jumbo sizes as proprietary extensions. I think that 802.1 bridges do not have such a limitation within the standard. As you mention, they can be configured to support larger frame sizes. Actually some of the non-Ethernet 802 technologies already support larger frame sizes. Dan > -----Original Message----- > From: Nader Vijeh [mailto:[email protected]] > Sent: Wednesday, December 04, 2002 6:10 PM > To: Romascanu, Dan (Dan) > Cc: [email protected]; [email protected] > Subject: RE: [RPRWG] RE: [IPORPR] payload length and padding and stuff > > > Dan, > > Thank you for the correction. Jumbo frames are not supported > by the 802.3 > standard. > There are Ethernet switches on the market that support jumbo > frames in a > proprietary manner. Of course these will not interoperate > with standard > compliant 802.1 bridges. As I pointed out in the rest of the > message, even > if jumbo frames are supported, max frame size "needs to be > configurable to > be lower, in order to comply with transparent bridging requirements". > > Nader > > -----Original Message----- > From: Romascanu, Dan (Dan) [mailto:[email protected]] > Sent: Wednesday, December 04, 2002 12:45 AM > To: Nader Vijeh; Necdet Uzun; Anoop Ghanwani > Cc: Frank Kastenholz; [email protected]; [email protected] > Subject: RE: [RPRWG] RE: [IPORPR] payload length and padding and stuff > > > > > > The max frame size may be extended beyond 802.3 1522 bytes > > limit as there is > > precedence in 802.3 community. > > Nader, > > I am not sure what you exactly mean. If you refer to what is > popularly known > as 'Jumbo frames', they are not supported by the IEEE 802.3 > standards. > > Dan >