Date: Thu, 19 Oct 95 14:31:11 EDT From: Anil Rijsinghani 19-Oct-1995 1424 To: p8021@nic.hep.net Subject: minutes from day 3 of Interim 802.1 meeting The following notes are the minutes from the last day of the IEEE 802.1 2.5-day Interim meeting on VLANs at Denver. (The first two days were recorded by Rosemary Slager.) Note that affiliations are not listed with names below; they may be derived from Hal Keen's previous message on this exploder. Please report any inaccuracy or incompleteness to me. Regards, Anil ------------------------- IEEE 802.1 Interim, Oct 13 1995 Subject: Virtual LANs 802.1 Chair: Bill Lidinsky 802.1 Interworking Chair: Mick Seaman On the third day, the following items were presented and discussed: - Potential Virtual LAN topologies - Potential Virtual LAN solutions - Proposed VLAN Service Definition - VLMP proposal The working group had split up into three parallel sessions during the evening of the first day to focus on the following topics: VLAN requirements; VLAN topologies; and VLAN solutions. The second day was spent by the 802.1 group entirely on discussion of requirements in order to come up with draft agreed-upon requirements. 1. Topologies David Cullerot presented the findings of the group discussing target VLAN toplogies. Several terms were coined in order to facilitate discussion: VLAN switch = VLAN-aware layer 2 device; ISL (Interswitch Link) = medium for muxing VLANs between VLAN switches; ISLPP = point-to-point ISL while ISLS = shared ISL; Access Link = medium used to mux 1 or more users into a VLAN switch; Access Port = switch port attached to an Access Link; Hybrid Link = medium with VLAN switches as well as users attached; Hybrid Port = switch port attached to Hybrid Link; Network Port = switch port attached to link with VLAN switches connected. It was suggested that two additional terms be added to describe the case when a single MSAP is attached to a VLAN switch port: Private Access Link and Private Access Port. In a diagram of possible topologies, examples of these terms were brought out. Two additional points were made with this example topology: that a user may want to be part of multiple VLANs simultaneously; and that it is desireable to have redundant configuration within a VLAN for failover. Some topology considerations were that encapsulation is simple when the ISL accomodates higher MTU sizes than access links; otherwise it forces fragmentation or end station co-operation. Other suggestions for topology included: various types of LAN topologies be accomodated (eg, star/ring/bus); radius of up to 20 km; users up to 250,000; etc. It was suggested that the constraints and requirements for now reflect the ones in place for 802.1 Bridged LANs. Finally some configuration restrictions were discussed. One of these was that a VLAN be restricted to a single administrative domain which may be connected to another via a router, i.e., it is not possible to have a VLAN distributed across a router. It was pointed out that it is possible, however, to connect VLANs within an administrative domain with routers, via a variety of means which need not include VLAN-knowledgeable routers. Issues presented: should interoperability across ISLs be specified? When ISL loop detection utilizes 802.1D spanning tree, there is a potential problem with a single spanning tree for all VLANs. An algorithm other than 802.1D may be considered for ISL loop detection if it presents VLAN benefits over and above current STA. [For further detail, please see document distributed by Dave Cullerot, which I believe Hal Keen will place on the FTP server.] 2. Solutions John Wakerly presented the findings of the group discussing potential VLAN solutions/implementations. A base 802.1D device implements DA filtering, and possibly allows unknown/multicast addresses to be sent to a different set of ports based on the input port. Some switches may allow use of both SA and DA in the forwarding decision; some use DA, SA, as well as protocol; some look beyond the protocol layer (eg, layer 3). It was pointed out that while many available products implement this kind of filtering today, customers find it difficult to use these features to configure VLAN-like capability in their networks. VLAN implementation premises: A switch restricts packet forwarding according to VLAN membership; the switch associates each received packet with a VLAN (comment: should it be one or more); it may be based on ingress port, SA, protocol, layer 3 or higher; or other arbitrary considerations (for example, time of day). Observations made: multicast and unicast need not be handled identically (eg, unicasts could go everywhere); some association can be made by looking at the packet, while others cannot (eg, port); it is useful to think of "ingress" switches and "ingress" port with trunks connecting switches. The question this raises is whether end stations may be connected to a trunk. Intermediate switches (on the way to the destination) must also associate each received packet with a VLAN (comment made: this need not be the case, a mixture of non-VLAN capable switches with VLAN-capable switches is possible); intermediate switches may recompute VLAN association, or learn it from a "tagged" packet. Tagging pros: Simple, fast intermediate VLAN-aware switches; carries traffic for any VLAN regardless of ingress switches associations means. Cons: breaks remopte bridges which rely on snooping certain fields; MTU violation or fragmentation/reassembly; on hybrid links, both tagged and untagged packets may be needed in some cases. Patent considerations, and IEEE standard policy and requirements, were also mentioned. 3. Proposed VLAN Service Definition Paul Frantz presented a proposal co-authored by Paul, Martin McNealis, and Tony Moraros. When a port on the VLAN network receives a packet from an attached device, it may map it into a VLAN based on SA, DA, port, protocol or other packet fields. The VLAN network retransmits the packet on other segments which meet one of the following criteria: The DA is unicast and traffic is allowed to be forwarded to it; or it is forwarded on all segments where the port configuration allows traffic for the associated VLAN. For broadcast DA, it is forwarded on all segments where there is at least one MSAP configured into the VLAN and the port configuration allows it, or on all segments configured to allow traffic for that VLAN. For multicast DA, on all segments where the network configuration allows traffic for the VLAN, except when the configuration indicates that a subscription protocol (TBD) is in use on the segment, in which case the packet is transmitted only if the device on the station has subscribed to the multicast DA. Notes: standard shall allow for multiplexing virtual router interfaces over a single physical link to which switches are attached; Virtual network allows connection of multiple MSAPs with the same MAC address provided they are not configured into overlapping VLANs. [For further detail, please see document distributed by Paul Frantz, which I believe Hal Keen will place on the FTP server.] 4. VLMP (Virtual LAN Management Protocol) John Wakerly talked briefly about this proposal on behalf of David Cheriton. An Internet Draft will shortly be submitted to describe the mechanism proposed. This is a MAC or datalink-level protocol for exchanging VLAN info between switches on an extended LAN. It relies on an RPC-like approach rather than 802.1D spanning tree. It suggests that a "callback" be performed if necessary to learn VLAN association, along the source path. -------------------------