Forwarding Multicast Frames on an Ethernet Bridge

Not applicable

Not applicable

The present invention relates to networks, and more particularly to forwarding multicast frames over an Ethernet bridged network infrastructure.

An Ethernet network with a bridged infrastructure improves networking performance, i.e., bandwidth, by separating point to point or unicast traffic. Such a network, as shown in FIG. 1, has one or more hosts coupled to a hub or common bus, with one hub being coupled to another via a bridge or switch. The bridge in turn is coupled via a router to the rest of the world, i.e., to the Internet, for example. However the bridged infrastructure does not separate, and thus improve the performance of, many to many or multicast traffic because the bridge, and hosts, treat multicast traffic as if it were broadcast traffic and floods it to all hosts. On the Ethernet network an Internet Protocol(IP)-multicast packet is encapsulated in an Ethernet multicast frame so that the IP-multicast packet shares the fate of the Ethernet multicast frame and is broadcast over the entire Ethernet bridged infrastructure.

A frame of data has a header, which includes an address space with a source address (the originator of the frame) and a destination address (the target of the frame), followed by data. For multicast traffic a network multicast packet is encapsulated within the frame as part of the data. The bridge does not look at the encapsulated network multicast packet, but merely at the source and destination addresses of the data frame header. The bridge maintains a forwarding table in which it contains a source address and a port of the bridge to which the source is coupled. The destination address of a frame is searched for within the forwarding table, and when found the frame is sent through the corresponding port to the host that has the destination address. If not found, the frame is broadcast--it is transmitted through all ports except the port on which it arrived. For broadcast frames, i.e., frames that are intended to be transmitted to all hosts, the destination address is tested to see if it falls within the broadcast address range, and if so the bridge broadcasts the frame. The bridge does not recognize multicast addresses, so multicast frames also are broadcast by the bridge.

The Ethernet system has 48 bits of address space that are divided up into:

(1) a broadcast address;

(2) multicast addresses; and

(3) unicast addresses.

The unicast addresses are the normal addresses, each address being assigned uniquely to a single board coupled to the network. A data frame addressed to a unicast address is forwarded by the bridge to the host to which the unique board identified by that address is coupled, while a data frame addressed to the broadcast address is forwarded to all hosts, and thence to all boards. But a multicast address is treated by the bridge as an unrecognized unicast address and broadcast.

The first facet of the problem in dealing with multicast addresses is on the host. Any frame addressed to a multicast address is received by every host, so that hosts that interface with the network may be interrupted for every multicast frame that appears on the hub, whether it is destined for them or not. This may be a major performance drain.

Next the bridge does not read the network level addresses that are encapsulated in the data frame, doing all its work at the data frame level, i.e., reading the data frame header. The bridge attempts to filter data frames between several hubs, each hub having one or more hosts attached to it. The bridge listens to source addresses on each hub and remembers on which bridge port it received such an address. The bridge then maintains a forwarding table which associates source address with the port on which it was heard. When it receives a data frame destined for a particular address, it searches its forwarding table to find a destination port. The bridge forwards the data frame to that port, if found, filtering the data traffic. If the bridge does not have the destination address in the forwarding table, or otherwise does not recognize the address, it treats the destination address as a broadcast address and outputs the data frame to every port. Thus bridges treat the multicast frames like broadcast frames.

Using a protocol entitled IGMP (Internet Group Management Protocol), as described in the Network Working Group Request for Comments (RFC) 1112, Appendix I (August 1989), hosts subscribe to a multicast session when they are polled by a router with a well-known specific multicast address. The multicast address from the router must be passed via the bridge as a broadcast frame to every host on every hub. If one or more of the hosts want to be part of a multicast session, the host or hosts respond by providing the address of the multicast session to which they want to subscribe. This information must be passed by the bridge back up to the router. If none of the hosts coupled to the bridge subscribe to a multicast session, then the router, when it receives a multicast frame, bypasses that bridge. However if one of the hosts coupled to the bridge subscribes to the multicast session, then the multicast frame is transmitted to the bridge which in turn, as discussed above, treats it as a broadcast frame and each host coupled to the bridge in turn accepts it as a broadcast frame.

There have been some attempts to solve this problem recently. Cisco Systems, Inc. of San Jose, Calif. sells bridges that work with a router which recognizes the network multicast address and performs the multicast polling at the router (network) level using a proprietary protocol between the bridge and the router.

