RE: [RPRWG] RE: payload length and padding and stuff
"Romascanu, Dan (Dan)" <[email protected]> Mon, 9 Dec 2002 10:34:59 +0200
| Newsgroups | gmane.ietf.iporpr |
|---|---|
| Message-ID | <AAB4B3D3CF0F454F98272CBE187FDE2F017B7427@is0004avexu1.global.avaya.com> |
This is a multi-part message in MIME format.
------_=_NextPart_001_01C29F5D.DC36F969
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Tony,
=20
You are right, and I obviously stand corrected. My question would be - =
is the reference mac_service_data_unit supported by the LAN configurable =
per port? If the answer is yes, the implication would be that standard =
802.1D bridges can be configured to support these MAC and PHY =
implementations that accommodate larger frame sizes ('jumbo frames') =
that some vendors built as proprietary extensions to the 802.3 MAC and =
PHYs.
=20
Regards,
=20
Dan
=20
-----Original Message-----
From: Tony Jeffree [mailto:[email protected]]
Sent: Thursday, December 05, 2002 11:36 AM
To: Romascanu, Dan (Dan)
Cc: Nader Vijeh; [email protected]; [email protected]
Subject: RE: [RPRWG] RE: [IPORPR] payload length and padding and stuff
Dan -
I think that you will find the 802.1D standard requires conformant =
Bridges to discard frames that exceed the max frame size for the =
destination LAN:
"7.7.1 Enforcing topology restriction
Each Port is selected as a potential transmission Port if, and only if
a) The Port on which the frame was received was in a forwarding state =
(8.4), and
b) The Port considered for transmission is in a forwarding state, and
c) The Port considered for transmission is not the same as the Port on =
which the frame was received,
and
d) The size of the mac_service_data_unit conveyed by the frame does not =
exceed the maximum size of
mac_service_data_unit supported by the LAN to which the Port considered =
for transmission is
attached.
For each Port not selected as a potential transmission Port, the frame =
shall be discarded."
Regards,
Tony
At 18:25 04/12/2002 +0200, Romascanu, Dan (Dan) wrote:
Nader,
There are actually two different layers here.=20
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
>=20
>=20
> Dan,
>=20
> Thank you for the correction. Jumbo frames are not supported=20
> by the 802.3
> standard.
> There are Ethernet switches on the market that support jumbo=20
> frames in a
> proprietary manner. Of course these will not interoperate=20
> with standard
> compliant 802.1 bridges. As I pointed out in the rest of the=20
> message, even
> if jumbo frames are supported, max frame size "needs to be=20
> configurable to
> be lower, in order to comply with transparent bridging requirements".
>=20
> Nader
>=20
> -----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
>=20
>=20
> >=20
> > The max frame size may be extended beyond 802.3 1522 bytes=20
> > limit as there is
> > precedence in 802.3 community.
>=20
> Nader,
>=20
> I am not sure what you exactly mean. If you refer to what is=20
> popularly known
> as 'Jumbo frames', they are not supported by the IEEE 802.3=20
> standards.=20
>=20
> Dan
>=20
Regards,
Tony
------_=_NextPart_001_01C29F5D.DC36F969
Content-Type: text/html;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META content=3D"MSHTML 5.50.4916.2300" name=3DGENERATOR></HEAD>
<BODY>
<DIV><SPAN class=3D260312708-09122002><FONT face=3DArial color=3D#0000ff =
size=3D2>Tony,</FONT></SPAN></DIV>
<DIV><SPAN class=3D260312708-09122002><FONT face=3DArial color=3D#0000ff =
size=3D2></FONT></SPAN> </DIV>
<DIV><SPAN class=3D260312708-09122002><FONT face=3DArial color=3D#0000ff =
size=3D2>You=20
are right, and I obviously stand corrected. My question would be - is =
the=20
reference mac_service_data_unit supported by the LAN configurable per =
port? If=20
the answer is yes, the implication would be that standard 802.1D bridges =
can be=20
configured to support these MAC and PHY implementations that accommodate =
larger=20
frame sizes ('jumbo frames') that some vendors built as proprietary =
extensions=20
to the 802.3 MAC and PHYs.</FONT></SPAN></DIV>
<DIV><SPAN class=3D260312708-09122002><FONT face=3DArial color=3D#0000ff =
size=3D2></FONT></SPAN> </DIV>
<DIV><SPAN class=3D260312708-09122002><FONT face=3DArial color=3D#0000ff =
size=3D2>Regards,</FONT></SPAN></DIV>
<DIV><SPAN class=3D260312708-09122002><FONT face=3DArial color=3D#0000ff =
size=3D2></FONT></SPAN> </DIV>
<DIV><SPAN class=3D260312708-09122002><FONT face=3DArial color=3D#0000ff =
size=3D2>Dan</FONT></SPAN></DIV>
<DIV><SPAN class=3D260312708-09122002><FONT face=3DArial color=3D#0000ff =
size=3D2></FONT></SPAN> </DIV>
<BLOCKQUOTE dir=3Dltr=20
style=3D"PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px =
solid; MARGIN-RIGHT: 0px">
<DIV class=3DOutlookMessageHeader dir=3Dltr align=3Dleft><FONT =
face=3DTahoma=20
size=3D2>-----Original Message-----<BR><B>From:</B> Tony Jeffree=20
[mailto:[email protected]]<BR><B>Sent:</B> Thursday, December 05, =
2002 11:36=20
AM<BR><B>To:</B> Romascanu, Dan (Dan)<BR><B>Cc:</B> Nader Vijeh;=20
[email protected]; [email protected]<BR><B>Subject:</B> RE: [RPRWG] =
RE:=20
[IPORPR] payload length and padding and stuff<BR><BR></FONT></DIV>Dan=20
-<BR><BR>I think that you will find the 802.1D standard requires =
conformant=20
Bridges to discard frames that exceed the max frame size for the =
destination=20
LAN:<BR><BR>"<FONT face=3D"Arial, Helvetica"><B>7.7.1 Enforcing =
topology=20
restriction<BR></B></FONT><FONT face=3D"Times New Roman, Times">Each =
Port is=20
selected as a potential transmission Port if, and only if<BR>a) The =
Port on=20
which the frame was received was in a forwarding state (8.4), =
and<BR>b) The=20
Port considered for transmission is in a forwarding state, and<BR>c) =
The Port=20
considered for transmission is not the same as the Port on which the =
frame was=20
received,<BR>and<BR>d) The size of the mac_service_data_unit conveyed =
by the=20
frame does not exceed the maximum size of<BR>mac_service_data_unit =
supported=20
by the LAN to which the Port considered for transmission=20
is<BR>attached.<BR>For each Port not selected as a potential =
transmission=20
Port, the frame shall be=20
discarded."<BR><BR></FONT>Regards,<BR>Tony<BR><BR><BR><BR>At 18:25 =
04/12/2002=20
+0200, Romascanu, Dan (Dan) wrote:<BR><BR>
<BLOCKQUOTE class=3Dcite cite type=3D"cite">Nader,<BR><BR>There are =
actually two=20
different layers here. <BR><BR>802.3 MACs and PHYs MUST support a =
max frame=20
length of 1522. You may find implementations that are both standard=20
compliant and support jumbo sizes as proprietary =
extensions.<BR><BR>I think=20
that 802.1 bridges do not have such a limitation within the =
standard. As you=20
mention, they can be configured to support larger frame sizes. =
Actually some=20
of the non-Ethernet 802 technologies already support larger frame=20
sizes.<BR><BR>Dan<BR><BR><BR>> -----Original Message-----<BR>> =
From:=20
Nader Vijeh [<A href=3D"mailto:[email protected]"=20
eudora=3D"autourl">mailto:[email protected]</A>]<BR>> Sent: =
Wednesday,=20
December 04, 2002 6:10 PM<BR>> To: Romascanu, Dan (Dan)<BR>> =
Cc:=20
[email protected]; [email protected]<BR>> Subject: RE: [RPRWG] =
RE:=20
[IPORPR] payload length and padding and stuff<BR>> <BR>> =
<BR>>=20
Dan,<BR>> <BR>> Thank you for the correction. Jumbo frames are =
not=20
supported <BR>> by the 802.3<BR>> standard.<BR>> There are =
Ethernet=20
switches on the market that support jumbo <BR>> frames in =
a<BR>>=20
proprietary manner. Of course these will not interoperate <BR>> =
with=20
standard<BR>> compliant 802.1 bridges. As I pointed out in the =
rest of=20
the <BR>> message, even<BR>> if jumbo frames are supported, =
max frame=20
size "needs to be <BR>> configurable to<BR>> be lower, in =
order to=20
comply with transparent bridging requirements".<BR>> <BR>>=20
Nader<BR>> <BR>> -----Original Message-----<BR>> From: =
Romascanu,=20
Dan (Dan) [<A href=3D"mailto:[email protected]"=20
eudora=3D"autourl">mailto:[email protected]</A>]<BR>> Sent: =
Wednesday,=20
December 04, 2002 12:45 AM<BR>> To: Nader Vijeh; Necdet Uzun; =
Anoop=20
Ghanwani<BR>> Cc: Frank Kastenholz; [email protected];=20
[email protected]<BR>> Subject: RE: [RPRWG] RE: [IPORPR] =
payload=20
length and padding and stuff<BR>> <BR>> <BR>> > <BR>> =
>=20
The max frame size may be extended beyond 802.3 1522 bytes <BR>> =
>=20
limit as there is<BR>> > precedence in 802.3 =
community.<BR>>=20
<BR>> Nader,<BR>> <BR>> I am not sure what you exactly =
mean. If you=20
refer to what is <BR>> popularly known<BR>> as 'Jumbo frames', =
they=20
are not supported by the IEEE 802.3 <BR>> standards. <BR>> =
<BR>>=20
Dan<BR>> </BLOCKQUOTE><X-SIGSEP>
<P></X-SIGSEP>Regards,<BR>Tony<BR></P></BLOCKQUOTE></BODY></HTML>
------_=_NextPart_001_01C29F5D.DC36F969--