Multicast Support via IGMP vs. 802.1Q VLANs May 1, 1997 Summary This paper discusses and compares two approaches to supporting multicast: IGMP - the Internet Group Management Protocol [2], and Virtual Bridged Local Area Networks (VLANs), specified by the proposed 802.1Q IEEE standard [1]. Various strengths and weaknesses of both solutions are analyzed with respect to several essential requirements of a successful multicast specification. Background Many of the emerging Internet applications require one sender to transmit data to a group of receivers simultaneously. Examples are video and audio conferencing, database replication, communicating stock quotes and collaborative computing. Multicast efficiently supports this type of transmission by enabling sources to send a single copy of a message to multiple recipients who explicitly want to receive the information. This is far less resource-intensive than requiring the source to send an individual copy of a message to each requester (referred to as unicast). It is also more efficient than broadcasting one copy of the message to all nodes on the network, since many nodes may not want the message. The Internet Group Management Protocol [2], or IGMP, is a set of multicast extensions to the Internet Protocol [5]. It is widely deployed and in daily use (MBONE is one well-known example of an application that makes use of IGMP). A large coalition of vendors, called the IP Multicast Initiative [3], has been formed to promote this technology. Virtual local area networks, or VLANs, can roughly be equated to broadcast domains. VLANs have existed for some time as proprietary solutions from different vendors. Among other ways, VLANs can be implemented with IP multicast technology. An effort is currently under way to standardize all these implementations and give the VLAN concept a rigorous definition. The standards committee of the IEEE is working on a standard for VLANs called 802.1Q. This standard defines an architecture that goes well beyond multicast. This report will not address administration and management aspects of VLANs and will only concentrate on the use of 802.1Q VLANs for multicasting. The information about VLANs contained in this paper relies on the data from the December 20, 1996 edition of the draft 802.1Q standard [1]. It is important to note that multicasting is just one of several design goals for VLANs. Other features of VLANs, such as improved network management, tracking workstation movement and broadcast containment, are outside the scope of this report. Note: The remainder of this report assumes that the reader is familiar with the standards being discussed. A list of references included at the end of this document contains some useful pointers that can help in this regard. Key Issues Below is a list of requirements that the "ideal" multicast technology should satisfy: * Open standards: proprietary solutions do not scale, so any technology worth considering must be based on open standards. * Network infrastructure independence: the multicast technology should fit into a variety of network infrastructures, such as backbone WANs and campus/premise LANs. * Security: there must be a way to ensure that only authorized receivers can join multicast groups and gain access to the transmitted data. * Scalability: there must be no restrictions placed on location or number of members in a multicast group. * Multicast is a receiver-based concept: receivers must have the ability to join a particular multicast session without administrator intervention. Traffic is then delivered to all members of that group by the network infrastructure. * Dynamic membership: hosts may join and leave groups at any time. Groups themselves may be permanent or transient. * Concurrent membership: a host must be allowed to be a member of more than one group at a time. Analysis At this point, it is worthwhile to go into more detail about how the two approaches to multicast are structured architecturally. IGMP is an extension to IP. It is a link-level, zero-administration, zero-security protocol which defines a way for hosts on a subnet to join and leave multicast groups. Each host group is assigned a class D IP address. Permanent groups have IP addresses administratively assigned to them. Transient groups exist only for as long as they have members. The multicast IP datagrams are propagated through routers using the IP time to live (TTL) field. Periodically the local multicast router sends an IGMP Host Membership Query to the "all-hosts" group, to verify current memberships. IGMP updates are used by multicast routing protocols to communicate host group membership to neighboring routers, propagating group information through the internetwork. In comparison to IGMP, the 802.1Q standard is vastly more complex. It defines a Layer 3, port-based architecture which is largely media-independent. The design goals for the 802.1Q standard are significantly beyond just multicast - it addresses administration, routing, host configuration, distribution and mapping. Frames are identified as belonging to a particular VLAN through frame tagging. Each frame can be tagged implicitly or explicitly. Implicitly tagged frames do not have VLAN ID (VID) information in the frame header. VLAN switches classify frames by the VLAN port on which the frame was received (a mechanism called ingress rules). Explicitly tagged frames contain VLAN ID information in the frame header. Ingress rules classify each frame as it arrives to the VLAN switch according to the frame's VLAN membership. A frame can be discarded if the port is configured to allow tagged frames only and the received frame is untagged. After each frame is classified, it is then passed on to the forwarding process to update the filtering database. The egress rules are then used to determine the format into which the frame needs to be converted and the port on which it is supposed to be sent out. This information is contained in the port egress list associated with each port. The port egress list is updated through the VLAN Membership Resolution Protocol (VMRP) discussed below. Open Standards IGMP and 802.1Q VLANs both qualify as open standards. This came naturally for IGMP, which is an Internet Standard, developed through the regular IETF process. The IEEE effort in defining VLANs came after several vendors already had their proprietary VLAN solutions on the market. Consequently, the standardization process is not as smooth for VLANs, and the standard will not be finalized until later this year. IGMP by itself does not constitute a complete multicast solution. It is a link-level protocol, which describes a method for collecting group membership information from the hosts and propagating it through the internetwork. IGMP does not address the problem of efficiently routing multicast traffic. This problem is solved by using one of several IP routing protocols, which are represented by an entire separate set of Internet standards. Network Infrastructure Independence IGMP is inherently tied to IP. This bond prevents deploying IP multicast in networks that are not running TCP/IP. This is a direct consequence of IGMP being a layer 2 protocol. This restriction is not an issue for the deploying IGMP on the Internet, but it can be a serious limitation for the enterprise networks. 802.1Q VLANs are architected at layer 3. This removes the requirement that the underlying network runs IP. The price of increased flexibility is usually reduced performance. Inspecting layer 3 addresses in packets is more time consuming than looking at MAC addresses in frames. Both IGMP and 802.1Q VLANs have to deal with the issue of supporting multicast over links that are not multicast-enabled. The solution in both cases involves "tunneling" - the multicast data is encapsulated in higher-level packets. Security Providing secure multicasting is a non-trivial requirement in a global, highly heterogeneous network, such as the Internet. Ideally, two security barriers must be erected: authentication and encryption. A host wishing to join a multicast group may be required to authenticate itself. The data sent by the sender may be encrypted to prevent eavesdropping. Only authenticated members of the group should possess the decryption keys necessary to unscramble the data. Security considerations have not entered the 802.1Q standard at the time of this writing. The reasons are political rather than technical - some vendors argue that adding these requirements to the standard will introduce additional overhead into routers and switches and will result in lower performance and higher prices. The required technology already exists - the IEEE 802.10 Interoperable LAN/MAN Security standard has been ratified in 1992 and can be used for cryptographically separating VLANs. In the absence of built-in VLAN security at the lowest levels, the job of providing secure communications will be left to higher-level protocols, in much the same way as it is now being done in the Internet world with SSL, HTTPS, S/MIME and other secure Internet protocols. IGMP inherits the zero-security model from IP and cannot be used for secure multicasting without extra help from the applications themselves. Whether the absence of MAC-layer security is a bad thing is arguable. MAC-layer encryption adds a significant overhead, and can be redundant if the data is encrypted at the application level. Scalability IGMP is perfectly suited for the Internet. It is platform independent, simple to implement and well supported by a large number of vendors. There are no administration costs, since all group membership decisions are taken by the receivers. The performance of IGMP multicast primarily depends on the routing protocol being used. Different IP multicast routing protocols use different techniques to construct the multicast spanning trees; once a tree is constructed, all multicast traffic is distributed over it. The protocols developed for routing multicast data over the Internet fall into two categories - sparse-mode and dense-mode. The suitability of a particular protocol family depends on whether group members are expected to be densely distributed throughout the network, or to be sparsely distributed with limited available bandwidth. Comparison of these protocols is an interesting topic in itself, but it is outside the scope of this document. The thing to note is that the performance of IGMP multicast routing can be tuned to the requirements of a particular target audience - a great help to scalability. VLANs provide rich administrative support - an essential requirement for any enterprise network solution. It is safe to say that because of its administration model and the extra hardware requirements, the VLAN technology can not, and is not intended to scale to the size of the Internet. However, the Internet can serve as a backbone to carry multicast traffic between geographically separated portions of a VLAN. This way, VLANs can trivially scale to the enterprise level. Receiver-Based Multicast The number of members in a multicast group is unbounded. Hence, in order to be scalable, the sender of multicast data should have no knowledge of the receivers' identity - this job is best left to the routers on the network. IGMP satisfies this requirement - membership requests come solely from the receiving hosts, and the routers' job is to deliver the multicast traffic to those requesting it. This freedom comes at a price - there is no provision for centralized control over the consumers of the data. 802.1Q VLANs are targeted towards enterprise networks in which rich administrative capabilities are of prime importance. See the Dynamic Membership section, below. Dynamic Membership Requiring administrator intervention for changing group membership can severely limit the usefulness of multicast. Therefore, any multicast group management protocol must allow hosts to join and leave groups at any time. Both IGMP and 802.1Q VLANs make explicit provisions for dynamic multicast group membership. The mechanisms through which this is achieved is different between the two specifications. IGMP achieves dynamic group membership by defining two additional IP service interface operations: JoinHostGroup and LeaveHostGroup. Under 802.1Q, end stations and bridges communicate membership information through VMRP (VLAN Membership Resolution Protocol) requests. VMRP provides more flexibility than IGMP for group membership resolution. The reason is that with VMRP, both end stations and bridges of the VLAN can issue and revoke declarations relating to membership of VLANs. This leaves the end stations the freedom of selecting groups, while keeping the administrator's ability to configure the group membership. IGMP has a zero-administration model in which group membership decisions are left entirely to the hosts. Concurrent Membership Under IGMP, a station is free to send multiple JoinHostGroup requests. Joining a new group does not mean leaving any groups, so concurrent group membership is built into the protocol. It is the job of the link layer on the host to filter out multicast packets not intended to reach it. The host therefore only deals with the packets addressed to it - and to the host group(s) it is a member of. A host must be IGMP-enabled in order to listen to multicast traffic. 802.1Q VLANs also allow concurrent membership, although the mechanism is different. Concurrent membership requires a protocol for dynamic maintenance of the contents of the port egress lists for each port of a bridge and for propagating the information they contain to other bridges. This mechanism is called VMRP for VLAN Membership Resolution Protocol. VMRP allows a great amount of flexibility with respect to VLAN membership configuration. The VMRP triggering function mechanism exists that allows automatic configuration of port egress lists to occur on ports where the attached LAN segment has end stations attached to it that are unable to participate in VMRP protocol exchanges. This way, an end station does not have to support VMRP in order to be a member of multiple VLANs. Conclusions VLANs and IGMP are both viable technologies for multicast. However, they address different problems and are best suited for different applications. IGMP is best suited for the Internet and campus LANs. It provides no link-level security, no administration hooks and requires the underlying network to carry IP traffic. IP multicast can be used to define VLANs, but that requires a great deal of application-level work, since there is very little being done at the link level. Nevertheless, IP multicast-based VLANs have been implemented and are in wide use. 802.1Q is a standard for robust, enterprise-wide VLANs. The standard provides for significant administrative control and configuration flexibility. It is more complex and less scalable than IGMP. 802.1Q defines a technology for managing the ever-changing enterprise network topology and minimizing the network administration cost. Multicast is only a subset of the benefits of VLANs. Organizations that only want multicasting may not be able to justify the cost associated with VLAN deployment. VLAN best suits the network switching infrastructure where end stations are rarely stationary, and where there is high demand for network bandwidth and broadcast containment. References 1. "Draft Standard for Virtual Bridged Local Area Networks", Interworking Task Group of IEEE 802.1 (Document P802.1Q/D4, dated 12/20/1996) 2. "RFC 1112 - Host Extensions for IP Multicasting", S. Deering (available at http://info.internet.isi.edu/in-notes/rfc/files/rfc1112.txt) 3. IP Multicast Initiative (IPMI) white papers, Stardust Technologies (available at http://www.ipmulticast.com/community) 4. "The Virtual LAN Technology Report", David Passmore and John Freeman (available at http://www.3com.com/nsc/200374.html) 5. "RFC 791 - Internet Protocol", J. Postel (available at http://info.internet.isi.edu/in-notes/rfc/files/rfc791.txt)