Subject: [IPORPR] payload length and padding and stuff

From: Frank Kastenholz <[email-masked]>
Date: Tue, 03 Dec 2002 18:45:56 -0500

i'm editing the iporpr document and have come across a question...

suppose i have an 802.17 ring comprised of both gig-e and sonet
sections. gig-e, i assume, has the usual ethernet min frame
size rules, so if a dataframe is transmitted onto gig-e and
the payload is too short, it gets padded so that the frame
is 64 bytes. if a frame is transmitted onto a sonet section,
no such padding is needed, since there are no min frame length
rules for sonet. so what happens when a frame that was initially
transmitted on a sonet section reaches a gig-e section of
the ring:

      +-----------+      +-----------+       +-----------+
      | Station 1 |      | Station 2 |       | Station 3 | 
      +-----------+      +-----------+       +-----------+
       /        \          /        \          /        \
...___/          \________/          \________/          \___...
                   sonet                gig-e

A frame generated at station-1 that has, let's say, only a 20 byte
payload, would be 42 bytes long. This is fine for sonet. What
happens when the frame reaches the gig-e section between stations 2
and 3?
- is the frame padded by the mac/phy layers in station 2?
- is the frame dropped?
- are the min-frame rules dropped for gig-e when it's being used
  for .17?
- is it illegal to mix sonet and gig-e in the same ring?
- am i very confused and is the answer obvious to all but me?

thanks

frank kastenholz
_______________________________________________
IPORPR mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/iporpr

---

From: Nader Vijeh <[email-masked]>
Date: Tue, 3 Dec 2002 16:04:49 -0800

Frank,

.17 specifies homogeneous rings. Mixed phys and different speeds on spans
and ringlets are disallowed. As for the frame size, there has been some
discussion on this topic and there will probably need to be a phy dependent
frame size requirements. For now, this is a configurable parameter. 

Also, no padding is specified by the .17 MAC for frames in transit. Whether
there needs to be padding by the MAC for transmitted frames is still open.

Hope this helps.

Nader Vijeh

-----Original Message-----
From: Frank Kastenholz [mailto:[email-masked]]
Sent: Tuesday, December 03, 2002 3:46 PM
To: [email-masked]
Subject: [IPORPR] payload length and padding and stuff

thanks

frank kastenholz

---

From: [email-masked]
Date: Tue, 3 Dec 2002 16:07:34 -0800

The min frame requirement of Ethernet is not carried into RPR. (This is baggage left over from Ethernet's CSMA/CD days that is no longer used.) Also agreed at the last meeting is that any PHY that does require a min length must implement padding and unpadding in its reconciliation sublayer (RS) so as not to effect other links running other PHYs.

John Lemon

-----Original Message-----
From: Frank Kastenholz [mailto:[email-masked]]
Sent: Tuesday, December 03, 2002 3:46 PM
To: [email-masked]
Subject: [IPORPR] payload length and padding and stuff

thanks

frank kastenholz

---

From: Nader Vijeh <[email-masked]>
Date: Tue, 3 Dec 2002 19:44:52 -0800

I think this requires additional work as 802.17 needs to comply with the
specifications for Phys that are adopted. Less than 64 bytes minimum frame
size precedence for Ethernet phys needs to be investigated. This may be
resolved through liaison with 802.3.

The max frame size may be extended beyond 802.3 1522 bytes limit as there is
precedence in 802.3 community. However, it needs to be configurable to be
lower, in order to comply with transparent bridging requirements. 

Whether SONET/SDH phys or 802.3 phys are used, 802.17 frames need to pass
through 802.1 relay, without source MAC knowledge of the destination's MAC
frame size capability. I don't believe there are any 802.1 protocols for
negotiating MAC max frame size. 

Nader

-----Original Message-----
From: Necdet Uzun [mailto:[email-masked]]
Sent: Tuesday, December 03, 2002 5:14 PM
To: Anoop Ghanwani
Cc: 'Frank Kastenholz'; [email-masked]; [email-masked]'
Subject: Re: [RPRWG] RE: [IPORPR] payload length and padding and stuff

Anoop,

Another thing to note that RPR over Ethernet does not require padding of
RPR frames as we do not have the same 64 byte minimum packet size
requirement as Ethernet.

Thanks.

Necdet

Anoop Ghanwani wrote:

> Frank,
>
> We shouldn't be trying to mix different PHYs,
> e.g. 10GE and OC-192, since they are in fact running
> at different data rates, and having PHYs with different
> data rates on the same ring is not allowed by the
> current version of the draft.  I think the draft
> is silent on this specific issue, though.
>
> I'm cc.-ing the 802.17 list since this is an interesting
> issue that has come up there as well.  Maybe someone
> else might be able to shed some light on this
> (PHY people??).
>
> -Anoop
>

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Wed, 4 Dec 2002 10:44:46 +0200

> 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

---

From: Nader Vijeh <[email-masked]>
Date: Wed, 4 Dec 2002 08:09:49 -0800

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-masked]]
Sent: Wednesday, December 04, 2002 12:45 AM
To: Nader Vijeh; Necdet Uzun; Anoop Ghanwani
Cc: Frank Kastenholz; [email-masked]; [email-masked]
Subject: RE: [RPRWG] RE: [IPORPR] payload length and padding and stuff

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

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Wed, 4 Dec 2002 18:25:20 +0200

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

