Date: Mon, 10 Jun 1996 21:49:01 -0700 To: jlarson@fnal.gov From: Richard Hausman Subject: 802.1p/D3 Ballot SUBJECT: P802.1p/D3 - Traffic Class and Dynamic Multicast Filtering Services in Bridged LANs __X__ I disapprove for the following reasons. Richard Hausman ---------------------------------------------------------------------- General Comments ================ 1 Need more analysis of the application of priority queueing. 802.1p/D3 addresses two distinct, and perhaps separable, objectives. These are pruning of multicast distribution and prioritized queueing. The multicast pruning is attractive, and addresses an important user need as users build larger bridged LANs. GARP provides an elegant solution to a specific, difficult problem. The prioritized queueing is part of a much larger picture. We are seeking to create a new MAC layer service. This service must integrate with higher layer services, and with the new applications, such as multimedia, which will benefit from "better quality" from the delivery service. I believe defining and integrating this new service deserves more consideration in the context of its actual application than it has yet received. 2 Need more analysis of relationship between 802.1p and 802.1q. 802.1q has embarked on another major new MAC service definition. This new service, as initially conceived, at the least provides frame forwarding constraints based on group identifiers carried in the MAC layer headers. This effort must not only integrate with other layer and application components to provide new user benefits, but must work with each of the two elements of 802.1p. The relationship is not now clear. As such, I believe we need to examine this integration of 802.1p and 802.1q. Technical Comments ================== 3 Remove MAC Address-signaled priority: --------------------------------------- The use of MAC address-signaled priority was strongly challenged at the interim meeting in Mass. Per presentations and discussions at this meeting, use with unicast addresses appears to not work, due to lack of scalability and incompatibility with layer 3 protocols. And the primary case we have for considering priority with multicast traffic - IP Multicast based protocols - were seen to have traffic of potentially different "classes" all using the same MAC multicast. (Both control and data frames use the same MAC address. Further, multiple unrelated IP multicast sessions map to each single MAC multicast.) Tying priority to MAC addresses is at odds with the intent of the address field as an identifier, with the frame-based priority indications of 802.5, and (perhaps more importantly) with the discussed frame-based priority indications of 802.1q. My current position is that all references to a priority association to 48-bit MAC addresses (unicast or multicast) should be removed from 802.1p. 4 Improve User priority to Traffic Class Mappings: -------------------------------------------------- On page 22, the draft states "It is recommended that bridges which support expedited traffic implement two traffic classes..." even while the draft also allows up to 8 classes. I suggest we acknowledge that, from the nature of the service, the more the better. While it has been noted that 2 may be better than 1, presentations at the last interim suggest more than 1 class may be required for multimedia alone, with data traffic at another, lower priority class and management traffic presumably at a higher level. As such, I believe the standard should specify a minimum of three classes (data, core-multimedia, management) and recommend 8. The default mapping table could take account of all legal implementations: User Classes Available Priority 3 4 5 6 7 8 ======== ========================= 0 0 0 0 0 0 0 (default for unspecified) 1 1 1 1 1 1 1 2 1 1 1 1 1 2 3 1 1 2 2 2 3 4 1 2 2 3 3 4 5 1 2 3 4 4 5 6 1 2 3 4 5 6 7 2 3 4 5 6 7 (default for management traffic) In every case, management traffic is arranged to have superior priority. Also in every case, any user priority but 0 is superior to unspecified priority traffic. Note that by not including a 2 class bridge as conformant we don't say no market exists for such (just as bridges that don't learn or that don't run spanning tree have a market), but we are saying that to provide this priority queueing service effectively in the networks we envision over the coming years, more is required. 5 Define a frame signaled priority: ----------------------------------- I recommend, but do not require for approval, that 802.1p incorporate specification of the basic 802.1q frame format in a fashion carrying priority. This format would later be extended in the 802.1q specification for additionally carrying VLAN identification; in 802.1p we leave the VLAN ID "reserved". Specifically, I recommend use of 8 (consecutive) Ethertypes, allowing for a 13 bit "Frame-is-MAC-tagged" Type plus 3 MAC priority bits (the low order 3 bits) in the Ethertype position. The 16 bit VLAN ID remains a 16 bit reserved field, for .1q to define. Even in making this recommendation, I am nervous. Settling on this, or another .1q tag related priority scheme, requires a careful investigation of what the protocols and applications need from our MAC layer in terms of such a good-, better- and best-effort "quality" related MAC service. (We still guarantee nothing!) It may be better to leave this for 802.1q altogether.