To: p8021@nic.hep.net Cc: 802exec@nic.hep.net Subject: 802.1 Interim on VLANs : Discussion of Requirements Date: Wed, 25 Oct 1995 00:39:05 -0700 From: Mick Seaman IEEE 802.1 Interworking : Interim Meeting Denver 10/11-10/13/95 Discussion of Virtual LAN Requirements, 10-12-95, Session Notes. Rosemary Slager and Mick Seaman (Task Group Chair) This session was based on the work of the requirements breakout group held the previous day (10/11/95), presented by Martin McNealis, Cisco Systems. Two further breakout groups, on network topology, and switch implementation assumptions presented 10/13/95. [Comments in square brackets like this one deal with followup work, and additions since the meeting - additional suggestions to me. Mick] The following summarizes the introduction provided by the task group chair, at the beginning and end of the session, and describes the agreed short term plan for progressing this work. The intent of the three areas of activity covered by the breakout groups is to share as much information as possible as rapidly as possible. To facilitate consensus, and ensure continued forward progress without backtracking we are communicating our individual basic assumptions about the problem to be solved (user requirements, protocol requirements etc.), the context in which it is to be solved (real physical network topology), and constraints (hard or desirable) on solutions (interoperability with existing equipment, classes of switch implementation capability). In each of these areas the intent is to create and maintain a standing document which collects together all the points of view (so far as is possible). Together with each line item we will attempt to capture sufficient discussion and clarification to make the meaning of the item clear. Between now and the 802 plenary (11/6/95) 802.1 attendees can request addition of additional list items or further points of clarification. Email (plain text) to the task group chair, mick_seaman@3com.com. This process will continue through (at least) the early part of the next meeting. The intent is to make the list and discussion inclusive rather than exclusive, and to remove or restrict items only on a near unanimous basis. When we believe we have full problem in open view we will move to the next stage of identifying significant choices and options. While we intend to maintain the following list and subsequent additions and clarifications through our work, it is not the intent to devote much attention and valuable time to wordsmithing it. In particular clever forms of wording designed to obscure fundamental differences of opinion or approach are strongly discouraged. A separate, reduced, set of elegantly phrased sentences may eventually be created for inclusion in the standard itself. The items listed under requirements can be considered to fall into a number of categories - user requirements, protocol requirements, interoperability with existing equipment, 802 architectural requirements etc. There were also some 'requirements' that were really solutions (both here and in the output from the other breakouts) and these should really disappear. [To make it easier for task group members to check the list commentary and their notes, it has been left 'flat' as originally presented, and in the original order of discussion, with points noted as they arose. I hope to be able to structure the list (though without removing items), prior to the plenary.] --------- Virtual LAN Requirements 1. A Virtual LAN (vLAN) is an administratively defined logical grouping of LAN stations independent of their physical location within a Bridged LAN infratructure. -where a "Bridged LAN' is defined to be a collection of MSAPs that can communicate at the Data Link layer. A vLAN is a subset of a bridged LAN. A given vLAN may cover the entire bridged LAN. The potential vLAN domain ends at a level 3 device ... (Alan Sikes) We need to define a bridged domain ... (Avner) Do we need a term that reflects "a conglomeration of vLANs". Suggestion that this is just the bridged LAN - the maximal set. A lot hinges on the term "administratively defined". Static and dynamic vLANs might be distinguished, and a "compile time" versus "run time" analogy drawn. An example of a static vLAN might be one defined by a list of actual stations. A dynamic VLAN might be created through observation of the protocols running. In general a dynamic vLAN might consist of the specification of an elaborate set of rules (by the administrator), followed by forwarding and filtering decisions (by switches) to enforce those rules. Here the idea is that the switches preserve given properties of the network which have been prescribed by the administrator, even if the network changes/reconfigures. Even purchasing or selecting a device with a given documented default behavior could be classified as "administrative definition" (and has been in the past). The above definition is a little too sweeping since there may be constraints on independence from physical location that we should recognize. For example, in port based vLANs there may be constraints covering devices which share the same switch port. We should distinguish the top down user view/definition from a bottoms up technical definition (Wayne Z.). An alternate definition focuses on the grouping of the LAN traffic (what happens to frames), rather than the attachment of end stations (user observed physical reality), or MSAPs (logical points of connection to higher layer protocols and a reflection of the technical service offered). This alternative is complementary, not exclusive. Existing 802.1D recognizes the distinction between the service offered and the supporting protocol mechanisms. 2. vLANs are to be supported over all IEEE 802 media (both shared and point2point) and remote WAN bridging technologies. Agreed that vLANs can be/are supported over anything which provides the necessary services i.e. the 802 MAC Service as defined by ISO/IEC 10039 (number to change soon) and the MAC Internal Layer Service defined in section 2 of 802.1D. This covers technologies beyond 802 LANs, for example those covered by 802.1G, without involving us in defining VLAN support separately for all media types. See discussion on ATM LAN Emulation, point 19. on this list. Still need to go some way to distinguish supporting a single VLAN over a connection between two sets of 802 MAC Service supporting media, from bridging between the two separate vLANs. There are considerations of possibly separate administrative domains or spheres of influence here. 3.vLANs shall support bi-directional unicast communication between any two MSAPs and unidirectional multicast and broadcast communication from one MSAP to one or more other MSAPs within the same Virtual LAN topology (e.g. IGMP Group definded vLANs) An MSAP may not be enough to define membership. Membership criteria might include may protocol types over MSAPs. There is a problem here in that OSI/802 layering is based on self identifying protocols in upper layers, as opposed to the embedded protocol identifier a la Xerox. Need to extend the MSAP definition. 4. vLANs must coexist and be backwards compatible with existing devices, end stations, hubs, routers, etc. [need to describe what compatibility means here in more depth - does it mean that the vLANs flow through the old equipment unnoticed, or that vlAN administrative boundaries are preserved, some options to be teased out]. 5. vLANs facilitate adds/moves/changes. A LAN attached device can reconnect anywhere within the Bridged LAN and remain a member of the same Virtual LAN or Virtual LANs. The move may be constrained by physical requirement constraints, as in the discussion on point 1 concerning port based vLANs. We should explictly choose between "Administrative assistance may be required" and "Administrative assistance shall not be required" (Geoff Thompson). Move is OK-DOKAY if the move is to a switch is using the same forwarding policy (ie., class). All of the devices that participate in the Virtual LAN that are of the same class have the same forwarding policy. Explictly recognize that different classes of device (port based, address based, tagging based etc.) should be accomodated on a given bridged LAN. The vLAN support should be unified at the top level, although different supporting devices might support vLANs through different mechanisms. Top-level here means user administrator definition and the information that is communicated through the network to support VLANs (though the protocol form of the latter may vary). Even individual ports on a given device may be required to play by different rules (Geoff Thompson). "Class" is not necessarily switch based. For example a port provided to a publicly accessible area, e.g. a building lobby, may be required to run port rules while the rest of the switch is running address based rules. Add "as fas as this is consistent with the administrative policies of the vLAN." (Alan Sikes) Explicit objective here is to move people within an organization without having to move the physical wiring. Put another way, it should be possible to move a people or stations so that they remain a member of the same Virtual LAN or Virtual LANs. [We agreed in the meeting to separate the two points in this item (5) and I will do that in the next revision] 6. vLANs enable logical segmentation of a Bridged LAN into automomous broadcast domains for end stations; where a broadcast domain comprises at least all MSAPs belonging to the same Virtual LAN. Originally this requirement read "... broadcast domains; where .." and "... comprises all MSAPs ...". The expanded wording recognizes: (a) that the broadcast domains for switches may be different, and not just a consequence of the administrative direct instructions for partitioning, (b) that the broadcast domain may be larger than the strict set of MSAPs belonging to this virtual LAN. The second condition could occur in (at least) two ways: Other end stations/MSAPs could be on the same physical segments of the network as the included MSAPs - either because they share a Port in a Port or address based part of the vLAN, or they directly attach to a backbone segment (servers, for example). This extension to the addressed set is covered in spirit by the rider "subject to the laws of physics", or as expressed in .1D "given the availability of .. [network] components" (Alan Chambers). Alternatively the broadcast domain could temporarily or permanently cover more segments than necessary. These segments might or might not reach further MSAPs - could be trunk or backbone segments. The switches might not know about all VLAN memberships for a temporary period during a configuration change. The switch(es) might not implement a perfect set of filters. There are two opposing high-level points of view on the question of accidental or deliberately extending coverage of a given vLAN beyond that administratively specified: The first could be characterized as the "laissez-faire approach", it takes the attitude that it is better to accidentally allow end stations to communicate with others in other VLANs, than it is to deny communication between two parties in the same VLAN. It is "inclusive". The second is the "secure approach" which attempts to prevent non-authorized communications, at the risk of interfering with those that should be allowed. It is "exclusive". It appears at first that the "laissez-faire approach" is more attuned to the goal of easy adds/moves/changes while providing increased aggregate bandwidth through traffic partitioning (and hence independence of one user group from interference from another's accidentally high bandwidth consumption). Conversely the "secure approach" addresses administrative users' desires to guard against malicious interference without relying on (usually non-existent) higher layer protocol controls. [At our Denver '95 interim there was significant sentiment that we should recognize the impossibility or extreme difficulty in feeding both ease of administration and security goals and move toward a definite choice between the two, or at least calling these out as two distinct operating modes for the bridged LAN. The latter would lead to distinct sets of requirements for each case, the former to declaring explicit non-requirements. More input and discussion please.] 7. Inter-vLAN communication between devices attached to different physical media shall require a Layer 3 or higher function. It was proposed that this be reworded either as "Inter-vLAN communication between devices shall require a Layer 3 or higher function." or as "Inter-vLAN communication between devices attached to different segments shall require a Layer 3 or higher function." The first of these recognizes that the need (in some cases) for a router to establish communication between two end stations in different IP subnets - even when these are on the same LAN. The second recognizes the impossibility of preventing direct communication between devices attached to the same segment. For some this is not a requirement, but a truism. However there is nothing to prevent a bridge being used to connect two administratively distinct bridged LANs (administratively distinct from the point of vLANs), to act as a converter between the two regions - provided that it can be configured to as a pair of end stations, each participating in multiple vLANs on each bridged LAN. Therefore this requirement may be unenforceable. In discussion of a number of these requirements we found it necessary to distinguish between requirements we might place on the standard or standards we develop, and requirements placed on the actual behavior of switches in a vLAN capable bridged LAN. This requirement is probably best rewritten as limiting the extent of standards we might produce. Alternatively we need to be much more explicit about the individual scenarios involved. One possible scenario deals with the case where a router function in a physical switch establishes the initial connection between IP subnets on different vLANs, via proxy ARP for example - and then gets out of the way of subsequent communication which occurs at the MAC layer. Note, this is apparently not possible with all IP implementations. In the Denver '95 interim this possibility was phrased as a need for further clarification of the requirement - "when - all the time, or just when communication is being established?". A further choice presents itself here - will the nominal end station know about the existence of vLANs. Proposed that if the end station does know, call it vLAN communication by the end station. If not call it LAN communication. 8. A vLAN device may forward unicast frames between vLANs. Changed from "With regard to non-routable protocols where two or more vLANs are defined, a vLAN device may forward unicast frames between vLANs." This requirement means a number of different things to different people. It may be a statement concerning the scope of the standard(s) we produce. In this context it gives us permission to bridge frames of non-routable protocols - and so include a direct bridging option in the standard. The definition of "non-routable protocol", is however up to the particular switch - if it doesn't implement routing for the protocol then it is non-routable. The alternative would have us legislating on whether each and every protocol is routable - which is outside our scope. This requirement can also be thought to address issues of connecting multiple administrative vLAN domains - in which case it is not true that there should be no bridging between vLANs, because the vLANs to be bridged should have been one vLAN in the first place. It needs to be resolved in the context of having or not having protocol specific vLANs. If all the vLANs in a given bridged LAN were protocol specific there might be no need to bridge between vLANs. However, if the vLANs were actually defined by a majority routeable protocol - to coincide with IP subnets for example - there would be a clear requirement to bridge non-routeable protocols between separate vLANs. The specification of unicast frames is consistent with a vLAN implementation in which the propagation of unicast frames is not at all restricted (in the spirit of the laissez-faire approach of requirement #6) but the multicast and broadcast frames are constrained to a given vLAN. Since most if not all protocols use multicast or broadcast for end stations to discover each other, constraining the multicast does constrain which unicast conversations take place. This fits with previous (bottoms up) vLAN definitions which use the concept of multicast domain. For a certain class of switch implementations performance may be higher if there is no need to check unicast propagation (beyond what is done in a .1D bridge). An overlying unicast vLAN provides some of the functionality (Geoff Thompson). On the other hand a "secure approach" would follow the administrative specification of who could possibly talk to whom much more closely, ensuring segregation of traffic. This requirement also triggered discussion of the notion of a "default vLAN", for use by network administration in order to reach all devices. We agreed that we need to make separate statements about unicast, multicast, and broadcast forwarding - in the separate contexts of a secure or a laissez-faire approach ["open approach" might be be a better term going forward]. [Equally it seems that these statements would be very sensitive to whether protocol based vLANs were to be used. Clearly we are some way below user requirements and into implementation here.] "A bridge is a device (straw) you dip into a packet soup and sucks/blows stuff out/in." "A bridge is a slow, selective repeater." (Geoff Thompson) 9. Criteria for vLAN membership are defined by administrative policy and require that each distinct vLAN be uniquely identified throughout the Bridged LAN. "uniquely" is necessary from the point of view of the administration, but not from the point of view of an individual switch - for which the vLAN identification may be ambiguous. The vLAN identification may not be the same throughout the vLAN, even amongst switches of the same class, but it should be consistent (even amongst switches of different implementation class). The vLAN membership for any given frame might be: (a) explicitly communicated along with the frame, e.g. by tagging (b) implicitly communicated with the frame, by separate explicit communication of a set of consistent rules to all the switches which rules can be applied to the frame (c) explicitly configured in to the topology (e.g. port based). To facilitate interoperability between different implementations and classes of switches there seems to be a need for a consistent top level view which can be translated to each of these styles. 10. A single Physical point of attachment via an 802 LAN interface may participate in multiple vLANs and may connect directly to a vLAN Trunk/Backbone. Where a vLAN Trunk/Backbone is defined to be a physical link between vLAN intelligent devices over which is carried traffic from one or more vLANs. Some objection to the use of "may" here. At whose option does this happen - ours in writing the standard, at procurement and network design time, freely for any end station? What protocols does the end station have to understand - LAN Communication or VLAN Communication (see requirement #7). This requirement introduces the notion of Trunks. Are trunks a user requirement or an artefact of a particular implementation style. If so which requirement do they address? "you have to build bypasses" (Tony Jeffree) A single point of attachment may correspond to multiple MSAPs, and in general does (a multicast address at an end station represents a distinct MSAP from its collocated unicast address). A major point of this discussion is - do we allow part of the network to be a part where endstations cannot directly attach (using LAN communication). We might envisage 3 regions: i. the vanilla environment which we have today ii. an environment which extra information is required, added to the packet (tagging, 802.10?) iii. an environment where additional static information is present, or additional information is carried by extra packets in the network (dynamically) We need to define a VLAN Trunk, in this and other terms. The question whether end stations can directly attached to all parts of the network is strongly related to investmant protection. If endstations cannot directly connect to a core part of the network, this corresponds to the situation described in 802.1G where more optimal routes (not just spanning tree routing) are available. 11. In the absence of any vLAN configuration all MSAPs are able to communicate with all other MSAPs throughout the Bridged LAN domain. Formally the abbreviation MSAP stands for Medium Access Control Service-access-point (ISO/IEC 15802-1), informally for Media Service Access Point. It identifies the notional point in a system that is selected by a MAC address. To be more precise this should refer to communicating using the forwarding path that is there without vLANs configured. This statement ought to be moved to the front, as a SCOPE statement on any standard we produce - the purpose of the standard being to add to .1D bridged LANs, not to invent something totally new (Geoff Thompson). Need to take into account recent 802.5 initiatives (Avner). There is a need to define the properties of the "default vLAN" in respect of communication with the configured vLAN (Anil). Creating a vLAN should not make the things inside it inaccessible to management. The truth of the proposed requirement depends whether we are operating under "secure" or "laissez-faire" assumptions, in this discussion called Open Policy or Closed Policy. 12. Once defined, static vLAN configuration should be non-volatile. Replace "static vLAN" with "statically configured vLAN"? Substantial discussion of this requirement, with some opposition on the basis that it is too constraining of implementation. Note however that in .1D we did go so far as to mandate non-volatile storage for certain filters - in order to guarantee behavior as the bridge powered up. The real requirement here is a combination of being deterministic (i.e. the network always configures in the same way, independent of the power cycling history of its individual bridge or switch components), together with acquiring certain parameters (particular if we are "secure approach" oriented) by the time traffic forwarding commences. Suggest changing 'non-volatile' change to 'deterministic' and specifying relevant time frames. It is not necessarily the case that this should apply to all parameters - we should choose carefully those for which this requirement needs to be true. 13. vLAN capable devices may participate in a method for exchanging and distributing vLAN configuration information. Seems harmless. 14. Network Management devices would be able to create/delete/reconfigure vLANs and as such, all vLAN devices should be accessible to an NMS (Network Management Station) if present. Much discussion, not good for port based... may be costly for SNMP (IP based) MAKE it a user choice to do this guarantee. Requirement may be absolved by requirement #13 (Geoff Thompson). It may be better to have explicit protocol to send vLAN information along the Spanning Tree so that the NMS can pickup information anywhere in the network, and if necessary inject information at a switch. This is a not shoot yourself in the foot requirement. There are shoot yourself in the foot possibilities inherent in .1D, but after discussion we didn't put extra mechanism and enforcement checks in because the real need was low. Assuming scope to be in band management, please restate as a requirement for having one vLAN that is capable of reching all devices (Geoff). Problem with forcing IP/SNMP to have priority to reach devices if this (default vLAN approach) is the preferred choice (Steve). This all adds up to building in more debuggability than we have in the past (Mick). 15. vLAN devices may be capable of supporting redundant links (possibly for the purposes of load balancing) within the Bridged LAN infrastructure. Rewrite to specify " standard shall do this...". Objection (Anil, others). Should base vLAN on existing bridge infrastructure, not go after every unsolved problem and opportunity for improving basic bridging. Does load balancing mean balancing of traffic within a single LAN? There are limitations to multiple Spanning Trees (aside from the patent question). Differentiate requirement for different paths through a network (via separate intermediate switches) from that for straight forward parallel links. 16. Virtual LANs may or may not require additional Quality of Service specifications. propose to change to: Virtual LAN standard shall not require additional Quality of Service specifications. with the following interpretations: It is possible to have/implement vLANs without QoS specifications. vLANs will have no unique QoS specification. Within a vlAN there is no additional QoS specification beyond that currently offered by the MAC Service and the MAC Internal Layer Service. A vLAN standard might address QoS issues, particularly maintaining QoS for a given vLAN. "Virtual LANification" 17. Virtual LANs may support and be deployed in conjucntion with multi-level security. May be a mistake to talk about vLANs with security. Replace "multi-level security" with "...with many people's concept of security..." (Lidinsky). Virtual LANs are an appropriate element in a comprehensive system of network security. (Geoff) 18. Networks overlaid with vLAN topologies shall support attachment devices with multiple MAC interfaces which have the same MAC address on each interface (e.g. DECnet IV). two instances DECnet phase IV SUN workstations using the same MAC address on several interfaces Same functionality as Bridged Networks today - a single vLAN should not/is not expected to tolerate duplicated MAC Addresses. Should be optional to have this support. Does not work well with port based devices. Should not do design engineering to the exceptional, arguably broken case (Backes). When we figure out what a vLAN standard amounts to we should figure out what happens to such devices. "The diversity of the human mind has created a problem set which defies comprehensive solution" (Geoff). The standard shall not preclude? --------------------------------------------------------------- RETHINK ALL REQUIREMENTS TO CONSIDER WORDING wrt VLAN STANDARD REQUIREMENT vs NETWORK REQUIREMENTS. ------------------------------------------------------------ 19. Virtual LANs as defined by the IEEE shall be interoperable with other Virtual Networking technologies notably ATM's LAN Emulation. Does this mean that vLANs should be mappable 1 to 1 to ELANs, or that "Virtual lans operate on emulated lans just as on real lans", i.e. a bunch of vLANs on an Ethernet will get carried over a single ELAN. Strong sentiment for the latter, it maps just using the defined MAC and MAC Internal Layer Services. A potential issue with broadcasts handled differently over ATM is how this scales in implementation. Also gives end stations directly attached to ATM the problem of understanding the vlAN protocol as well (vLAN communication in addition to ELAN communication). >20.Automated vLAN reconfiguration, if supported, shall be done in such a way so as not to disrupt convergence of higher-layer protocols. Realistic goal is to do as well as .1D does today, not a lot worse due to having further layered configuration protocols. 21. Nothing in the standard shall preclude implementations which scale to many thousands of users. We agreed we were talking about 16 vs 32 bit counters, but probaly tens of thousands rather than thousands. Take 50,000 as the upper design limit in order to be specific. 22. Virtual LANs may support spanning tree protocol independant of 802.1D STP. In that framework, it will require separate multicast address, protocol frame (which contains VLAN id field) and rules on processing of STP from othe VLANs as will as 802.1D's STP. (Himanshu) This is a pure solution view. Restate the requirement to limit the effect of changes in some part of the network or some vLAN can have on the effect of connectivity in another part or vLAN. At an implementation level this is a plea that Spanning tree changes should not affect connectivity. 23. The addition of VLANs to an existing bridged LAN should not significantly increase the traffic on any portion of that LAN. [Added at the request of Alan Sikes after the meeting, with the following discussion] Discussion: Presumably, users will be implementing VLANs to reduce traffic congestion and otherwise improve traffic patterns on their LANs. However, the addition of VLAN routing protocols (if any), routing of packets between VLANs, and other similar "features" that we may come up with will add to the traffic on the net. I have purposely left the metrics vague ("significantly") since I'm not trying to define a hard requirement, but rather something that needs to be kept in mind over the coming months.