Folks, I believe there is one and only one aspect of 802.1's current work that benefits from action by the MAC groups, and that is the frame size issue. It's great that someone is willing to take this issue on in 802.3, because that's the only place it can be tackled. The VLAN work is to be standardised in 802.1, so that it can be applied consistently across the different dot groups. That's why we have a family of 802 standards; each concentrating on its own area. It would be wrong for MAC groups to standardise the VLAN header format or the meaning of its fields. In particular it would be most unfortunate if 802.3 were to formalise descriptions of these fields which conflict with the 802.1 definitions (e.g., the Canonical Field Indicator). The last thing we need is different flavours of VLAN on different media. However, informational material on the VLAN header would be of great help in justifying changes to frame size. Perhaps if a group such as 802.3ac considers these issues, the best thing to do would be to reference 802.1Q. Regards, -- John Messenger Return-Path: X-Sender: pe.pjsingh@packetengines.com X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Tue, 01 Jul 1997 18:55:30 -0700 To: P8021@hepnrc.hep.net From: "PJ Singh" Subject: FWD >> Proposal for inclusion of VLAN Tagged Frames Content-Type: text/plain; charset="us-ascii" Hello 802.1ers: I picked this e-mail up from the .3 reflector and it has some interesting propositions. It seems like that 802.3 will start a new project to standardise the ("much neded") larger (1522 bytes)frame size. I think that we should welcome this effort and support them in supporting us. This is what 802.1 has requires of 802.3 for long time. I think the intent is to keep same ethertype as 802.1. Tag format is same as what we have defined. Comments?? ..pj >Return-Path: >Received: from agate.cisco.com ([171.69.198.44]) by hurricane.spokes.com > (post.office MTA v2.0 0813 ID# 184-13416) with ESMTP id AAA61 > for ; Tue, 1 Jul 1997 17:42:53 -0700 >Received: (hfrazier@localhost) by agate.cisco.com (8.8.4-Cisco.1/8.6.5) id RAA29380; Tue, 1 Jul 1997 17:42:08 -0700 (PDT) >Date: Tue, 1 Jul 1997 17:42:08 -0700 (PDT) >From: Howard Frazier >Message-Id: <199707020042.RAA29380@agate.cisco.com> >To: stds-802-3-hssg@ieee.org, stds-802-3@ieee.org >Subject: Proposal for inclusion of VLAN Tagged Frames >Cc: lidinsky@hep.net, geoff_thompson@baynetworks.com >X-Sun-Charset: US-ASCII > > > Proposal for Inclusion of VLAN Tagged Frames in 802.3 > >Background information >====================== > >IEEE P802.1Q/D6 specifies the following things regarding VLAN Tagged >frames which are of interest to IEEE 802.3. > >1) VLAN tagged frames are a minimum of 64 bytes in length. > (reference subclause 2.2) > >2) VLAN tagged frames have the following Tag Header format: > (reference clause 4) > > Tag Protocol Identifier (TPID) - 2 bytes corresponding to a unique "Type" > Tag Control Information (TCI) - 2 bytes defined as follows: > User priority - 3 bits > Cannonical Format Indicator (CFI) - 1 bit defined below > VLAN Identifier - 12 bits > >3) The CFI bit is further defined as: > (reference clause 4) > > i) in Token Ring/FDDI media, to signal the bit order of address > information carried in the encapsulated frame; and > ii) in 802.3/Ethernet media, to signal the presence or absence of a > RIF [Source-Routing Information Field] field, and, in combination > with the information carried in the RIF, to signal the bit order > of address information carried in the encapsulated frame. > >4) Furthermore, regarding the RIF: > (reference clause 4) > > f) In 802.3/Ethernet media, a Source-Routing Information Field (RIF) is > included, if required by the state of the CFI flag in the TCI. > If present, in addition to carrying Source-Routing information, > this field includes a further CFI flag that signals the bit order > of address information carried in the encapsulated frame..... > > >Observations >============ > >802.1Q/D6 appears to be silent on the subject of maxFrameSize for >802.3 LANs. As a consequence, either: > > A) Legacy (non VLAN-aware) end stations must reduce their MTU by 4 > bytes so that they never send more than 1514 > > B) 802.1Q bridges violate 802.3 by emitting frames of 1522 bytes > >I also observe that the length of the RIF may be from 2 to 30 octets. The >RIF follows the TYPE/LENGTH field (which appears after the TCI). This >implies that the Tag Header can be from 4 to 36 bytes in length >(including TPID, TCI, TYPE/LENGTH, and RIF), as shown in Figure 4-1 of >802.1Q/D6. > >Lastly, I observe that there are numerous individuals in the 802.3 >community who are actively working on MAC implementations. This >heightened activity is likely the result of the new projects which >have been developed, or are being developed in 802.3, such as >802.3u (100BASE-T), 802.3x (Full Duplex), and 802.3z (Gigabit). Many >of these individuals have approached me with questions about the impact >of VLAN tags on the 802.3 frame format and frame size. > >My opinions >=========== > >Regarding maxFrameSize, I believe that A) is not likely to happen. I >very much doubt that all of the end station device drivers in the >world are going to be changed so that they report a smaller MTU. >B) produces an unnecessary conflict between 802.1 and 802.3, and there >is no good reason why this should occur. > >802.1 has debated the subject of minFrameSize at great length, and >has come to the conclusion that minFrameSize should remain 64 bytes, >regardless of whether a frame is tagged or not. I fully support this >position, having studied the pros and cons, and heard arguments each way. > >I am concerned about the definition of the CFI bit, and the inclusion >of Source-Routing Information in 802.3/Ethernet frames. > >Aside from the CFI bit and the inclusion of a RIF, I fully support the >Tag Header format described in P802.1Q/D6, and all of its constituent >elements. > >My proposal >=========== > >I believe that it is time for 802.3 to act on the subject of >VLAN frame format and frame size, and to act in concert with 802.1Q. >We should make the necessary changes to our standard to accommodate >VLAN tagged frames, and we should do it in a way which facilitates >the work in 802.1Q. To that end, I propose that 802.3: > >1) Initiate a new project, tentatively identified as P802.3ac > >2) Within 802.3ac, identify the format for VLAN tagged frames as > carried on 802.3 LANs, irrespective of data rate. > The format of the Tag Header being as follows: > > Tag Protocol Identifier (TPID) - 2 bytes corresponding to a unique "Type" > Tag Control Information (TCI) - 2 bytes defined as follows: > User priority - 3 bits > Cannonical Format Indicator (CFI) - 1 bit defined below > VLAN Identifier - 12 bits > > The Tag Header is inserted between the last octet of the > Source Address (SA) field and the first octet of the TYPE/LENGTH field. > > The CFI bit would be defined as "Reserved/Send as Zero" for 802.3 > LANs, with a note in 802.3ac stating that: > > Note: Behavior in response to receipt of a frame with CFI=1 is > outside the scope of this standard. > >3) Within 802.3ac, specify that the maxFrameSize for VLAN tagged > frames is 1522 bytes, irrespective of data rate. Additionally, > perform the required adjustments to maxFrameSize in 4.4 so that > management attributes in Clause 30 accommodate frames of this size. > >This would be the full extent of the 802.3ac project. > >Summary >======= > >I intend to make this proposal to the IEEE 802.3 CSMA/CD Working Group >on Tuesday, July 8th, 1997. I believe that this project >will align the work in 802.3 and 802.1, will provide the information which >MAC implementors seek, and will solidify the industry behind a common >VLAN tag header format. I believe that the elements addressed in my >proposal are within the scope of responsibility of the 802.3 Working Group, >and should be formalized within the 802.3 standard as quickly as >possible, so that the work on 802.1Q can progress without delay or >uncertainty. > > >Sincerely, > >Howard Frazier >Cisco Systems, Inc. > ______________________________________________________________________ Paramjeet (PJ) Singh 509-922-9190 (Voice) x239 Packet Engines Inc. 509-922-9185 (Fax) PO Box 14497, Spokane, WA 99214-0497 http://WWW.PacketEngines.com ______________________________________________________________________