To: "Norman W. Finn" Cc: P8021 From: Peter Wang/HQ/3Com Date: 10 Apr 96 20:58:14 EDT Subject: Re: ["Robin Tasker": Priority in 802.1p] >>That's more-or-less exactly what ATM Forum is attempting to do with the >>MPOA (Multi-Procotol Over ATM) group; its trying to make IETF's NHRP and >>Mars work with IEEE VLANs and ATM Forum LAN Emulation. Is IETF reciprocating? Attempting to work with other standards body is certainly desirable. Depending on working the whole solution out by coordinating multiple standards is not something I think I'd want to count on. >>I would think that a priority mechanism that is orthogonal to addressing, >>such as using the free source MAC address bit, would be more useful. >>Perhaps including a priority field in a VLAN tag is an alternative. RSVP >>could make use of either without altering the well-established mechanisms >>for delivering packets to the right destination. Both can be useful. The concepts are similar in that they all provide a simple CoS mechanism. What is the state of 802.3 standardizing on using the I/G bit of the source MAC address to indicate priority? If one uses the source MAC I/G bit as CoS flag, is it still necessary to add a separate field in the VLAN tag? >>There is another problem, of course, with registering priorities with >>unicast MAC addresses -- the registration of those addresses. The >>thought of propagating 8 * (the number of endstations) worth of unicast >>MAC address registrations in order to establish the infrastructure >>required for QoS packet delivery is obviously absurd. I believe the current draft recommended using two priority levels as default. Also, putting the priority in GARP was originally intended for multicast addresses, as the name GARP suggests. The fact the GARP happens to support registration of unicast addresses was strongly advocated by David Cheriton, the author of EGMP, which GARP evolved from. >>So, if defining priorities in the 802.1p manner for unicast addresses >>is not a good idea, and if a method such as the I/G bit would work for >>both unicast and multicast, why does 802.1p have priorities at all? The reason 802.1p incorporates priority is to specify the behavior of bridges when expedited forwarding is to be implemented in the bridge to take advantage of the priority mechanisms supported by the underlying MAC. Token Ring and FDDI both include priority field in their MAC headers. Ethernet doesn't (yet). Even if 802.3 standardizes on using the source MAC address's I/G bit as priority flag, the need still remains for 802.1p to describe the bridge behavior in term of mapping priorities to internal queues to dissimilar MAC. What 802.3's action might alleviate is the need to specify priority within GARP. However, using the source MAC I/G bit is source driven. RSVP is very much destination driven, i.e. destination sending the request towards the source. Personally, the source driven approach seems just fine for unicast deliveries. It may be OK for the majority of the multicast delivery scenarios, though I'm not totally convinced that it is. Hence, the question is whether we should allow for both source-driven and destination driven approaches? Peter