> From: Nader Vijeh [mailto:[email-masked]]
> Sent: Wednesday, December 04, 2002 6:10 PM
> To: Romascanu, Dan (Dan)
> Cc: [email-masked]; [email-masked]

---

From: Tony Jeffree <[email-masked]>
Date: Thu, 05 Dec 2002 09:36:05 +0000

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:

>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
>
>

Regards,
Tony

---

From: Tony Jeffree <[email-masked]>
Date: Thu, 05 Dec 2002 09:45:56 +0000

Dan -

Some further clarification here:

This very issue came up as a formal Interpretation request on 802.1D and 
802.3 recently. The 802.1 agreed interpretation is documented here:

http://www.ieee802.org/1/pages/int-2.html

Hence, it is the frame size defined by the 802.3 standard (or more 
generally, the size defined in the standard for the destination port's MAC) 
that is used by a conformant Bridge in order to identify (and discard) 
oversize frames.

Regards,
Tony

-------------------------------------------------
Dan -

Regards,
Tony

Regards,
Tony

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Wed, 4 Dec 2002 18:25:20 +0200

Nader,

Dan

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Mon, 9 Dec 2002 10:34:59 +0200

Tony,
 
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.
 
Regards,
 
Dan

-----Original Message-----
From: Tony Jeffree [mailto:[email-masked]]
Sent: Thursday, December 05, 2002 11:36 AM
To: Romascanu, Dan (Dan)
Cc: Nader Vijeh; [email-masked]; [email-masked]
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

Nader,

Dan

> From: Nader Vijeh [ mailto:[email-masked]]
> From: Romascanu, Dan (Dan) [ mailto:[email-masked]]

Regards,
Tony

---

From: Tony Jeffree <[email-masked]>
Date: Thu, 05 Dec 2002 09:36:05 +0000

Dan -

Regards,
Tony

Regards,
Tony

---

From: Tony Jeffree <[email-masked]>
Date: Mon, 09 Dec 2002 11:06:23 +0000

Dan -

If your question translates as "Can a Bridge be built that supports more 
than one type of MAC", then the answer is Yes. And indeed, there are 
Bridges that support plug-in blades for each port, and which can therefore 
potentially support a wide variety of frame sizes.

However, at least as far as the standard is concerned, there is no 
configurable per-Port parameter involved; if a Port supports an 802.X MAC, 
then the frame size supported on that Port is as stated in the standard for 
the 802.X MAC (i.e., there is no standard means to configurable the frame 
size independently of the MAC type).

So, if you are asking "Is it possible to build a Bridge that will forward 
jumbo frames?" then clearly, the answer is "Yes". However, that is a 
different question to asking "Is forwarding jumbo frames conformant 
behaviour for a Bridge?"; the interpretation of the 802.1D standard 
relative to that question is "No".

Regards,
Tony

At 10:34 09/12/2002 +0200, Romascanu, Dan (Dan) wrote:
>Tony,
>
>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.
>
>Regards,
>
>Dan
>

Regards,
Tony

---

From: Tony Jeffree <[email-masked]>
Date: Thu, 05 Dec 2002 09:36:05 +0000

Dan -

Regards,
Tony

Regards,
Tony