From: "Norman W. Finn" Subject: Re: ["Robin Tasker": Priority in 802.1p] To: Peter_Wang@3mail.3Com.COM Date: Wed, 10 Apr 1996 17:55:58 -0700 (PDT) Cc: R.Tasker@dl.ac.uk, P8021@nic.hep.net Peter Wang/HQ/3Com writes: > > Robin, > > A well-engineered solution will involve the use of multiple mechanisms > at different protocol layers. I don't know that there's been any precedence > among the standards group to coordinate all of the related standards such > that vendors can implement a well-engineered and yet standard-based > solution. 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. > Philosophical points aside, the simple mechanism that's being provided > by the current .1p is useful if you consider the following: > > - application (or user) request QoS at WinSock level; > - RSVP sets up the QoS with the routers and or the high function switches; > - QoS is mapped to CoS at the link level; > - switches at the edge of the bridged LAN provides the CoS. > > Backbone switches in the center of the network will likely implement some > form of RSVP, i.e. more control than that offered by .1p alone. Also, the > way .1p specifies CoS doesn't prevent any vendor from implementing more > sophiscated management scheme within a switch in addition. Hence, it > makes sense to keep the link layer CoS mechanism simple and let the > higher layer build on it. I would say that "some kind of priority mechanism" is useful if you consider those points. I have difficulties, though, with the way 802.1p ties the priority of a packet to its destination MAC address. Were the priority mechanism not tied to destination MAC address, your arguments make good sense. But in existing protocols, the destination MAC address is tied to how you reach a station, not how important the traffic is. RSVP allows one to define multiple streams between two endstations, each with a different QoS requirement. There is no way to map QoS requirements to 802.1p's priority mechanism without doing violence to fundamental protocols such as ARP. Nor is there any way for IPX or AppleTalk to utilize multiple MAC addresses for QoS. I should say, "There is no way I'm aware of..." Please enlighten me if the problem is my ignorance. 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. 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. 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? -- Norm