Re: [FE] Plans for San Antonio, etc
Pat-
When I look at 802.3 - 2002 I see:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
3.5.4 Length/Type field
The Length/Type field of a
tagged MAC frame always uses the Type interpretation,
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
so I am not sure I understand what you are talking about.
While the inner encapsulated packet might be length encoded, each of the
encapsulating wrapper tags is type encoded.
I have heard no serious proposals for a tag format that includes a length
encoding.
Geoff
At 02:35 PM 11/16/2004 -0800, Pat Thaler wrote:
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