From: klamm@ods.com (Keith Klamm) Subject: Dancing Bears in Readable Text Format To: p8021@hepnet.hep.net Date: Fri, 8 Mar 1996 08:12:31 -0600 (CST) Hi, I am re-posting Steve H.'s contribution to the list with a few formatting changes. Words and paragraphs have been reformed and extraneous chars. removed. I think the Dancing Bears paper is an excellent introduction to where we are now, thanks to Steve for authoring it. I send my apologies in advance to any formatting errors present- they are all mine. It was difficult to tell where the paragraph breaks were. Cheers, Keith Klamm ------------------------------ cut here ---------------------------------- Dancing Bears IEEE 802.1 Virtual LANs Abstract Currently, the IEEE 802.1 standards committee is working on developing a set of standards for bridging devices to provide inter-operable virtual LAN features. This document discusses the current direction of the working group and puts forth some proposals. The reader of this document is expected to be somewhat conversant with LAN technologies. Specific knowledge of bridging technology is especially helpful. The target audience for this paper are engineers that need to stay abreast of the working group progress, newcomers to the working group who need to come up to speed, and the user community. The purpose of this document is to help educate and to help frame the standards discussions. This document in does not necessarily represent the views of the IEEE 802.1 standards committee or its members. This document is not sanctioned by the IEEE 802.1 committee Copyright (c) 1996, Steven E. Horowitz This copyright is modeled on the "copyleft" as put forth by the Free Software Foundation. It is specifically permitted to copy and redistribute this document without prior permission or fee. The only requirements are that the document is copied in its entirety including this copyright noti ce, the contributing author(s) are attributed, and that any additions to the document are clearly noted as not belonging to the original. Disclaimer This document is meant to benefit the general public. It should not be construed as being approved by the IEEE or any other standards organization. It is provided as is. Please do not base any decisions on this document. It is educational in nature. The standard(s) should always be consulted for the definitive information. Credits Significant input has been provided by Anil Rijsinghani of Digital and Paul Langille of Ascom/Nexion. Also, thanks to Mick Seaman of 3Com for the spanning tree review and Jim Hiscock of 3Com for his overall support. Revision History Date Version Editor Description 2/12/96 x1.0 S. Horowitz Initial Draft 2/14/96 x1.1 S. Horowitz Updated following Littleton meeting 2/13/96 with Anil R. and Paul Langille. Still in transition - forgive the rough areas. 3/6/96 v1.0 S. Horowitz Prepared for first release to the general public. Table of Contents 1. INTRODUCTION 4 1.1 USER PERSPECTIVE 4 1.1.1 Moves, Adds and Changes 4 1.1.2 Performance 4 1.1.3 Eavesdrop Protection 4 1.2 BRIDGED INFRASTRUCTURE 5 1.3 JURASSIC VLANS 5 1.4 VIRTUAL LAN REQUIREMENTS 6 1.5 VIRTUAL LAN COMPONENTS Error! Bookmark not defined. 2. ARCHITECTURE 8 3. MAPPINGS 11 3.1 IMPLEMENTATIONS 11 3.2 MAPPING ISSUES 11 3.2.1 Leaky VLANs 12 3.2.2 Unresolved Mapping 12 3.3 STANDARDIZATION 12 4. INTER-SWITCH LINK PROTOCOL 14 4.1 JUSTIFICATION 14 4.2 VLAN CLOUD 14 4.3 REQUIREMENTS/GOALS 14 4.4 ISL TOPOLOGIES 15 4.5 ISL PROPOSAL 16 5. SPANNING TREE 17 5.1 LEGACY DEVICE LOOP 17 5.2 VLAN-TO-VLAN LOOP 18 5.3 SPANNING TREE DISCUSSION 18 5.4 VIRTUAL BRIDGES 19 6. VLAN GRAMMAR 20 6.1 GRAMMAR PROPOSAL 20 6.2 GRAMMAR APPLICATION 20 6.3 DISCUSSION 21 7. GRAMMAR DISTRIBUTION 22 7.1 NETWORK MANAGEMENT 22 7.2 VLAN SERVER 22 7.3 DISTRIBUTED MODEL 22 7.4 SECURITY 23 8. VIRTUAL LAN MEMBERSHIP PROTOCOL 24 1. Introduction IEEE defines virtual LANs to be a logical grouping of MSAPs [MAC Service Access Points] within a bridged infrastructure. Let's examine what this statement means. 1.1 User Perspective 1.1.1 Moves, Adds and Changes Traditional LANs tie the logical network to the underlying physical infra structure. To the user, this means that accessing the network from wall jack A may provide a different set of services than when the network is accessed from wall jack B. For example, jack A may be physically tied to IP subnet A and jack B may be physically tied to IP subnet B. A user moving offices would need to reconfigure the IP Address of the workstation before reconnecting to the network. Additionally, if the user requires the services available on the other subnet, the users network traffic would be required to flow through the router adding delay in providing that service and load to the router. VLAN enabled networks separate the logical network from the physical wiring. This dynamic capability enables the network to reconfigure the logical network that is available to that user through the users new wall jack. Therefore, instead of the user reconfiguring the workstation to subnet B, the network reconfigures to add IP A services to the users new connection. 1.1.2 Performance Often users of different network services coexist on the same LAN. For example, many existing network implementations have an IP subnet and an IPX subnet coexisting on the same LAN. Some users of this LAN use both IP and IPX and others may only use IP or IPX. The problem with this environment is that IP-only hosts must process IPX broadcasts and IPX-only hosts must process IP broadcasts. Additionally, significant bandwidth is wasted on the single protocol segments because frames of the other protocol are flooded to all segments. Because of the nature of VLAN networks, VLAN devices can intelligently forward or flood frames to the appropriate segments. This means that IP floods are forwarded to IP-only and IP-IPX segments and IPX floods are forwarded to IPX-only and IP-IPX segments. Physical bandwidth and host bandwidth is preserved. 1.1.3 Eavesdrop Protection A lot of users seem to expect VLAN technology to provide LAN security. Indeed, LAN security is currently specified by IEEE 802.10. VLANs, however, do provide a form of security that protects LANs from Peeping Toms. Users who are on a different VLAN will not be able to eavesdrop on communication of another VLAN -- unless those VLANs overlap on the same physical segment. In the previous example, users on the IPX segment cannot promiscuously monitor frames in the IP VLAN. This is because the VLAN devices will not forward frames to those segments. However, users on the IP-IPX segments could eavesdrop on either the IP or the IPX frames. This is because both VLANs are overlaid on the same physical wiring for those segments. True security is a very complex technology. Eavesdrop protection, although it may make it more difficult for hackers, does not provide any real security. True LAN security requires privacy through encryption and authentication. These techniques are specified by IEEE 802.10s standards. 1.1.4 Plug and Play Users expect that their virtual LAN equipment will follow the bridging tradition of being simple to use and configure. If Virtual LAN technology adds significant cost and complexity, then users might as well invest in routing or ATM switching. Ideally, users will be able to purchase the virtual LAN device from any conformant vendor, plug the device into the network, and have the device play within the existing infrastructure. 1.2 Bridged Infrastructure What does the standard mean by the phrase "bridged infrastructure?" In today's LANs, bridges receive LAN frames from one port and forward the frame out zero, one or multiple ports. The forwarding decision is based on the destination address of the frame and the spanning tree state of the port. For example, a frame might be forwarded to zero ports ("filtered") if the receiving port is not in the forwarding state, or if the destination address is already associated with the receiving port (implying that the destination host already received the frame). A frame is forwarded to one port if the destination address is found in the bridges address table with a valid port association. A frame is forwarded to all ports other than the receiving port ("flooded") when the frame is a broadcast frame, a multicast frame, or a frame without a valid port association ("unknown"). Characteristics of legacy bridged LANs include one spanning tree and connectivity of all end stations within the bridged domain using MAC layer addressing. When host A sends a frame to host B and both hosts are connected to the same bridged domain, then the frame will be properly forwarded from host A to host B. Early on, bridge users realized that the bridged domains do not scale to very large environments. The more hosts that exist in a domain, the greater number of addresses each bridge must support to cut down on flooding due to unknown addresses. Also, large networks tend to generate more broadcast and multicast traffic, sapping the bandwidth of the entire network and hosts on the network. As networks grow larger, many environments are forced to break the bridged domains into smaller zones by installing routers. Routers provide a termination of the flooding domain. They look further into the frame and forward the packet based on network layer protocol information. Routers are able to perform this extra processing at the expense of performance and complexity in routing protocols. An ideal environment would forward frames only to the port or ports that required that frame for connectivity purposes. Some would say, an ideal environment would have routers everywhere. However, routers typically are most costly to buy and administer. There is a large market to move closer to layer III capabilities without adding the associated costs. 1.3 Jurassic VLANs A variety of techniques were developed to intelligently limit the flooding domains in bridged infrastructures. These techniques provide a rudimentary logical groupings of end stations or, if you will, rudimentary virtual LANs. For example, routers typically are capable of bridging or routing based on protocol. (Depending on your perspective, some would say, some bridges are capable of routing certain protocols.) A "Brouter" that routes IP and bridges LAT connects hosts differently based on the protocol that the hosts are communicating. Host A can communicate with host B if communicating LAT. However, host A must communicate through the router to communicate to host B using IP (assuming different subnets). This configuration has the benefit of limiting the IP floods to one side or the other of the router improving the performance of each subnet. Another technique that was developed is to filter frames in the bridges based on protocol (or other criteria). Bridges look at the protocol information of frames as they pass through the bridge. The forwarding or filtering decision in this model is based on the protocol of the frame as well as the addressing and spanning tree information. These techniques fit the current definition of virtual LANs. What is required of any virtual LAN device (and not explicitly specified by the current definition) is the ability to reconfigure the logical topology dynamically without host or physical wiring restructuring. A host on the bridged LAN can't simply plug into the LAN that is physically connected to a different port of the "Brouter" if that host communicates using a routed protocol. That host would require reconfiguration of its network layer addressing so that the router could relay packets to it properly. 1.4 Virtual LAN Requirements What can the user community expect to gain from the virtual LAN technology? Performance Most customers who purchase switching technology do so for the performance improvement. VLAN technology will further improve the performance of the overall LAN by restricting network traffic to only the segments that are logically associated with that traffic. Also, VLANs allow a sort of "load sharing" capability where different VLANs may be forwarded over different bridge paths. Scaling to large environments Restricting flood domains enables switches to be deployed in a hiearchical manner resulting in support for significantly larger LANs. Cost-effective VLAN technology must not add significant cost to the switching devices. Otherwise, users might as well buy routers. The technology must remain simple to implement and cost-effective to deploy. Mobility One of the promises of VLAN technology is to support the mobility of end stations through the LAN. For example, if a IP host moved within the switched network, the network is able to reconfigure such that the host is still connected to the other IP hosts on the same subnet. The host would not be required to change its network layer addressing configuration. Inter-operability As with any standard, the ultimate goal is to be able to purchase any vendor's equipment that supports the VLAN standard knowing that it will work with equipment from other vendors. This implies that the standard must be clear in content and easy to implement, without superfluous options and ambiguities. Backward Compatibility There is a significant installed base of equipment that supports the IEEE 802 standards. It is an absolute requirement that the standard work with this installed base. Security VLANs won't address security as perhaps users might expect. True security where data integrity is authenticated and message privacy is maintained is addressed by the IEEE 802.10 working group. However VLANs will make it more difficult for users to eavesdrop on traffic if their segment is not participating in that traffic's VLAN. 2. Architecture A virtual LAN, in essence, specifies a dynamically allocated flooding domain. There are two things that occur within the VLAN switch to support VLANs. First, the switch has to determine which ports are associated with each VLAN. And secondly, the switch has to associate frames with specific VLANs as part of the forwarding process. It is natural to view VLANs as a set of services. John Hart, CTO of 3Com, probably put it best when he compared VLANs to cable TV. Eventually, users will simply connect to the "channels" that they wish to use. The network cable will carry (or acquire) access to multiple services as provided by the network. Another view of VLANs, perhaps less visionary, is to align VLANs with sub-networks. IP Subnet A, IP Subnet B, IPX Subnet C and LAT may align to separate virtual LANs. 2.1 Topology 2.1.1 LAN Planes A VLAN resides within a bridged infrastructure. This implicitly means that VLANs are flat networks. They are not hierarchical in nature like routed environments. Connectivity within a VLAN is achieved by devices that either forward, filter or flood LAN frames. At the heart of VLAN switches is the traditional bridging function as defined by IEEE 802.1D standard. Where a traditional bridge floods frames to all of its ports, a VLAN switch floods frames to a subset of its ports. Therefore, it is natural to view VLANs as overlays upon the physical wiring infrastructure. Each VLAN is a different LAN plane that runs over a subset of the entire physical LAN plane. [Insert graphic]. There are two important notes about the topology. One is that the spanning tree formed by the virtual LANs need not be identical to each other. Each VLAN may pass through different areas of the physical structure, or indeed, may be entirely separate from each other. It is possible to align the virtual LANs along the spanning tree formed along the physical layer (the legacy tree). Alternatively, there are benefits to forming separate trees, one for each virtual LAN. The second note is that the topology of the virtual LAN is dynamic. The structure of the Virtual LAN may change due to new devices requesting or releasing the services available through the VLAN. The dynamic nature of VLANs has lots of advantages in flexibility and bandwidth conservation at the cost of network management complexity. 2.1.2 Virtual LAN Clouds Each particular VLAN may consist of one or multiple "clouds". These clouds are useful abstractions that specify the underlying frame mapping mechanism. Devices in virtual LANs use a variety of mechanisms to map frames to virtual LANs as part of the forwarding process. There are many different implementations that map frames based on some implicit information associated with the frame, such as the receiving port or the MAC address, etc. Other devices support a variety of mechanisms that explicitly identify the VLAN association of the frame including IEEE 802.10 frame formats and tagging. ATM networks have standardized LAN emulation as the model for identifying virtual LAN associations. [Insert cloud graphic here]. As a frame passes through the virtual LAN, it may pass through different clouds. For example, a frame may be transmitted by a host, implicitly mapped to a virtual LAN by the ingress switch. That defines one cloud. The ingress switch may tag the frame using a proprietary approach before forwarding it on. A switch further on may translate the frame from the tagged approach to the IEEE standard virtual LAN frame format, or to a particular ATM emulated LAN. All of these different portions of the network are logically separate clouds of the same VLAN. 2.1.3 Bridging VLANs Most people would think that VLANs can only be connected by a router. There is a case where it might make sense to bridge different VLANs. 2.1.3.1 Implicit mapping disconnect Envision a network consists of a variety of switches, some with limited implicit mapping capabilities and others with sophisticated mapping capabilities. For example, a per-port mapping switch maps IP and IPX frames received on the same port to the same VLAN. Another switch receiving the same frames may be able to map them to separate VLANs. Assume those switches are communicating the frames to each other using the VLAN frame format with the embedded VLAN ID. If a particular VLAN is limited to one global ID, then the entire network uses the lowest common denominator. That is, since one switch groups the IP and IPX VLANs together, all of the switches must use this grouping. Alternatively, the IP and IPX VLAN might be considered a superset of VLANs. This model is hard to conceptualize and even harder to administer. The easiest model is to assume that the IP and IPX VLAN is separate from the IP or IPX specific VLANs and that the sophisticated VLAN device that maps can map between them provides a bridging function between the unsophisticated portion of the network and the sophisticated portion of the network. [What are the spanning tree implications?] 2.1.3.2 Re-mapping IDs Some devices are constructed to be as low cost as possible. These devices may not support a hashing function for the VLAN ID name space. Rather, they support a table lookup of a much smaller name space. For example, a desktop device may only support 16 VLANs. To lower cost, it also only recognizes VLAN IDs from 1 to 16. This enables the device to perform a table lookup which given the small number space, may be supported entirely within integrated circuits. Clearly, this is a desirable approach for providing low-cost VLAN support. A backbone switch might be capable of interpreting a VLAN ID on a particular port and to re-map the ID to the larger VLAN name space. For example, local ID 5 on port 1 maps to VLAN A but local ID 5 on port 2 maps to VLAN B. This model brings forward the notion of local VLAN clouds. It is a very powerful feature for LANs with low cost desktop devices configured in point-to-point topologies. It is highly desirable that the standard support this model. 2.2 Switch Internals This section describes the architectural internal mechanisms inside a Virtual LAN switching device. 2.2.1 Port Association The switch associates ports to specific virtual LANs. A switch may associate any particular port to zero, one or multiple VLANs. The association may be static in nature (assigned by network management configuration) or dynamic (assigned by monitoring the network or participation in a Virtual LAN membership protocol). The result of this operation is that the switch maintains a list of ports associated with each virtual LAN in which it participates. 2.2.2 Real-Time Mapping As each frame is received by the switch, the switch performs a real-time mapping of the frame to a virtual LAN. The mapping function may be based on an implicit mapping function or an explicit mapping function. The frame is then forwarded to zero, one or all ports that are associated with the virtual LAN. 2.2.3 VLAN Learning When a switch is unable to map a frame to a particular VLAN in real-time, the frame is processed in the background to learn the VLAN association. Each VLAN is described by a VLAN grammar in the form of a sequence of masks and values. The switch applies each mask to the frame until it finds a match to the value. The matching entry points to the appropriate VLAN and the switch updates the real-time function for processing subsequent frames. 2.3 Administration 2.3.1 Naming The cornerstone of the Virtual LAN architecture starts with a name. A name is required to label the logical grouping. Human beings use this name to administer the logical infrastructure including mapping policy, connectivity and performance. The name must be unique and consistent within the administered domain. The format of the name is purely a user preference. "IP Subnet A" and "Software Engineering" are equally good names for VLANs. 2.3.2 Membership Policy Once defined, human administrators define the membership policy(s) for frames in the virtual LAN. For example, a membership policy might be frames on IP subnet A, or IPX subnet B, or LAT, or a set of MAC addresses. Membership policy must be defined based on some content of the frame. Multiple criteria can map to the same VLAN. 2.3.3 Policy Compilation The VLAN policy, e.g. "IP Subnet A" is compiled into a set of grammars, one for each MAC layer protocol supported within the VLAN. MAC layer protocols include FDDI, Ethernet, 802.3 and 802.5 (Token Ring). 3. Port Mode Each physical port supports two configuration modes. For each port in basic mode, the switch runs one spanning tree process. The spanning tree BPDUs are sent in the "clear" -- your basic IEEE 802.1D spanning tree. When a frame cannot be mapped to a VLAN in real-time, then frame is forwarded to all basic mode ports. For each port in dynamic mode, the switch runs a spanning tree for each VLAN. The spanning tree BPDUs in this case are hidden from legacy bridges. When a frame cannot be mapped to a VLAN in real-time, the frame is not forwarded to any dynamic mode ports. 4. Mappings The mapping function defines the set of criteria used by the switch to associate each frame, in real-time, with a particular virtual LAN. Each frame can be associated to a particular virtual LAN by an implicit mapping or an explicit mapping. Implicit mappings refer to the capability of the switch to infer the virtual LAN association based on information associated with the original frame. Implicit mappings include the received port number, the subnet address, and the ATM LEC association. Frames can be explicitly mapped to a particular VLAN by translating the frame to the virtual LAN identifier. This section describes both types of mapping functions. The format for the explicit mapping, however, is described in another section. 4.1 Implementations Many different real-time mapping functions exist in today's implementations. Here are some examples: Receiving Port By far the easiest mapping function to implement and the most prevalent in the industry, the per-port function maps each frame to the virtual LAN associated with the receiving port. The disadvantage to this approach is that all of the hosts on a particular segment by definition are grouped together on the same VLAN. However, this approach does work very well in desktop environments where only one host is connected per segment. Source MAC Address As each frame arrives in the switch, the frame is mapped to the VLAN associated with the source MAC Address. This mapping technique allows each host to belong to one VLAN. Source MAC Address and Protocol This function extends the source address function by adding the protocol of the frame to the equation. This mapping function allows each host to belong to multiple VLANs, one per protocol. Protocol and Subnet This function looks deep into the frame to pull out the network layer addressing. The network addressing (or subnet) defines the virtual LAN mapping. Many implementations of this type only map flooded frames (which make up a much smaller percentage of the overall traffic.) Frames that are not flooded are simply forwarded to the appropriate destination port based on the destination MAC address. Tagging/Translation Tagging changes the frame to include a VLAN identifier. It is easy to see that there exist many devices with a wide range of capabilities. And this list is by no means exhaustive. 4.2 Mapping Issues Some implementations bring forward some interesting issues. 4.2.1 Leaky VLANs For example, some implementations only perform the mapping function for frames that require flooding. If these implementations, the switch forwards known unicast frames normally. This behavior is sometimes referred to as "leaky VLANs". The disadvantage to this technique is that it is possible for a hacker to spoof a unicast frame and thus gaining access to a restricted VLAN. However, VLANs are not truly a security mechanism and users who wish to have secure environments are pointed to the IEEE 802.10 specifications. The advantages in simplicity and cost of leaky VLANs outweigh any perceived disadvantages. Leaky VLANs, therefore, are specifically allowed (for basic mode ports). 4.2.2 Unresolved Mapping Another issue arises when the mapping function cannot resolve the frame to a particular VLAN. For example, what does the switch do if it does not have a VLAN associated with the source address of the frame? There are three possibilities: Flood the frame Flood to the "default" or "legacy" VLAN by forwarding it out all of the non-blocking (legacy spanning tree) ports. This has the advantage of giving priority to connectivity. The only question is will anything break on the network by seeing frames with unexpected information, e.g. an IP subnet A router port receiving a subnet B packet? Or, will this action result in inadvertent loops? Drop the frame This assumes that hosts will retry and that the switch will be able to resolve the mapping before the host does retry. Hold the frame Hold the frame with the intent to forward after a background VLAN association is made. This technique has the distinct disadvantage of mis-ordering frames (or stopping the switch) and could never be part of the IEEE standard. The assumption is that the switch will eventually be able to resolve the frame mapping and to load the new mapping function into the real time lookup processing for subsequent frames. The main issue is whether default flooding results in network loops. Without too much thought, the quick answer is that legacy bridges will perform in this way so this action should also be OK for basic mode ports. However, this issue requires further study. 4.3 Standardization Essentially, the implicit mapping function is a vendor specific capability. There is no need to standardize the criteria that must be supported for mapping implicitly tagged frames in real time. Indeed, the opposite is true. It is desirable to embrace the many implementations and architectures already deployed to enhance the acceptance of any standard in the marketplace. However, the behavior of the switch with respect to enforcing the VLAN topology is very important. If one were to prioritize simplicity and connectivity, then it is desirable to specify that frames be flooded when VLAN associations cannot be made. If, on the other hand, VLAN integrity is important, or if flooding frames to segments not participating in that VLAN can break other devices, or if violating the VLAN integrity can result in network loops, then clearly the behavior of VLAN devices must be to bar leaky VLANs and to drop frames when implicit mappings cannot be resolved. The standard will cover two port modes as described earlier. For basic mode ports, leaky VLANs are specifically allowed. Flooding unknown VLAN frames are specified. For dynamic mode ports, leaky VLANs are not allowed and unknown VLAN frames are filtered. This latter specification is to prevent loops. Clearly, it is important to define the explicit tagging formats for inter- operability purposes. This is the topic of the next section. 5. VLAN Frame Format The VLAN Frame format defines the translation formats to support explicit mapping. VLAN aware hosts, or more typically, the ingress VLAN switch may form frames with the VLAN identifier. 5.1 Translation The model for this proposal is not encapsulation, but frame translation. This is an easy model to understand since translational bridging is a proven technology deployed widely throughout the industry. When a frame arrives in a particular format (e.g. IEEE 802.3 format), the switch first translates the frame to the desired frame format (e.g. FDDI or Token Ring) if necessary and then translates the frame to the VLAN frame format associated with the MAC layer protocol. Architecturally, transitions to the VLAN frame format are only between the MAC layer format and the VLAN format associated with the MAC layer. This has the advantage of translating the original frame to the appropriate format for the egress port. Traditional frame translation is performed where the translation function is implemented and is not forced upon the edge switches. [Insert Ethernet to FDDI graphic here]. 5.2 Justification By translating the frame, the ingress device removes the need for the switches in the VLAN cloud to perform implicit mappings. Why is this desirable? One reason is to support devices of differing implicit mapping capabilities. For example, it does not make sense to have a device that supports protocol and subnet mapping to send frames to a switch supporting only source address mappings. The original subnet mapping is lost. This result occurs whenever a more advanced switch sends data to a simpler switch. Another issue is that per-port devices cannot de-multiplex VLAN traffic within one port. For example, if one were to inter-connect two per-port devices, one would need a separate physical line for each VLAN. Translation enables per-port devices to support multiple virtual LANs over one physical port without adding complex mapping logic. 5.3 VLAN Cloud Once the frame is translated with the VLAN ID, the frame can be said to enter a "VLAN cloud" until it is decoded by an egress switch at the frame's destination(s). The VLAN cloud can be architecturally separated from the non-VLAN cloud network in a similar fashion to how the ATM cloud is treated. The VLAN cloud can be considered a black box that provides transit for frames from one side of the LAN to another. A VLAN cloud should not be confused with a VLAN. A VLAN might contain zero, one, or multiple VLAN clouds, legacy networks and ATM clouds. This concept will be elaborated on fully within the architecture section later. 5.4 Requirements/Goals The following attributes are highly desirable in an translation technique: Virtual LAN ID - A field to store a virtual LAN ID. The ID must be unique within each VLAN cloud. There has been some discussion that this ID must be unique within the entire VLAN. This may be required if it is possible for a VLAN cloud to collapse together with another disjoint VLAN cloud. It is desirable to make the field large enough to support a fair amount of concurrent VLANs within the enterprise. A large field will not become outdated by future technological advances that suck up the VLAN ID name space. For example, the spanning tree protocol allocates 8 bits for bridge ports. That was considered more than enough at the time. We can see with hindsight that 256 bridge ports is limiting to today's high density switch products. It is also desirable to keep the VLAN ID field small. If it is small enough, some implementations may be able to save on the lookup performance by performing a table lookup instead of a hash. If hashed, it is desirable to perform a MAC address hash. This could be achieved by using 6 bytes for the VLAN ID field, 3 for an OUI assigned by IEEE and 3 for the VLAN ID. Alternatively, the OUI could be assumed by the implementation and just the 24 bits of the VLAN ID passed. CRC protection - Frame can be validated by the following methods No CRC regeneration- leaves the VLAN encapsulation unprotected and will fail to pass through legacy devices. CRC regeneration - Hides errors introduced by the switch Double CRC - CRC the header and the original frame - Can be costly for devices that need to modify the original frame forcing two CRCs to be calculated. CRC Normalization - Proposed by John Wakerly, CTOof Alantec/Fore, this technique generates a magic value that normalizes the header such that the original CRC is still valid. Frames too long - Tagging may generate frames larger than the MTU of the LAN. The choices are: MTU Violation - Ignore the problem - send frames that are too long. Modify the LAN standards to allow this for VLAN frames. Fragment - Force the ingress switch to fragment the frame and the egress switch to restore the frame. MTU Protection - Modify applications to use a smaller frame size to leave room for the encapsulation overhead. Transparency to non-VLAN aware devices Valid frames - CRC valid and frame length is valid Real DA and SA Other information needed by non-VLAN devices in the VLAN cloud such as frame priority and source routing information Header aligns with existing standards of 802.2 and Ethernet Encapsulation Efficiency Header Size should be kept minimal - overhead will decrease network throughput Strict header vs. splitting frames - How is the frame tagged? Do we simply add a header to the frame, or do we split the DA/SA from the rest of the frame and insert a new field? Ethernet vs. 802.3 Ethernet type useful for cut-through type devices Desirable to not specify two different formats to support 802.3 and Ethernet. Many of these requirements are actually at odds with each other. Some real tradeoffs must be made or multiple frame formats must be specified. 5.5 VLAN Frame Proposal This proposal is a variation to the proposal by Anil R. This proposal attempts to achieve the following: Compatibility with existing bridges with respect to frame format Minimize extra overhead in both the network and the switch device Maintain frame lookup logic Protect frame validity for segment transfer but not for end-to-end The VLAN frame splits the original frame into two parts. The first part consists of the original destination address and the original source address. The second part consists of the rest of the frame. The CRC is re-generated as it is in normal translational bridging. In between, the VLAN information is added in a format that is compatible with existing IEEE standards. 5.5.1 IEEE 802.3 Frame Format The IEEE 802.3 VLAN frame appears as follows: Original Address Information VLAN Information Inserted Original Packet following Addresses Regenerated CRC Destination Address Source Address Length (2) DSAP 3D VLAN, SSAP, Control (3) VLAN ID (3) Rest of packet including original length CRC Fig-1. VLAN Frame Format This format adds 8 bytes to the original frame. It does not support fragmentation. Legacy devices that wish to carry encapsulated frames must be "giant" enabled to support the extra 8 bytes. The CRC is regenerated. This leaves open the possibility that the switch itself corrupts the frame and the corruption is undetected until the packet's arrival at its ultimate destination. However, routers also regenerate CRCs with good success. It is thought that this issue is not a large problem with today's high reliability components. The actual frame is constructed such that legacy layer II devices could still be used to forward the frames. It has a proper DA and SA and the frame is constructed to conform to existing IEEE standard formats with a length field and an IEEE 802.2 header. It should be noted that the proposal does not support fragmentation and re-assembly. It is suggested here that modifying the existing standards to allow an extra 8 bytes of data would not be a problem, especially when compared to the level of acceptance of this standard if fragmentation were to be specified as mandatory. The VLAN portion of the frame is new. This information is parsable only by VLAN intelligent devices. It consists of a 24 bits of VLAN ID. A VLAN aware device can logically form a MAC Address like value by using a unique OUI with this 24 bit value to perform a lookup in the address table if so desired by that implementation. A couple of notes. In the above proposal, the length field is replicated rather than updated. Architecturally, it would be purer to just update the length field by 6. From an implementation perspective, however, replicating the length field makes it easier for the translational bridging function. Another thought is to only specify one frame format to support both Ethernet and 802.3 frames. If this is the case, it would be desirable to specify an Ethernet frame format, using an Ethernet protocol type and three bytes for the VLAN ID. This has many advantages: Generally speaking, it is easier to design hardware to recognize one frame format, either 802.3 or Ethernet, but not both. Ethernet frame format can support cut-through. If 802.3 frame format was the only defined format, then the whole frame needs to be resident before the Ethernet frame can be translated because of the length field requirement. Ethernet frame format only adds 5 bytes as compared to 6 (or 8). The disadvantage to using Ethernet frame formatting is mainly that it is no politically correct within the IEEE community. (Well, OK, it is not recognized as a standard but it is a de facto standard.) 5.5.2 IEEE 802.5 Frame Format TBD. 5.5.3 ANSI FDDI Frame Format TBD. 6. Spanning Tree There is essentially two different problems that need to be solved in a VLAN environment. One problem is preventing loops when connected to legacy devices and another problem is to prevent loops when connected to VLAN devices. In both cases, it is highly desirable to maintain connectivity. The following describes the spanning tree method supported on dynamic mode ports. 6.1 Legacy Device Loop In this scenario, a VLAN device is connected to non-VLAN devices such that the physical topology forms a loop. It is simple to say that we could just run the normal spanning tree protocol and algorithm as specified in IEEE 802.1D. Certainly, this method would cause at least one port of the switches involved to be blocked, thus terminating the network loop. However, it is highly desirable to interconnect VLAN devices with bridge/router devices or even bridges that perform protocol filtering. In this case, running spanning tree might cause disruption in the services provided to one or multiple LANs. For example, a common configuration in legacy environments is to support a bridge/router device which might route IP but bridge LAT. Since the brouter is bridging, it too is running the spanning tree protocol. It is natural for a site to configure each IP subnet and the LAT network as separate VLANs. And, it is natural for the VLAN devices to be connected to all of those VLANs. In simple terms, the VLAN switch is somehow connected to the brouter, either directly or indirectly. When this occurs, running a single spanning tree on the VLAN device may result in one of the IP subnets losing service. This is because, indeed, a loop exists between the VLAN device and the brouter. What is needed is for the legacy bridges (including the brouter) to see the VLAN device as separate bridges. This is natural for the legacy devices since legacy LAN topologies would involve separate bridges. How can this be accomplished? Instead of running one instance of the spanning tree protocol and algorithm, the VLAN device must terminate the legacy LAN spanning tree. That is, it does not propogate BPDUs. There are two ways to do this. One way is to simply terminate the BPDUs and do not participate in the legacy spanning tree at all. This is very simple. However, the VLAN spanning tree(s) (described below) must be relied upon to terminate any loops. It is possible, even likely, for loops to occur during power up and topology changes for the interval of VLAN hello times. Alternatively, if it is desirable to eliminate the incidence of network looping during reset or topology changes, then the VLAN switch can participate in the legacy LAN spanning tree by representing each port as a one-port bridge. More specifically, the VLAN device can represent itself as multiple one-port bridges by running an instance of spanning tree on each bridge port. Each bridge port sends BPDUs with the Bridge ID of the port (i.e. its MAC Address). >From the outside, each port appears as a separate bridge so that the legacy devices won't block because of the loop between the legacy LAN and the virtual LAN. The VLAN device, however, must still protect from the network loop. First, if any of the spanning trees run on each of the VLAN switch's ports have common spanning tree roots, then a loop exists on the LAN connecting those ports. Second, any common VLANs that are running through those physical segments involved in the loop must only pass through one of those ports. In the above example, IP-A and LAT run through one port and IP-B and LAT run through another port. LAT is the common VLAN running through both ports involved in the loop. Therefore, the switch must block LAT from passing through one of the ports to prevent the loop. Executing multiple "one-port bridges" adds an additional processing load and complexity to the VLAN switch. Also, this method does take longer to move to the forwarding mode and temporarily shuts down the virtual ports due to physical topology changes. It does, however, eliminate extraneous network loops. It is not clear whether the costs of associated with "one-port" bridging (slower to forward, downtime due to topology changes, complexity and burden to the processor) outweighs the benefits of eliminating infrequent, short term loops. Note, it has been observed that the "one-port bridges" do not need to transmit BPDUs. This is not true. In the case where the switch ports are connected directly (repeated, for example), the switch ports would need to be able to detect the loop by detecting each other's BPDUs -- one of them will be root in this case. It is noted that in most cases, the "one-port bridges" won't be sending BPDUs since it is likely that they are not the root of the spanning tree and therefore are not the designated port for their associated segment. 6.2 VLAN-to-VLAN Loop Running "one-port bridges" works very well for legacy LAN loops. However, when interconnecting VLAN devices in a loop, the VLAN devices would not be able to detect a loop. They would see each other as separate bridges. The solution to this problem is to run a spanning tree instance for each VLAN. First, the BPDUs would either have to be encapsulated (as described earlier) or a change to the BPDU structure would need to be developed such that legacy bridges would not treat them as real BPDUs. These VLAN BPDUs need to be invisible to legacy bridges ... and, they need to be forwarded (multicasted) as normal frames. Secondly, the VLAN spanning trees must take their cue from the underlying legacy spanning trees. When the legacy spanning tree for a particular port moves to the forwarding state, the virtual port(s) change state from disabled to blocked. This should be obvious because a blocked legacy port cannot forward frames (virtual or otherwise). Therefore, the virtual LANs must wait twice as long to begin forwarding as compared to the legacy LANs. Also, if the legacy tree indicates a topology change, the virtual port(s) connected to the legacy tree must immediately go back to the listening state. This issue is lot more obscure. The best example of a problem that might occur is two VLAN devices connected in redundant fashion through two separate legacy "clouds". Since each legacy cloud does not see the other, there is no loop in any of the legacy trees. In this example, one of the legacy clouds are not connected (i.e. one of the ports is disabled.) The VLANs are not in a loop because the legacy port is disabled and the virtual ports are in the forwarding state. Now, the legacy port is enabled. A loop exists and won't be terminated until the virtual ports detect the loop, perhaps many seconds later. [Credit to Mick Seaman for this issue]. By detecting a topology change in the legacy tree, the virtual ports can avoid this inadvertent loop. The cost to the VLAN is that it blocks where the legacy ports might not. One key advantage to running VLAN spanning trees is that it is possible to block different virtual ports for different VLANs. This means that one VLAN can run on one physical segment while another VLAN runs through a different physical segment. A form of load sharing, if you will. 6.3 State Machine The State Machine for dynamic mode ports is modified as follows: The legacy spanning tree executes normally for this port. The port moves from blocking, listening, learning and forwarding states as described by the IEEE 802.1D standard. When the one-port bridge moves to the forwarding state, it triggers each VLAN spanning tree to transition from the disabled state to the blocking state for their respective virtual ports. That is, the transition of the physical port to forwarding also enables the virtual port(s). Any transition by the physical port to a non-blocking state disables all of the virtual port(s) associated with the physical port. Additionally, if the physical port detects a topology change, the virtual port(s) transition back to the listening state. The switch itself scans all of the legacy spanning tree processes (one-port bridges and the normal spanning trees run over basic mode ports). If any of the legacy trees share a root bridge with another legacy tree, then the virtual LANs that overlap on those physical ports must block one (or more) of the virtual ports. Also, for each virtual LAN, the switch participates in a virtual LAN spanning tree over both the basic mode and dynamic mode ports. These spanning tree processes are exactly the same as the legacy mode process except as modified above for the dynamic mode ports. If any of the virtual ports detect a loop within the virtual LAN tree, then the virtual port(s) must also block. 6.4 Spanning Tree Discussion Each VLAN device runs a spanning tree process for each physical port representing each port as a separate bridge. Each VLAN device also runs a separate spanning tree process for each VLAN that it participates. The VLAN spanning tree is either encapsulated or run using a separate format from the existing BPDUs so that legacy bridges do not act upon them. In fact, the VLAN BPDUs must be invisible to legacy bridges so that they propagate them properly through the network. Executing these methods have the following advantages: Interoperability with legacy devices of all kinds Possible load sharing by separating VLANs over redundant links The architecture does have these disadvantages: Virtual ports' must wait for the physical port to move to the forwarding state before starting their spanning tree process Virtual ports' must react to any topology change in the legacy spanning tree by moving to the listening state Virtual devices must execute multiple spanning tree processes, one for each switch port and one for each VLAN. Virtual devices must have the capability to block VLAN traffic. This may not be trivial for some devices. 7. VLAN Grammar Each switch needs to be able to convert some commonly understood VLAN grammar into the run-time mapping supported by the switch. Therein lies the problem - what grammar can possibly be common among switches that support such a wide range of mapping capabilities? One switch might understand network layer protocols and parse frames based on subnet information. Others base their mappings on MAC addresses or received ports. It is certainly not acceptable to lower the bar of the standard to the lowest common denominator such as specifying port to VLAN mappings. On the other hand, it is not acceptable to force all switches to understand network layer protocols, or even application layer protocols. 7.1 Grammar Proposal The proposal is to specify a database of rules consisting of a sequence of masks and values and associated VLANs. Each database is specific to the underlying frame format, e.g. Ethernet, 802.3, 802.5 or FDDI. Each switch uses the database when a real-time mapping does not exist for the frame. The frame is compared against the set of masks and values until a match is found. The VLAN associated with the matching entry is then applied to the real-time mapping function. Whew! That sounds complicated. Well, its quite simple, really. Let's take a look at a few examples. Each database entry has the following structure: Offset - Relative Byte offset within frame to apply mask Length - Byte length to compare (may be implied by bit mask). Bit Mask - Mask is applied to frame at the specified offset Value - Value to compare against the masked frame value Next Entry - Points to the next entry to use if this entry is a match. Multiple compares might be required if the data to compare is buried in a variable length header. The offset is the relative offset from the last applied offset. Null entry indicates that this entry is a terminating entry and that it points directly to the appropriate VLAN. VLAN ID (or name) - Specifies the VLAN associated with frames that match these database entries. Each database entry is qualified by the underlying protocol type. This is obvious for disparate frame types like Token Ring and Ethernet. For example, matching a MAC Address requires separate rules based on the different MAC ordering of those protocols. It is also required for similar protocols like Ethernet and 802.3 type frames. Otherwise, the frames would have to be ordered to prevent ambiguities such as an Ethernet rule finding a match in an 802.3 frame. 7.2 Grammar Application When a switch receives a frame, it attempts to map the frame to a specific VLAN in the forwarding processing. If no mapping for the frame exists, the switch must find the appropriate VLAN. For example, a port based switch has not assigned a VLAN mapping to its ports. When a frame is received, it is cannot be associated in real-time to the appropriate VLAN. It is processed further (typically by the processor) against the VLAN grammar. The frame is masked and compared against the set of values appropriate for its frame type. If a match is found, the VLAN specified is then assigned to the real-time mapping function -- the per-port assignment in this case. In this way, complex criteria can be specified and used by simple VLAN devices. 7.3 Discussion Now, these primitive "assembly" level grammars can be used to build quite complex rules. Any criteria can be used to specify a VLAN - from MAC Address to SMTP email address. Since these rules are usually applied in the background, not in the real-time forwarding process, any processor can have simple software written to iterate through the database. Some vendors may wish to differentiate their products by speeding up the parsing with dedicated hardware logic. A simplifying optimization to this proposal would be to limit the size of any one rule. Sixteen bytes would seem to be a reasonable limit. One could argue that these rules are way too complex for the "average Joe." Indeed, a "pre-compiled" grammar could also be specified to allow users to specify VLANs as "IP Subnet A" and so on. The fact of the matter is that regular users should never have to see the bit grammar. All of the grammars should be hidden behind nice user interfaces. It is up to the NMS devices to map the user's compiled interface to the assembly grammar understood by all switches. Specifying a "pre-compiled" grammar that switches must also interpret is overly complex and entirely unnecessary. Another idea is to provide the capability to imply a range of values that map to the same VLAN. This maybe a powerful optimization, but for most applications the complexity is not required. 8. Grammar Distribution The grammar can be distributed to the switch in following ways: Manually configured through network management -- SNMP for example Retrieved dynamically from a VLAN server Distributed from switch-to-switch 8.1 Network Management The SNMP example is well-understood and works well for a small number of VLANs. A VLAN grammar MIB is easily defined that encompasses the elements of the VLAN database. Each switch would be expected to accept and process SNMP sets into local memory. The number of entries that can be locally stored is a vendor-specific issue and subject to product differentiation. 8.2 VLAN Server The concept of a VLAN server is modeled upon the LAN emulation services as specified by the ATM Forum. When the switch needs further resolution for a specific frame, it forwards the frame to the server for resolution. The server finds the appropriate rule(s) and VLAN association and responds to the requesting switch. What is not clear is how the frame is forwarded to the server. If it is acceptable to forward a subset of the frame, the frame can easily be encapsulated in the data portion of another frame. If, however, the standard requires resolution to be applied to any portion of the frame, then another protocol entirely must be specified. The easiest solution might be to send the frame within an IP (or some other network layer protocol) packet. Alternatively, a variation of the VLAN frame format might be used. Again, large frame sizes would have to be allowed or a fragmentation mechanism supported. The one great flaw of a server is that there is no redundancy. Alternatively, a redundancy mechanism could also be standardized. 8.3 Distributed Model The distributed model is based on the fact that the ingress switch must have made a VLAN association and therefore, has the VLAN rule that applies to this frame in its local memory. Clearly, the ingress switch must have been configured with the information initially, either through network management or through contact with a server. Once the information is acquired, it is trivial for the ingress switch to distribute the information as needed. In this model, the downstream switches send the original frame back to the upstream switch (with all of the associated protocol issues mentioned in the server model). The upstream switch responds with the locally stored rule base. The distributed model overcomes the lack of redundancy in the server model. The protocol issues, however, remain. Additionally, the distributed model still depends on an initial configuration mechanism to exist -- either server or manual configuration. Also, distributed models open the possibility for inconsistent grammars to co-exist in the same network. A variation to the distributed model is proposed in the VMP section below. 8.4 Security Always the odd man out, how is the authenticity of the VLAN grammars established. [This section is for better architects than me to specify.] 9. Virtual LAN Membership Protocol (VMP) [Note, this is not the same as VLMP as defined by a recent internet draft document. Personally, I like calling it VLMP but there may be confusion with the names, so it is VMP for now. Perhaps I should have called it GUMP in the tradition of .1q calling its protocol GARP.] Once the switch has mapped a particular frame to a VLAN, how does the switch know the set of ports that participate in that VLAN? One method is to manually configure the associations. Ports 1,2,5 belong to VLAN 10. Ports 2,3,4 belong to VLAN 250. And so on. Another method is to participate in a protocol that specifies virtual LAN membership. Each VLAN aware device that wishes to participate in a particular VLAN sends out a VPDU indicating that it wishes to join the VLAN. When other switches receive this request, they associate the received port with the specified VLAN and forward their own VPDU join requests out the other ports. As each VLAN device determines that it no longer needs to participate in the specific VLAN, it generates VPDU leave requests. Other switches receiving the leave request remove the VLAN association from the receiving port (after some time interval to give other devices a chance to (re)join. If that switch has no other ports associated with that VLAN, it stops sending VPDU requests for that VLAN on all of its ports. This protocol has the capability to dynamically build a VLAN tree structure within the bridged infrastructure such that only the segments that need to receive the VLAN traffic actually do. The other segments are only disturbed sometimes by periodic VMP join messages. This protocol is modeled on the Group Address Resolution Protocol submitted by Tony Jeffree in the IEEE 802.1p draft standard. The major difference is the form of the protocol data unit, not in the operation of the protocol. In fact, it would make sense to send the mask and value rule(s) associated with the VLAN. [This section needs work.] 10. Miscellaneous Issues 10.1 ATM Interoperability ATM already has a well-established standard for providing virtual LAN capabilities. It is called LAN emulation. Each ATM device can belong to one or more emulated LANs. Bridging devices model each instance of a LAN emulation client as a virtual bridge port. ATM LEC ports should be treated as any other switch port. The mapping functions may be per-port, per frame information, or explicitly identified. Each port can be configured to basic or dynamic mode, running the spanning tree process(es) as appropriate. This conflicts with the sentiment last expressed at the IEEE 802.1 working group meeting. Although it is true for hosts that connect to the ATM cloud directly that LAN emulation provides a virtual LAN capability, for legacy to ATM switch devices, a LEC instance is simply another bridge interface. It is entirely up to the switch (and user configuration) whether the LEC interface participates in the flooding domain of any virtual LANs or if a particular LEC transfers VLAN translated frames. In summary, from the IEEE point of view, a LEC instance is another "physical" port. 10.2 Translating Bridges [Discussion of how VLAN impacts translational bridging]. 10.3 VLANs and Intelligent Multicasting What is the difference between Virtual LANs and intelligent multicasting as defined in 802.1p? In reality, not too much. A VLAN can be thought of as a superset of the capabilities specified in 802.1p. Certainly, a multicast domain could be specified by a VLAN grammar associated with the destination address of the frame. And, GARP could be replaced by VMP. However, a multicast standard does not require changes in spanning tree or encapsulation protocols. For that matter, GARP could be considered a "pre-compiled" grammar within VMP. It does beg the question if intelligent multicasting requires its own standard. Perhaps a simplified subset of capabilities can be standardized within the VLAN standards so that devices that wish to only support intelligent multicasting are not burdened with extra overhead only needed for VLANs. It seems to be the better approach than requiring VLAN devices to support two mechanisms for specifying the same feature. 10.4 Proprietary Tagging [Discussion of how existing proprietary tagging approaches are embraced or supported by the standard]. Dancing Bears 3/6/96 Public Domain Document Steve Horowitz, Editor