Quick VLAN Standardization -------------------------- Oct 2, 1996 IEEE 802.1 Meeting, Ottawa Floyd Backes, 3Com Norm Finn, Cisco Scott Harvell, Acacia Steve Horowitz, Prominet Paul Langille, Ascom Krishna Narayanaswamy, Fore Luc Pariseau, Bay Himanshu Shah, US Robotics Rosemary Slager, IBM Anil Rijsinghani, Digital 1. Objectives This contribution seeks to achieve agreement within the 802.1Q Task Group of the IEEE 802.1 Working Group for a basic, interoperable set of features needed for timely standardization of Virtual LAN capabilities in a Bridged LAN. Three criteria were used to determine this set of features: * Minimal functionality for a V1.0 standard: This is not intended to preclude more complex or richer capabilities that could be standardized; rather, the intent is to continue working on and evolving VLAN capabilities following agreement on V1.0; * Implementation experience in products available today; * Deployment of mechanisms by users. 2. Accomplishments so far within 802.1Q To date, there has been significant discussion and agreement within the 802.1 WG on frame formats to be used for signalling VLAN membership of packets with the use of tags, and of the concept of "trunk" ports. Further work is needed on the classification criteria and policies for VLAN membership. In addition, VLAN administration and management definitions are needed for interoperable management mechanisms. 3. Port-based VLANs It is proposed that port-based VLANs are the classification criterion required by V1.0: * 802.1D bridge/switch ports are aggregated into VLANs by configuring each port into a VLAN; * A VLAN comprises switch ports across different switches attached to a common Trunk; * Traffic exchange is allowed only within the set of ports comprising a VLAN; * Multicast and Unknown unicast traffic is flooded only within this set of ports; * Packets are classified into a VLAN at ingress and tagged with a VLAN-ID corresponding to this VLAN when transmitted to the trunk; * At egress, VLAN membership is identified by the tag, and the packet is allowed to be forwarded only to ports configured into the same VLAN. 4. Trunk Ports and Access Ports A port can be either a Trunk port or an Access port. Traffic on Trunk links is tagged (contains an 802.1Q VLAN header); traffic on Access links is untagged. When tagged traffic is received on Access ports, it is discarded. An end-station on a Trunk link can become VLAN-aware if it is capable of identifying VLAN membership from the VLAN header. However end-stations on Access ports send and receive regular, untagged traffic. 5. Default Behavior A VLAN-capable switch which is unconfigured for VLANs behaves like an 802.1D switch; it forwards and filters traffic as specified by IEEE 802.1D. As ports are configured into VLANs, traffic from these ports are sent in 802.1Q format on the Trunk (if necessary; that is, unless the traffic is exchanged between Access ports of the same switch). 6. Spanning Tree It is proposed that all bridges/switches within a Bridged LAN run a single spanning tree, as per IEEE 802.1D-1990, over which multiple VLANs will exist. While multiple spanning trees offer some advantages over a single spanning tree for all VLANs: a) It is not practically feasible to run a spanning tree per VLAN when a large number of VLANs is configured; b) It is a more complex solution; c) It is expected that this subject needs and will receive further discussion and study for possible inclusion in a subsequent revision of the VLAN standard. 7. Management A simple SNMP MIB for configuration and management of port-based VLANs is proposed. The following management objects are suggested as candidates for inclusion in the MIB: * VLAN Version number * VLAN Name * Configuration of a switch port as Trunk or Access port * Switch port to VLAN mapping * VLAN Name to Tag mapping * Create/delete/enable/disable actions for a VLAN It is proposed that since 802.1D counters are defined for ports (In/Out/Filter), no new counters be added for VLANs. VLAN traffic on Trunks is best analyzed with the use of specialized traffic analyzers; maintaining counters for every possible VLAN will be very burdensome for the switch. 8. Further Discussion points * Hybrid Ports When a LAN has attached to it both VLAN-aware and non-VLAN-aware devices, rules are needed to determine the VLAN mapping and forwarding actions. What are expected capabilities of hybrid ports? * Default VLAN Non-VLAN switches, when attached to a trunk, may communicate through each other with the use of normal, untagged packets. Untagged packets may map into a "Default VLAN" for VLAN-capable switches. For a VLAN switch that is unconfigured, all ports could be viewed as access ports belonging to the "default VLAN" and there is no trunk port. * Extent of Tag Uniqueness Is an assigned tag unique within a Bridged LAN (ie, between all bridges that know about the same Root), or only within an extended or logical Trunk? * Duplicate addresses If the same address exists on two different VLANs, packets from it can be identified by looking at the tag attached to the packet by the ingress switch. What are topology restrictions (if any) to allow the same address to reside within separate VLANs? * Overlapping membership Can/should a port be configured as a member into more than one VLAN? * Configuration issues What are legal/recommended configurations? 9. Proposed Schedules and Milestones * A V1.0 VLAN working draft completed by November '96 Plenary * Ballot initiated thereafter * Resolution of comments and agreement in 802.1 by March '97 Plenary.