To: P8021 From: Steve Horowitz Date: 7 Jun 96 13:11:21 Subject: Priority Bits Discussion This email is in regards to using the 3 bits of the VLAN tag as proposed in Lynnfield: Using 3 bits of the VLAN tag: Reduces VLAN tag space to 13 bits. Personally, I thought 16 was too small. I believe that we will kill the long term prospects of VLANs if we continue to steal "name" space from the field. I've said this before ... at one time, 256 bridge ports was seen as enough (see spanning tree BPDU). Another way of saying this is that the argument for 3 bits of priority (when 4 or 5 would do for all applications imagined today) is for architectural growth. However, the same argument can be made for keeping the VLAN ID 16 bits wide. Provides 2 ways of specifying best effort CoS: no tag and tag with 0 in priority field. Comes late in the frame (which is OK since it appears that there is no other way to do this.) However, it does imply a buffering decision that has to wait at least 15 bytes. Forces VLAN devices to have an "if-then-else" VLAN mapping clause. That is, if a device uses subnet or protocol type in its VLAN mapping mechanism, it must look at the VLAN tag first (if it exists) and if 0, offset to the appropriate bytes. Priority is policy of VLAN OK except forces CoS to be tied to VLAN infrastructure - may not be desirable to force this. Makes buffering decision even later since VLAN now needs to be looked up. Use separate frame format to tag priority. Two protocol IDs, VLAN only and VLAN/Priority - new frame with 48 bits of tag info. Three protocol IDs? VLAN, VLAN/Priority, Priority only? Huh? VLAN & Priority protocol IDs totally separate? Issues of Priority within VLAN or VLAN within Priority. Priority & VLAN really need to be on the "outside" of the frame. I prefer 3.1 . If we go with 1, I recommend to use only 2 bits. -- Steve