Stephen Deering, in a 1988 paper entitled "Multicast Routing in Internetworks and Extended LANs" published by the Association for Computing Machinery, describes one technique prior to the IGMP protocol for multicasting in a simple bridged LAN using membership reports and a forwarding table algorithm. However the article does not describe how the bridge operates under the IGMP protocol, specifically what the interaction should be between the bridge and a router.

What is desired is a solution to the multicast problem in an Ethernet bridged network infrastructure using the IGMP protocol that assures that multicast frames are received only by subscribers to that multicast session without the use of proprietary hardware bridges or protocols.

Accordingly the present invention provides for forwarding multicast frames over a bridge in an Ethernet network infrastructure by using multicast destination addresses from a data frame to augment a forwarding table within the bridge to support multicasting. When a bridge sees a multicast address in a destination field of the data frame, it knows that the originating host is a subscriber to that multicast session and also wants to receive all data frames destined for that multicast address. The bridge enters the multicast address together with the source port into the forwarding table. The bridge then searches the forwarding table for the destination address and forwards the message to each port which has the corresponding multicast address in the forwarding table. Thus the bridge forwards a multicast data frame only to selected ports rather than broadcasting the multicast data frame to all ports.

The objects, advantages and other novel features of the present invention are apparent from the following detailed description when read in conjunction with the appended claims and attached drawing.

FIG. 1 is a block diagram of an Ethernet bridged network infrastructure for practicing the present invention.

FIG. 2 is a flow chart diagram for the forwarding of multicast frames over the Ethernet bridged network infrastructure of FIG. 1 by a bridge according to the present invention.

Referring to FIG. 1 one or more hosts P1-Pn are coupled together on one hub 10, and one or more hosts P(n+1)-Pm are coupled together on another hub 20, etc. The hubs 10-20 are coupled together via a bridge 30 having a port 32, 34 for each hub. The bridge 30 in turn is coupled via another port 36 to a router 40 at a router port 42. Another router port 44 is coupled to the rest of the world 50, i.e., other routers via the Internet. Each bridge 30 has a forwarding table 38 that it maintains. The bridge maintains the forwarding table by looking at all of the data frame traffic on the hubs 10-20 coupled to it. If the data frame has a broadcast destination address, the bridge 30 transmits the frame to all of its ports 32-36 except the one on which the frame was received so that all hosts P1-Pm receive the frame. If the data frame has a unicast destination address, the bridge 30 enters the source address identifying the frame originator and the corresponding port 32-36 into the forwarding table 38. Then the bridge 30 searches the forwarding table 38 to find an address corresponding to the destination address in the frame. If the destination address is found, the data frame is transmitted to the associated port 32-36 and the single host P1-Pm having that unique address receives the frame. If the destination address is not found, the data frame is broadcast. This is conventional bridge processing.

However if the frame has a multicast destination address, the bridge 30 now recognizes it as a multicast data frame from the multicast address and enters the destination address, i.e., the multicast subscription address, and corresponding port 32-36 into the forwarding table 38. Since the hosts P1-Pm respond to the router multicast polling passed through the bridge 30 by transmitting a multicast subscription frame, each hub 10-20 that has a host that subscribes to a particular multicast address is entered into the forwarding table 38. Then a search on the destination address may have more than one hit, i.e., more than one port 32-36 may have at least one host P1-Pm that has subscribed to that multicast session. The multicast data frame is then sent to each port 32-36 that has a subscribing host P1-Pm for that multicast address except the port on which it arrived. In this manner a multicast frame is only transmitted by the bridge 30 to the hubs 10-20 that have subscribing hosts P1-Pm, rather than to all ports, and each host only responds if it is a subscriber to the particular multicast session. Thus nonsubscribing hosts P1-Pm are not interrupted by multicast data frames as they are by broadcast data frames.

The process is more clearly described with reference to FIG. 2 and the following bridging code.

Thus the present invention provides forwarding of multicast data frames on a bridge in an Ethernet bridged network infrastructure by entering multicast destination addresses in the forwarding table as well as source addresses and then searching the addresses for a match with the destination address, forwarding the multicast data frame to all ports that have subscribers to the addressed multicast session.