APPLYING IEEE 802.1P I. INTRODUCTION Let us analyze how 802.1p/D3 can be used to provide class of service facilities. We will conduct this analysis by means of a series of choices (A, B, etc.), exhaustively listing the possibilities for associating Classes of Service with destination MAC addresses. II. ONE CLASS OF SERVICE PER ENDSTATION OR MANY The first choice is whether or not an endstation will receive unicast traffic at multiple classes of service, or be limited to a single class of service. 802.1p/D3 requires an endstation to have multiple MAC addresses if it is to receive unicast frames on different classes of service. ******** CHOICE A: 1. An endstation is limited to a single class of service for unicast frames. 2. An endstation may receive frames on different classes of service for unicast frames. Choice 1 is clearly not an acceptable limitation on the applications that wish to use CoS, which forces us to select choice 2. III. ALGORITHMIC OR ARBITRARY MAC ADDRESS ASSIGNMENT We can divide the ways that a workstation can have two (or more) different MAC addresses into two categories: ******** CHOICE B: 2.1 Use MAC addresses with no algorithmic relationship (e.g. 0134.5600.5432 and 0134.5600.8441) 2.2 Use MAC addresses with an algorithmic relationship, said algorithm being well-known to all bridges, switches, and endstations (e.g. differ by one or a few bits in a standard place). Reading 802.1p/D3 might lead one to expect that 2.1 is the only choice. An endstation has a repertoire of MAC addresses which it registers with the bridges/switches. There are a number of objections to choice 2.1: a. Most existing endstations have only a single globally-administered MAC address each. In order to gain multiple MAC addresses, locally-administered addresses could be used. However, no protocol has been proposed, and no standard mechanism exists in the existing Ethernet world, to assign these addresses. b. The address storage and maintenance requirements on bridges and switches are increased dramatically as stations begin registering up to 8 addresses each. c. The protocol overhead required to register the endstations' MAC addresses is burdensome, and if VLANs are employed and the number of endstations greatly increased, this overhead becomes unacceptable. d. Many endstations with older 802.3 MAC interfaces support only a single MAC address. In order to accept multiple MAC addresses, the interface must be placed in promiscuous mode, placing a significant burden on the endstation to filter unwanted unicast traffic in software. Although these objections are weighty in total, all can be corrected or ignored. Choice 2.1 has not yet been eliminated from consideration. IV. MULTIPLE, SEPARATE MAC ADDRESSES AND HIGHER-LAYER PROTOCOLS If we assume that an endstation will be using protocol layers above the MAC layer, we run into the problem of assigning the multiple MAC addresses required for multiple CoS levels to the endstation's Layer 3 address(es). The existing layer 3 protocols that work over Ethernet - IP, IPX, AppleTalk, DECNet, for example - are unable to support multiple MAC addresses mapping to a single L3 address. Thus, even if an endstation can find additional MAC addresses, choice 2.1 leads one to have to make a very uncomfortable choice at L3. ******** CHOICE C: 2.1.1 Use a single L3 address for an endstation, with multiple MAC addresses. This requires significant changes to every existing L3 protocol and/or its L3-L2 mapping function (e.g. IP ARP). It is impossible in protocols such as IPX in which the MAC address is incorporated into the L3 address. 2.1.2 Use multiple L3 addresses for an endstation, corresponding to the different CoS levels desired, with one MAC address per L3 address. Most endstation software stacks are unable to support this possibility. It is deprecated under IP. Furthermore, this doubles (or worse) the number of L3 addresses required. Finally, multiple L3 addresses require, in turn, either multiple endstation names, or new algorithms for mapping one endstation name to multiple L3 addresses. Neither of these choices is at all practical. The higher layers are not going to make the fundamental changes required to support choice 2.1. Thus, choice B must be made in favor of 2.2 - an algorithmic mapping between the multiple MAC addresses. V. CONVERTING MAC ADDRESS BITS TO COS INDICATORS If there is an algorithmic mapping between the multiple MAC addresses required to give the endstation multiple classes of service, the endstation can retain a single name, single L3 address, and for all purposes except making the choice of CoS, a single MAC address. This is required to retain compatibility with existing L3 protocols. Note also that, with algorithmic mapping, we can dispense entirely with explicit unicast registrations! Since 802.1p/D3 allows registrations to be established through configuration (by unspecified means), we can "configure" each endstation and switch to know the algorithm for relating the various MAC addresses for an endstation to each other, and to specific classes of services. Then, for example, when an 802.1D transparent bridge learns of any of an endstation's MAC addresses, it can automatically construct the necessary mappings for all classes of service for that endstation. The term "algorithmic mapping" does not mean a complex mathematical function. Let us instead explore the possibility of disassociating a minimum of one bit of the destination MAC address from its normal station identification function and assigning it the task of distinguishing between two classes of service. For example, we could decide that the least-significant bit of the MAC address is a CoS bit, and that every endstation requires a pair of MAC addresses, whether globally assigned or locally assigned. ******** CHOICE D: 2.2.1 Assign each endstation a set of locally-administered MAC addresses, one for each level of CoS supported. Since the addresses are administered locally, any division of the 46 available bits (48 less I/G and U/L bits) between endstation identification and priority indication is possible. 2.2.2 Assign each endstation a set of globally-administered MAC addresses, with a standardized division of the 46 available bits between endstation identification and priority. 2.2.3 Assign each station a mixture of globally- and locally-administered MAC addresses, with a standardized division of the 47 available bits between endstation identification and priority. (Mixing global and local MAC addresses makes the U/L bit available.) VI. ALL MAC ADDRESSES LOCALLY ADMINISTERED Choice 2.2.1 is a definite possibility, but it raises the question of how to assign the locally-administered MAC addresses to the workstations. A number of techniques can be imagined that would work. At this time, however, no interoperable (i.e. standard) solution exists, and the problem is clearly non-trivial. VII. CONVERTING GLOBAL MAC ADDRESS BITS TO COS INDICATORS Examining choice 2.2.2, there are three regions of the MAC address that can potentially be used as CoS indicators within the space of globally-administered destination MAC addresses: ******** CHOICE E: 2.2.2.1 The 22 bits of the OUI. 2.2.2.2 The I/G bit. 2.2.2.3 The 24 vendor-assigned bits. (The U/L bit is constrained by choice 2.2.2 to be "Global".) 2.2.2.1 is a possibility, although it cuts the available number of OUIs from 4M to 2M, or less, if more than 2 levels of CoS are desired. Furthermore, it affects other media besides 802.3 media, which are the media with the immediate problem. (802.5, 802.12, and FDDI already have MAC layer priority.) Choice 2.2.2.2 can be dismissed, because the I/G bit carries critical semantic meaning. Choice 2.2.2.3 can also be dismissed, as a number of vendors have exhausted more than one OUI. There exists no bit or combination of bits that can be converted to a CoS indication that is compatible with existing endstations. IEEE 802.1p clearly must not require for its employment new hardware in every endstation. VIII. CONVERTING THE U/L BIT TO A COS INDICATION There remains choice 2.2.3 to examine. The only case that has not been covered by the examination of cases 2.2.1 and 2.2.2 is the case in which the meaning of the U/L bit itself is, in effect, changed to a CoS indication bit. Another way to describe this option is to say that every endstation assigns itself a locally-administered MAC address that is identical to its globally-administered MAC address, except that the U/L bit is set to "Local" for the second address. One of these addresses can be assigned to the higher-priority class of service, and the other to the lower-priority class of service. Choice 2.2.3 certainly has drawbacks. For one, it prevents CoS from being used by existing protocols that depend on the current definition of the U/L bit, such as DECNet Phase IV. However, such objections are not insurmountable. IX. SUMMARY: IEEE 802.1p/D3 REDEFINES THE U/L BIT We have found only three possible ways to actually use 802.1p/D3 to provide 802.3 media with Class of Service capabilities: Choice 2.2.1 - Eliminate global in favor of local MAC addresses. This requires the creation of a local MAC address assignment protocol before interoperability can be achieved. Choice 2.2.2.1 - Convert one OUI bit to a priority indication. This cuts the number of available OUIs in half, adversely impacting all 802 media, as well as FDDI, and clearly requires explicit action by 802 before it can be used interoperably. Choice 2.2.3 - Convert the U/L bit to a priority indication. This redefinition significantly impacts old endstations that support only a single MAC address, and protocols which utilize locally-administered MAC addresses. Of these three choices, only one choice enables most users of most protocols to obtain Class of Service capability in a completely standard manner, without significant additional effort by 802 and/or other standards bodies. This is choice 2.2.3. The net effect of 802.1p/D3 is to alter the meaning of the U/L bit to a Class of Service indication. Such a redefinition demands considerably more discussion than it has received to date within 802.1.