From: "Norman W. Finn" Subject: Implicit vs. Explicit VLAN Frame Tagging To: p8021@NIC.HEP.NET Date: Thu, 25 Jan 96 0:01:00 PST Here is the text of the contribution presented, today, at the interim meeting. Implicit vs. Explicit VLAN Frame Tagging 1.0 Implicit versus Explicit tagging Significant debate has occurred over whether each frame transmitted between VLAN switches should be explicitly tagged with the identity of the VLAN to which it belongs, or whether a frame should be examined by each receiving port, and pattern matching rules applied to determine its VLAN membership (implicit tagging). Both methods are required of any interoperable VLAN standard. 1.1 Justification for frame classification by implicit tagging Given that it is required to attach endstations belonging to different VLANs to the same wire or hubbed LAN segment, and given that we do not have the option to change existing endstations' communications stacks, the only way to differentiate frames on their first entry to a VLAN switch is by applying filters to the frames themselves, in effect looking for VLAN tags implicit in the contents of the frames. Obvious fields in a frame to examine include the source MAC address, the internetworking protocol used (determined e.g. by the LLC/SNAP fields), the internetworking layer source address, or fields from higher protocol layers. Some or all of this information may be important to determining the VLAN to which the frame belongs. 1.2 Justification for frame classification by explicit tagging In a Decnet Phase IV network, a station with two LAN interfaces is required to use the same MAC address on both interfaces. In at least some recent revs of the SunOS operating system, a Sun workstation with two Ethernet interfaces automatically uses the same MAC address on both interfaces. In these cases, the source MAC address of a frame is insufficient to determine the VLAN membership of the frame. In some cases, there is no implicit tag in the frame at all. For example, consider a Sun workstation with two Ethernet interfaces, both using the same MAC address, which has "routed" turned on and is acting as an IP router between those Ethernet interfaces and an FDDI interface. A frame passed down one or the other of the Ethernets may have source and destination IP addresses foreign to the local IP networks; there may be nothing in a frame that can be used to tell whether the frame belongs on one or the other of the two VLANs. If both VLANs are carried along the same backbone by the VLAN switches, there is no substitute for explicitly tagging one or both frames with the identity of the VLAN to which it belongs. Finally, there exist standard means for implementing VLANs, ATM LAN Emulation in particular, that in effect employ tagging. 1.3 Which is "better", implicit or explicit tagging? Given the above justifications both for explicit and implicit tagging, the relevant question is not whether we should standardize implicit or explicit tagging, but rather, how to make both work together in the same installation. 1.4 Temporary definition of explicit tagging For the purposes of the arguments presented here, we will assume that an explicitly tagged frame includes: 1. Source and destination MAC addresses. The destination MAC address may be the same as that of the encapsulated frame, a multicast address identifying "interested VLAN switches", the MAC address of a particular VLAN switch, or the MAC address of a subsection of a VLAN switch. (These issues are presented in a separate contribution.) 2. A tag value which identifies which VLAN the encapsulated frame belongs to. 3. An indication of at least whether the encapsulated frame is in 802.3/Ethernet format or 802.5 format. (The question of whether other formats are to be supported is TBD.) This indication may be explicit, or may be implicit in the VLAN tag value (again, TBD). 4. The encapsulated frame, bit-for-bit identical to its native un-encapsulated form on its native medium (802.3/Ethernet, 802.5, etc.). 5. Whether the frame contains one or more FCS fields is TBD. 6. A frame may be encapsulated on a LAN type (802.3/Ethernet, 802.5, etc.) that is different from its frame type before encapsulation. In this case, the encapsulated frame undergoes no change. The type of the encapsulation, including at least the source/destination MAC addresses and tag fields, matches the type of the medium over which the encapsulated frame is carried. This definition of an explicitly tagged frame is not complete, nor even sufficiently justified; it includes only those features required to make clear the arguments presented in this contribution. 2.0 Co-existence of Implicit and Explicit Tagging The key to allowing both implicit and explicit tagging interoperate in the same installation is to require that: + Any given VLAN has only one representation, either native mode, or one explicit tag, on any given physical extent (LAN segment). Another way to phrase this is that: + For any given VLAN on one LAN segment, all of the VLAN switches must agree to use the same tagging mechanism for all frames on that VLAN. This rule (stated two different ways), along with implicit or explicit tagging of frames, allows interoperable VLANs to include arbitrary combinations of VLAN switches, bridges, routers, and translation bridges. This rule, along with the given definition of explicit tagging, generates a number of corollaries: 1. Implicitly-tagged frames are in "native" mode on a LAN segment. They can be read/written by bridges or end-stations ignorant of the VLAN protocols. 2. All VLAN switches, end stations, and VLAN-ignorant bridges on a given LAN segment must agree on the native frame format on that VLAN. 3. All VLAN switches on a given LAN segment must have filters capable of differentiating all the implicitly-tagged frames carried on that LAN segment. 4. LAN segments connected by bridges ignorant of the VLAN protocols become, for the purposes of VLAN tagging, a single LAN segment. 5. A given LAN segment may carry implicitly-tagged VLANs, explicitly-tagged VLANs, or both. Note that this does not mean that all VLAN switches must support all tagging mechanisms. But if all VLAN switches on a given physical LAN segment are able to handle them, a mixture of implicit and explicit tagging is possible. This makes it possible, for example, to have a native-mode file server on a (mostly) explicitly-tagged FDDI backbone. 6. The same VLAN may have different representations on different LAN segments. 7. Different explicit tagging technologies may be used on different LAN segments. 8. A VLAN switch connecting two LAN segments that use two different tagging mechanisms for a given VLAN must translate between tagging mechanisms when relaying a frame between those two LAN segments. Note that this translation does not affect the original, encapsulated frame. 9. Two different VLANs that contain frames that cannot be differentiated by implicit tags (e.g. when the same MAC address is used by routers on two different VLANs) must never both exist in the implicitly-tagged form on the same LAN segment. If sharing one LAN segment, one or both of the VLANs' frames must be explicitly tagged. 10. If an endstation that does not understand the VLAN protocols is connected to a LAN segment, and that endstation belongs to a given VLAN, then that VLAN must exist in implicitly-tagged form on that VLAN. 2.1 Simple vs. Translation vs. Encapsulation Bridging The two most commonly used frame formats are 802.3/Ethernet and 802.5. Let us ignore the other formats for the moment. The "type" of an implicitly-tagged (unencapsulated) frame we will call 802.3/Ethernet or 802.5 according to whether the LAN physical medium format is 802.3/Ethernet or 802.5. The "type" of an explicitly-tagged (encapsulated) frame is taken to match the type of the inner, encapsulated frame. This may be different from the type of the encapsulation, which must match the medium on which the encapsulated frame is carried. We call transparent and source-route bridging, as it exists today, "simple" bridging. Simple bridging moves frames between like media types, without affecting whether or not the frames are explicitly or implicitly tagged. "Encapsulation" bridging occurs when a VLAN switch bridges a frame between implicitly-tagged and explicitly-tagged media, or between media using two different explicit tagging mechanisms. The encapsulation bridge must add or remove an explicit tag, or both. The encapsulated frame is not altered by this process. "Translation" bridging occurs when the type of the frame is changed, whether the frame is implicitly or explicitly tagged. Translation bridging may require changes to the contents of a frame at layers higher than the MAC layer. Both translation bridging and encapsulation bridging can occur in the same VLAN switch. Thus, bridging an 802.3 frame in native mode to an 802.5 LAN by adding the appropriate 802.5 encapsulation is encapsulation bridging, not translation bridging, because the encapsulated 802.3 frame is not altered by the process. On the other hand, an 802.5 frame encapsulated on an 802.3 LAN may be shorn of its encapsulation, translated to 802.3 format, re-encapsulated, and output on another Ethernet LAN. This frame is said to be translation bridged because its native format changed, even though it remains on an 802.3 physical medium. 2.2 BPDUs BPDUs, in order to work well with this loose tagging scheme, are treated just like any other frames as far as tagging is concerned. Native mode (i.e. unencapsulated or implicitly-tagged) BPDUs cannot be differentiated by VLAN. Therefore, on any given physical LAN segment, all VLANs represented in the native (implicitly-tagged) form must share the same spanning tree. Explicitly-tagged VLANs may have separate spanning trees, as their BPDUs are encapsulated and tagged. There is no requirement that explicitly-tagged VLANs use separate spanning trees, however. The simplest way to meet the requirement for implicitly-tagged VLANs is to use a single spanning tree for all VLANs. The question of the value of multiple spanning trees is not addressed in this contribution. We will assume, here, that a single spanning tree is in use. 2.3 User endstation considerations Some knowledge of the tagging mechanisms employed may be required of endstations. Where an endstation has only a single networking-layer stack with a single networking-layer address, no knowledge tagging is required or expected. We must assume that a host that is running, e.g. both IPX and IP stacks, knows how to differentiate incoming frames for the two stacks. Effectively, such a dual-stack endstation participates in the implicit tagging of VLANs. Note that a system administrator must be careful when placing multiple implicitly-tagged VLANs on a LAN segment attached to endstations. Not all endstation protocol stacks are able to cope with "foreign" frames, particularly MAC-layer broadcast frames. There is no reason to rule out endstations which are aware of explicitly-tagged VLANs, either. This might be a useful capability for a server for a particular application which spans multiple administrative domains. Norman Finn, Cisco Systems, Jan 24 1996