Re: [FE] Plans for San Antonio, etc
Kevin, there is no problem with the original frame having a length field.
The issue I was raising is the case where the added header uses length/LLC instead of using type. For example the VLAN tag is defined both with an Ethernet format and a SNAP formats. If someone sent the SNAP format VLAN header, it would have a length field that would cover the whole packet including the SNAP header and VLAN tag. Normally one wouldn't send this format on Ethernet (and our existing length adjustment for VLAN tags doesn't accomodate the extra bytes this would take) but I can't find a SHALL NOT statement in 802.1Q that prohibits it.
If someone adds a wrapper protocol using LLC or SNAP to identify it instead of a raw Type field, then it would have a length field covering the entire encapsulated packet.
One way to deal with this is to require that wrapper protocols are only allowed to use Type fields. As far as I know, all the 802.1 protocols accomodate this. I think this is the approach Geoff indicated he preferred and that approach is also the one I favor, but if that is not acceptable we would need to use one of the other ways to handle the extra length.
Pat
-----Original Message-----
From: **** IEEE 802.3 Frame Expansion Study Group ****
[mailto:STDS-802-3-FE@listserv.ieee.org]On Behalf Of Kevin Daines
Sent: Tuesday, 16 November, 2004 7:37 AM
To: STDS-802-3-FE@listserv.ieee.org
Subject: Re: [FE] Plans for San Antonio, etc
Pat,
Unfortunately, 3.2.6 references a poorly named constant, maxValidFrame. Rather than specifying 1518 for an untagged frame, or 1522 for a 801.Q tagged frame, this constant specifies 1500. See 4.2.7.1.
Since FESG isn't increasing the size of the data field, I believe the Length encoding is still valid.
Although I do agree with Geoff's later e-mail, Length encodings are rarely used today.
Kevin
-----Original Message-----
From: **** IEEE 802.3 Frame Expansion Study Group ****
[mailto:STDS-802-3-FE@listserv.ieee.org]On Behalf Of Pat Thaler
Sent: Friday, November 12, 2004 2:46 PM
To: STDS-802-3-FE@listserv.ieee.org
Subject: Re: [FE] Plans for San Antonio, etc
Kevin,
Another issue occurred to me that I don't recall being discussed yet though perhaps it has been discussed when I was not present.
The longer length frames being discussed will not be compatible with a Length field (which is used when 802.3 is used under 802.2) because the maximum length field value cannot exceed the minimum valid Type field value. (See IEEE 802.3 3.2.6.)
In practice, I think this is acceptable because protocols that are adding the extra headers/trailers to the packets all run using a Type field rather than a Length field. The current IEEE 802.3 Five Criteria still call out IEEE 802.2 compatibility (the 802 version of the Five Criteria does not) so if the frame extension is to be limited to Type field interpretation the response to the compatibility criteria should call this out.
More importantly, what we put in the standard needs to make clear whether the length field may be used with extended frames. There are at least three possible alternatives:
Type field only: Require that frames larger than 1535 bytes use a type value in the Length/Type Field.
Special length value: Allow length in the length/type field but define 1535 to be a special length value that means that the frame is 1535 bytes or longer.
Modulo length field: Allow length in the length/type field for frames longer than 1535 bytes but require that the length field value be the length of the frame modulo 1536.
Personally I favor the type field only alternative because I don't know of any need for the length interpretation with these frames.
Regards,
Pat
-----Original Message-----
From: **** IEEE 802.3 Frame Expansion Study Group ****
[mailto:STDS-802-3-FE@listserv.ieee.org]On Behalf Of Kevin Daines
Sent: Wednesday, 10 November, 2004 4:42 PM
To: STDS-802-3-FE@listserv.ieee.org
Subject: [FE] Plans for San Antonio, etc
All,
Well, so far, no one has requested a presentation slot for San Antonio. We still need presentations on:
Research folllowing topics:
Frame size limitations of:
Existing equipment - below MAC (elasticity buffers, block coding, delimiters)
Existing equipment - above MAC (FIFO, fabric)
Links with FEC (EPON)
If you would like to present, please e-mail me this week.
However, in the event we do not have presentations, we'll still make progress at next week's meeting.
Our goals for San Antonio will be to:
1) Review approaches for modifying Clauses 3 and 4 and Annex 4A
2) Review possible timeline
3) Prepare motions for 802.3 closing plenary (Thu)
- PAR
- 5 Criteria
- Objectives
4) Get approval from 802.3 to forward PAR and 5 criteria to 802 EC (for 11/19 meeting)
5) Get approval from 802.3 to forward PAR and 5 criteria to NESCOM (for December meeting)
The timeline discussion will include topics such as:
- Timeframe for issuing first Task Force draft (D1.0)
- Decision on maximum frame size (i.e., January or March)
Kevin Daines
Chair, 802.3 Frame Expansion Study Group