WO1996034474A1 - Broadcast transmission in a data network - Google Patents

Broadcast transmission in a data network Download PDF

Info

Publication number
WO1996034474A1
WO1996034474A1 PCT/US1996/005853 US9605853W WO9634474A1 WO 1996034474 A1 WO1996034474 A1 WO 1996034474A1 US 9605853 W US9605853 W US 9605853W WO 9634474 A1 WO9634474 A1 WO 9634474A1
Authority
WO
WIPO (PCT)
Prior art keywords
multicast
host
packet
bridge
network
Prior art date
Application number
PCT/US1996/005853
Other languages
French (fr)
Inventor
Kenneth Virgile
Original Assignee
Cabletron Systems, Inc.
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Family has litigation
First worldwide family litigation filed litigation Critical https://patents.darts-ip.com/?family=23698750&utm_source=google_patent&utm_medium=platform_link&utm_campaign=public_patent_search&patent=WO1996034474(A1) "Global patent litigation dataset” by Darts-ip is licensed under a Creative Commons Attribution 4.0 International License.
Application filed by Cabletron Systems, Inc. filed Critical Cabletron Systems, Inc.
Priority to AU55792/96A priority Critical patent/AU5579296A/en
Publication of WO1996034474A1 publication Critical patent/WO1996034474A1/en

Links

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00Data switching networks
    • H04L12/02Details
    • H04L12/16Arrangements for providing special services to substations
    • H04L12/18Arrangements for providing special services to substations for broadcast or conference, e.g. multicast
    • H04L12/1886Arrangements for providing special services to substations for broadcast or conference, e.g. multicast with traffic restrictions for efficiency improvement, e.g. involving subnets or subdomains
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00Data switching networks
    • H04L12/02Details
    • H04L12/16Arrangements for providing special services to substations
    • H04L12/18Arrangements for providing special services to substations for broadcast or conference, e.g. multicast
    • H04L12/185Arrangements for providing special services to substations for broadcast or conference, e.g. multicast with management of multicast group membership

Definitions

  • the present invention relates to a hierarchically organized communication networks which transmit messages therein.
  • the communications network may transmit a bitstream therein organized into packets.
  • the present invention especially relates to the transmission of multicast packets in such a network.
  • FIG 1 shows a conventional a hierarchically organized communications network
  • the communications network has a wide area network (WAN), such as the internet, at the highest level of the hierarchy.
  • a campus network 1 5 is interconnected to the WAN by a router RI .
  • the campus network 1 5 is so called because it is typically located at a single geographic campus of several buildings.
  • the interconnections may include any combination of wires, coaxial cables, optical fibers, circuit switches, packet switches, etc.
  • the router RI interconnects a backbone network of the campus network 15 to the WAN. Connected to the backbone network are additional routers r2, r3 and r4. Each additional router r2, r3 and r4 connects a respective subnetwork A, B or C to the backbone network.
  • the campus network 1 5 is at a middle level of the hierarchy and subnetworks A, B & C of the campus network 1 5 are at a lower level in the hierarchy.
  • the subnetworks A,B,C are typically isolated to a single, small geographic area such as an office building or floor of an office building.
  • the WAN typically sprawls from geographic area to geographic area.
  • the WAN itself typically includes a number of routers (not shown) for routing communications from campus network to campus network.
  • the communication between routers on the WAN and on the backbone network is illustratively achieved according to the internet protocol (IP).
  • IP internet protocol
  • protocol means a collection of semantic and syntactic rules obeyed by the devices which communicate according to the protocol.
  • the router r2 is connected to bridges bl and b2 of the subnetwork A, the router r3 is connected to bridge b3 of the subnetwork B and the router r4 is connected to the bridge b4 of the subnetwork C.
  • Each bridge bl -b4 is connected to one or more network segments or collision domains which illustratively are local area networks (LANs).
  • the bridge bl is connected to network segments LI and L2
  • the bridge b2 is connected to network segments L3 and L4
  • the bridge b3 is connected to network segments L5, L6 and L7 and the bridge b4 is connected to network segment L8.
  • Each network segment L1-L8 comprises one or more interconnected hosts computers hi -hi 7.
  • the network segment LI includes hosts hi, h2 and h3, the network segment L2 includes the host h4, the network segment L3 includes the hosts h5, h6 and h7, the network segment L4 includes the host h8, the network segment LS includes the host h9, the network segment L6 includes the host hlO and hi 1, the network segment L7 includes the hosts hl2, hl3 and hi 4 and the network segment L8 includes the hosts hlS, hl6 and hl7.
  • the network segments L1-L8 may be Ethernet LANS, token ring LANs or FDDI LANS, for example. Communication may be achieved locally within each network segment L1-L8 according to one of a number of protocols.
  • each host computer is connected via an I/O interface to a common broadcast medium (which broadcast medium may be carried by a coaxial cable, unshielded twisted pairs of wires, etc.).
  • a host communicates on the medium by transmitting a bitstream organized into packets.
  • FIG 2 illustrates an illustrative packet 20, which comprises a header section 22 and a payload section 24.
  • a host which desires to communicate writes data in the payload section 24, and an address of the intended recipient host in the header section 22.
  • all hosts on a network segment are assigned a unique identifier or address.
  • the host transmits its packet 20 from an I/O interface connected to the host onto the common broadcast medium. If the common broadcast medium is currently being used by another host to transmit a packet, then the host waits until the common broadcast medium is available. The transmitted packet 20 is received at the I/O interface of each other host on the network segment. Each host then examines the destination address written in the header section 22 of the packet 20. If the destination address matches the destination address of the host, the host accepts the packet 20 and may examine the contents of the payload section 24. If the destination address does not match, the host discards the packet 20.
  • each host transmits a jamming signal for a specified period of time and waits a variable amount of time before reattempting transmission of its packet. See U.S. Patent No. 5,355,375. Collisions are only possible within an individual collision domain or network segment. For instance, the communication amongst the hosts hl-h3 and bridge bl in the network segment LI does not effect the communication amongst the host h4 and bridge bl in the network segment L2. The delay incurred in transmitting a packet on a network segment (as caused by collisions or otherwise) increases with the increase of communications traffic on each segment.
  • CSMA CD Carrier Sense Multiple Access with Collision Detection
  • the bridge enables inter-segment communication while isolating the two network segments so that they operate as independent collision domains.
  • the bridges bl-b4 also can enable communication between network segments that communicate according to different protocols. For instance, the bridge bl can enable communication by the host h4 in the network segment L2, which is a Token Ring LAN, with the host h2 in the network segment LI, which is an Ethernet LAN.
  • the bridges within a subnetwork pass control packets between each other to determine the best route for reaching each host in each attached network segment. Thereafter, each bridge receives each packet transmitted on its attached network segments. If the bridge (e.g., bridge bl) receives a packet from one network segment (e.g., LI) containing a destination address of a host in another network segment, (e.g., the host h8 in network segment L4) the bridge transmits the packet in another attached network segment on a route to the network segment that contains the destination host.
  • one network segment e.g., LI
  • a destination address of a host in another network segment e.g., the host h8 in network segment L4
  • the route from host hi in network segment LI to the host h8 in the network segment L4 illustratively comprises: hl-Ll-bl-L2-b2-L4-h8.
  • the bridge bl retransmits a packet received from host hi destined to host h8 on network segment L2.
  • the bridges enable the hosts in one subnetwork to communicate with the hosts in other subnetworks.
  • IP (internet protocol) addresses may be assigned to each host which includes the destination host's address in the particular subnetwork concatenated to at least a unique address that is assigned to the subnetwork in which the destination host is located.
  • the host hi in the subnetwork A wishes to transmit a packet to the host hi 5 in the subnetwork C.
  • the host hi writes the IP address of the node hi 5 (which includes at least the destination address of the subnetwork C concatenated to the destination address of the host hi 5) in a packet and transmits the packet on its network segment LI.
  • the packet is received at, amongst other places, the bridge bl. If a bridge (e.g., the bridge bl) in a particular subnetwork receives a packet with a destination address that is foreign to the particular subnetwork, the bridge transmits the packet to its attached router (e.g., r2).
  • the bridge transmits the packet to its attached router (e.g., r2).
  • the packet is then transmitted via the backbone network to the router that connects to the subnetwork containing the destination host.
  • the packet may be transmitted from the router r2 via the backbone network to the router r4.
  • each router which receives a packet illustratively uses the destination address (or a portion thereof) to index a routing table stored at the router.
  • the indexed router table entry indicates the next router to which the packet must be transmitted.
  • the router e.g., router r4 that attaches the subnetwork (e.g., subnetwork C) containing the destination host (e.g., host hi 5)
  • the router transfers the packet to the attached bridge (e.g., b4).
  • the bridge then transmits the packet to the destination host.
  • the discussion above has been limited to unicast packet communication wherein a packet is transmitted from a single source host to a single destination host.
  • the network 1 0 also supports multicast communication, wherein a packet is transmitted from a single source - host to multiple hosts.
  • U.S. Patent No. 5,331 ,637 describes multicast routing and, in particular, how to implement multicast routing at the WAN level of the hierarchy.
  • multicast communication of packets is supported in the communications network 1 0 at the network level of communications according to the Internet Group Management Protocol (IGMP), IETF RFC 112, Host Extensions for IP Multicasting.
  • IGMP Internet Group Management Protocol
  • IETF RFC 112 Host Extensions for IP Multicasting.
  • multicast groups of hosts are identified, wherein each group is a collection of destination hosts for packets for a particular communication.
  • Each multicast group is assigned a special multicast address which bears no relation to any single host of the multicast group.
  • Each router which connects a campus network 15 to the WAN (e.g., the router RI ) periodically transmits a "Host Membership Query" multicast control packet with a destination address that specifies all of the hosts of the campus network 1 5.
  • each host transmits back to the router (e.g., the router RI) a "Host Membership Report" multicast control packet that indicates all of the groups to which the host belongs.
  • a host can transmit a "Join Host Group” or "Leave Host Group” multicast control packet to the router (e.g., the router RI) at any time to join or leave a multicast group.
  • the router receives these messages and updates its routing tables accordingly.
  • a host When a host, e.g., the host hi, desires to transmit a multicast packet, it writes a multicast address of an appropriate multicast group in the destination field. The host then transmits the packet to its attached bridge, e.g., the bridge bl (via the subnetwork LI). The bridge has no way of knowing the location of the destination host (because the multicast -destination address bears no relationship to the destination address of a single host). Thus, the bridge retransmits the multicast packet to each attached subnetwork and router, other than the subnetwork or router from which the packet originated, e.g., the subnetworks L2, L3 and the router r2.
  • the bridge retransmits the multicast packet to each attached subnetwork and router, other than the subnetwork or router from which the packet originated, e.g., the subnetworks L2, L3 and the router r2.
  • the attached router accesses its routing table using the multicast destination address.
  • the accessed routing table entry may indicate more than one next router to which the packet must be transmitted, e.g., the router RI and the router r3.
  • the router transmits a copy of the packet to each indicated next router.
  • the packet is selectively routed and replicated in route.
  • Each router that receives a copy of the multicast packet performs the same table access procedure.
  • a router e.g., the router r4, receives a packet that must be transmitted to an attached subnetwork, e.g., the subnetwork C.
  • the bridge When a multicast packet is received at a bridge of the subnetwork, e.g., the bridge b4 of the subnetwork C, the bridge has no way of knowing to which attached network segment (or router) the packet is destined. This is because the packet has a multicast address which bears no relationship to any individual host. Furthermore, the multicast packet can be destined to more than one host in more than one attached network segment and or router. Thus, the bridge retransmits the multicast packet in each attached network segment and to each attached router. The packets transmitted in the network segments are received by each host. Each host then compares the multicast destination address to the multicast destination addresses of the groups of which it is a member.
  • a bridge retransmits a received multicast packet in each attached network segment even if one of the attached network segments is devoid of destination hosts of the multicast packet (i.e., even if the network segment does not have any hosts that are members of the multicast group of the multicast packet). This resulting in unnecessary bandwidth reduction in some attached network segments that are devoid of destination hosts.
  • the wasted bandwidth can be - o - very high and can noticeably degrade performance on a network segment.
  • the solution to improving network segment performance is to reconfigure the campus network by increasing the number of routers and redistributing (i.e., reconnecting) the network segments or hosts amongst the routers.
  • this solution is disadvantageous because routers are relatively expensive and difficult to manage.
  • the Deering reference teaches that the hosts transmit special control packets that are destined to all bridges of the campus network indicating to which multicast group the host belongs.
  • the bridges compile such information, in order to construct the multicast forwarding, table and to determine when entries of the multicast forwarding table have become stale and therefore must be discarded.
  • the environment of the present invention is a hierarchically organized communications network.
  • the illustrative communications network environment of the present invention is a subnetwork of a campus network which campus network provides for inter-subnetwork unicast and multicast packet communication.
  • the subnetwork includes an internetworking device, such as a bridge, for connecting the subnetwork to the campus network.
  • a bridge internetworking device constructs a multicast forwarding table (for retransmitting multicast packets) as follows.
  • Selected hosts transmit, on a route to one or more routers, a host membership packet indicating at least one multicast group to which the hosts belong, (for instance, according to IGMP, the hosts may transmit Join Host Group, Leave Host Group or Host Membership Report packets.)
  • a bridge on the route to a router receives each host membership packet. Using the host membership packet, the bridge updates multicast forwarding table entries corresponding to one or more multicast groups of the host which transmitted the packet. In this fashion, the bridge ensures that the multicast forwarding table entries corresponding to each multicast group only indicate those network segments on routes to hosts that are members of the corresponding multicast groups.
  • a bridge then routes the host membership packet to the router in the normal fashion, i.e., retransmits the host membership packet on the route to the router. (The router in turn uses the membership packet to update routing tables thereat.) The bridge then retransmits multicast message packets received thereat, which are destined to the multicast groups joined by the hosts according to the multicast forwarding table maintained at the bridge.
  • a bridge utilizes host membership packets normally destined to a router for purposes of maintaining a multicast table. This is a very efficient way to maintain a multicast routing table with a bridge.
  • Multicast message packets are received in a subnetwork at the internetworking device (bridge).
  • the multicast message packet may have originated from outside the subnetwork or from a host within the subnetwork.
  • the internetworking device retransmits the packet to only those network segments of the subnetwork on a route to a destination host for the received multicast message packets.
  • the destination host is contained in a network segment that is directly connected to the internetworking device.
  • the route to the destination host may include only the network segment containing the host.
  • the destination host is contained in a network segment that is not directly connected to the internetworking device. Rather, the network segment containing the destination host is connected to a second internetworking device.
  • the second, internetworking device is connected via an intervening network segment to the internetworking device which received the multicast packet.
  • the route to the destination, host includes the intervening network segment, the second internetworking device and the network segment containing the destination host.
  • the internetworking device retransmits the packet in the directly connected network segment containing the destination host while in the latter case the internetworking device retransmits the packet in the intervening network segment.
  • an apparatus and method are provided for controlling the retransmission of multicast packets within a subnetwork to conserve bandwidth.
  • multicast packets originating from, or destined to, outside the subnetwork do not interfere with the network segments that do not contain any hosts that belong to the multicast group of the multicast packets.
  • FIG 1 shows a conventional communications network.
  • FIG 2 shows a conventional packet.
  • FIG 3 shows a subnetwork including a bridge according to the present invention.
  • FIG 4 shows an illustrative forwarding table according to an embodiment of the present invention.
  • FIG 5 is a flowchart which schematically illustrates a multicast forwarding table maintenance process according to an embodiment of the present invention.
  • FIG 6 is a flow chart which schematically illustrates a multi-cast message packet routing process according to an embodiment of the present invention.
  • FIG 3 shows a subnetwork 100 according to the present invention.
  • the subnetwork 100 is connected to a router rlOO of a campus network or directly to a WAN.
  • the subnetwork 100 includes a bridge b 100 connected to three network segments, namely, LI 00, L101 and L102.
  • the network segment L100 includes a number of hosts WOO, hlOl, W02, W03, hl04, hl05, hl06, hl07 and hl08 interconnected to form a LAN such as an Ethernet LAN.
  • the network segment 102 includes a number of hosts hllO, hi 11, hi 12, hi 13, hi 14, hi 15, hi 16, hi 17, hi 18, hi 19 connected to form a LAN.
  • the network segment L101 only includes the host 109 which is also connected to form a LAN.
  • the bridge bl 00 includes a bus 110, a processor 120, a memory 130 and 4 I/O interfaces 141, 142, 143 and 144.
  • I/O interfaces 141, 142, 143 and 144 may be provided to support each router and network segment attached to the bridge blOO.
  • the I/O interface 141 is connected to the router rlOO.
  • the I/O interface 142 is connected to the network segment L100.
  • the I/O interface 143 is connected to the network segment L 101.
  • the I/O interface 144 is connected to the network segment L 102.
  • Packets which may be received via the I/O interfaces 141-144 may be transferred via the bus 110 to the processor 120 or memory 130.
  • the memory 130 is for, amongst other things, temporarily buffering received packets.
  • the processor 120 can access the packets in the memory 130, for example, to read or write data in the header portions of the packets for purposes of translating a packet from one protocol to another protocol.
  • the processor 120 can also examine the address of the packet header to determine from which I/O interface 141-144 the packet should be retransmitted.
  • the bridge bl 00 conserves the bandwidth of the other network segments (or routers) which do not contain the destination host of the packet.
  • multicast packets received at the bridge blOO are only retransmitted onto the network segments L100, L101 or L102 that contain destination hosts of the multicast packets.
  • the bridge bl 00 refrains from retransmitting multicast packets onto those attached network segments L100, L101 or L102 that are devoid of destination hosts of the multicast packets.
  • the processor 120 maintains a forwarding table with entries corresponding to multicast addresses. Alternatively, additional forwarding table entries as described below may be added to a forwarding table already maintained by the bridge blOO.
  • each table entry 210, 220, 230, 240, 250, 260, 270, and 280 includes a multicast destination address index field 212, 222, 232, 242, 252, 262, 272, or 282.
  • the multicast destination address index field contains a multicast destination address of a particular multicast group. This field is used by the processor 120 for retrieving a multicast forwarding table entry 210-280 that corresponds to a particular multicast group.
  • the table entry also includes an I/O interface field 214, 224, 234, 244, 254, 264, 274 and 284.
  • This field is for storing indications of only those I/O interfaces 142- 144 that connect the bridge blOO to a network segment that contains a destination host of the multicast address.
  • This field 214-284 also stores indications of I/O interfaces 141 that connect the bridge blOO to a router rlOO that provides communication access external to the network segment 100.
  • each table entry 210-280 includes a list field 216, 226, 236, 246, 256, 266, 276 or. 286 for storing a list of the hosts which are members of the multicast group corresponding to the table entry.
  • the multicast forwarding table entry 230 corresponds to the multicast group for an audio-video teleconference which has the address AV 1 stored in the multicast destination address index field 232.
  • the multicast forwarding table entry 230 also includes the indications of the I/O interfaces 143, 144 and 141 (from which the packets must be retransmitted) stored in the I/O interface field 234.
  • the multicast forwarding table entry 230 includes a list of the hosts hl09, hll4, hi 17 and hi 19 which are members of the multicast group AVI stored in the host list field 236.
  • FIG 5 is a flowchart that illustrates a process executed by the bridge blOO in constructing and modifying the multicast forwarding table entries 210-280 of FIG 4.
  • the processor 120 determines if a received packet is a multicast control packet.
  • Such packets have a well defined and easily identifiable form.
  • the processor executes a routing process (step S2) described below. If the received packet is a multicast control packet, the processor 120 executes step S3. In step S3, the processor 120 determines if the packet contains an instruction from the attached router to each host hlOl-hl 19 to report all of its current multicast group memberships (e.g., a Host Membership Query packet).
  • the processor 120 keeps track of from which router and via which I/O interface 141-144 the packet was received, e.g., by temporarily storing this information in the memory 130. As discussed in greater detail below, the processor 120 uses such information in the construction of forwarding table entries corresponding to multicast groups. In particular, such information is used to update the forwarding tables to ensure that multicast packets originating in the subnetwork 100, and destined outside the subnetwork 100, are transmitted from the bridge bl 00 to the routers rlOO that can deliver multicast packets to such destinations external to the subnetwork 100. If the packet is not a Host Membership Quay packet, the processor 120 proceeds to step S5.
  • step S5 the processor determines if the packet contains a report from a host of all of its current multicast group memberships (e.g., a Host Membership Report packet). Such a packet contains the multicast destination address of each multicast group of which the host wishes to be a member. If a Host Membership Report packet is received, then, in accordance with step S6, the processor 120 executes steps S13-S15 for each multicast destination address (of each multicast group) specified in the packet. If the packet is not a Host Membership Report packet then the processor 120 proceeds to step S7.
  • a Host Membership Report packet e.g., a Host Membership Report packet.
  • step S7 the processor 120 determines if the packet contains an indication that a host is leaving a multicast group (e.g., is a Leave Host Group packet). If not, the processor 120 executes step SI 1. If the packet does contain an indication that the host is leaving a multicast group, the processor 120 executes steps S8-S10. In step S8, the processor 120 retrieves the multicast forwarding table entry corresponding to the destination address of the multicast group designated in the received packet. For example, suppose the packet contained an indication that host hl09 desired to leave the multicast group AVI. The processor 120 would thus retrieve from the memory 130 the forwarding table entry 230 that has the multicast destination address AVI stored in the multicast destination address index field 232.
  • the packet contains an indication that host hl09 desired to leave the multicast group AVI.
  • the processor 120 would thus retrieve from the memory 130 the forwarding table entry 230 that has the multicast destination address AVI stored in the multicast destination address index field 232.
  • step S9 the processor 120 deletes the indication of the host which transmitted the packet from the list of hosts contained in the entry. For instance, the processor 120 would delete the indication for hl09 from the host list field 236 of the multicast forwarding table entry 230. Thereafter, the processor 120 executes step S10, wherein the processor 120 updates the indicators stored in the I/O interface field 234 of the I/O interfaces from which the packet must be transmitted. In particular, the processor 120 examines each remaining host indication contained in the host list field 236. If necessary, the processor 120 deletes an indicator for an I/O interface from the I/O interface field 234 if none of the remaining hosts in the host list are connected via that I/O interface.
  • the host which transmitted the multicast control packet was formerly the only host on a particular network segment that belonged to that multicast group.
  • the host hl09 was formerly the only host of the list 236 connected to the bridge blOO by the I/O interface 143.
  • the indication for the I/O interface 143 is deleted from the I/O interface field 234.
  • step SI 1 the processor 120 determines if the received packet contains an indication that a host wishes to join a particular multicast group (e.g., a Join Host Group packet). If not, then the packet must be some unidentifiable multicast control packet. In such a case, in step SI 2, the processor executes the routing process described below. If a multicast control packet for joining a multicast group was received, the processor 120 executes steps S13-S15. In step SI 3, the processor 120 first attempts to retrieve a multicast forwarding table entry using, as an index, the multicast forwarding address of the group that the host wishes to join. If the processor 120 is able to retrieve a corresponding multicast forwarding table entry from the memory 130, the processor 120 then executes step S14.
  • a host e.g., a Join Host Group packet
  • step SI 4 the processor 120 adds the destination address of the host which transmitted the control packet to the host list field of the multicast forwarding table entry.
  • step SI 5 the processor 120 updates the I/O interface indications in the I/O interface field of the multicast forwarding table entry in accordance with the revised host list. That is, suppose the newly added host is connected to the bridge blOO via an I/O interface not already indicated in the I O interface field. Such- ould be the case if the newly added host is the only multicast group member on a particular network segment. If such is the case, then an indicator for the I/O interface which connects the network segment of the newly added host must be added to the I/O interface field of the table entry.
  • the bridge After each of the steps S4, S6, S10 and SI 5, the bridge also routes the received packet towards its intended destination.
  • the multicast packet contains an "all hosts" address. This packet is thus retransmitted on every network segment on a route to a host of the subnetwork 100.
  • steps S6, S 10 and S 15 such multicast control packets are destined to an attached router, such as the router rlOO.
  • the bridge blOO retransmits such packets on a route to that router.
  • the router in turn updates its internal routing tables in response to receiving such packets in a well known manner.
  • the hosts need not transmit special packets to the bridges. Rather, the bridges blOO according to the present invention "eavesdrop" on the very same packets used to change host membership on the WAN or campus network level according to, for instance, IGMP protocol. Thus, network segment bandwidth is conserved since a single multicast control packet serves two purposes. Moreover, neither the hosts nor routers need be specially adapted to implement the invention. Rather, only the bridges need be adapted. While not shown in FIGS, the processor 120 also performs an "aging-out" process. Generally speaking, the forwarding table 200 is only accurate for a limited period of time.
  • the forwarding table 100 is presumed to be stale or inaccurate after a fixed period of time, e.g., every five minutes.
  • the processor 120 flushes or discards the forward table 200 in the memory 130 and begins constructing a new forwarding table 200 as per the above-described -process. See S. Deering, Multicast Routing in Internetworks and Extended LANs, ACM Symposium On Communication- Architectures and Protocols, ACM SIGCOMM pp. 55-64, Aug., 1988 for an exemplary "aging- out" process.
  • FIG 6 shows a process executed by the bridge blOO in routing, i.e., retransmitting received packets.
  • the processor 120 examines the received packet in the memory to determine if it is a multicast message packet (i.e., a packet for delivering data to multiple destinations). If not, the processor 120 executes step SI 7 wherein the processor routes the packet using conventional unicast routing (described above). If the packet is a multicast message packet, the processor 120 executes step SI 8. In step SI 8, the processor 120 uses the multicast destination address as an index to retrieve a corresponding entry from the multicast forwarding table 200 (FIG 4). If the table does not have an entry corresponding to the multicast destination address of the received packet then the processor 120 executes step SI 9. This may occur for various reasons including:
  • step 19 the processor 120 discards or retransmits the received packets depending on why the multicast destinating group is not contained in the forwarding table 200. For example, in the event of conditions (a)-(b), the received packet is discarded. On the other hand, in the event of conditions (c)-(e) the processor 120 retransmits the received packet in a conventional fashion, namely, the processor 120 retransmits the received packet from each I/O interface 142-144 other than the I/O interface 141 from which the packet was received.
  • step S20 the processor 120 retrieves the indications of the I/O interfaces stored in the I/O interface field of the retrieved multicast forwarding table entry.
  • the processor 120 then retransmits the received multicast packet only from the I/O interfaces 141-144 indicated in the I/O interface field except for the I/O interface from which the packet was received. For example, suppose the bridge blOO receives a multicast packet from the router rlOO destined to the multicast group VI . This packet is received via I/O interface 141 and temporarily stored in the memory 130.
  • the processor 120 retrieves the table entry 250 corresponding to the multicast group of the address VI. The processor then retrieves all of the I/O interface indications from the I/O interface field 254. The only indicated I/O interfaces are 141 and 142. However, the packet was received from I/O interface 141. Thus, the received multicast packet is only retransmitted from the I/O interface 142. As such, the received multicast packet is retransmitted on the attached segment L100 but not on the attached network segments LI 01 or LI 02.
  • the packet is transmitted to the router rlOO (from which the packet may be transmitted to host external to the subnetwork 100) and to the hosts hi 13, hll4 via the network segment LI 02. However, the packet is not retransmitted on the network segment L101.
  • the bridges bl and b2 self-configure routes to the hosts of subnetworks to which they are not directly attached by passing control packets back and forth to each other. For instance, the bridge bl may determine that packets destined to hosts in the subnetworks L3 and L4 may be transmitted thereto via the intervening network segment L2 and the bridge b2.
  • the processor 120 updates the I/O interface field, the processor 120 ensures that only I/O interfaces that attach network segments on a route to a host of the host list are included therein.
  • I/O interfaces include those that attach network segments which contain multicast destination hosts and those which attach intervening network segments on a route to multicast destination hosts.
  • a system and method are disclosed for routing multicast packets in a subnetwork so as to conserve bandwidth in at least some of the network segments or collision domains of the subnetwork.
  • multicast packets are only retransmitted in the network segments that are on a path to a host that is a member of the multicast group of hosts to which the multicast packet is destined.

Abstract

A system and method are disclosed for routing multicast packets in a subnetwork so as to conserve bandwidth in at least some of the network segments or collision domains of the subnetwork. In particular, multicast packets are only retransmitted in the network segments that are on a path to a host that is a member of the multicast group of hosts to which the multicast packet is destined.

Description

BROADCAST TRANSMISSION IN A DATA NETWORK
Field of the Invention
The present invention relates to a hierarchically organized communication networks which transmit messages therein. For instance, the communications network may transmit a bitstream therein organized into packets. The present invention especially relates to the transmission of multicast packets in such a network.
Background of the Invention FIG 1 shows a conventional a hierarchically organized communications network
1 0. In particular, the communications network has a wide area network (WAN), such as the internet, at the highest level of the hierarchy. A campus network 1 5 is interconnected to the WAN by a router RI . The campus network 1 5 is so called because it is typically located at a single geographic campus of several buildings. The interconnections may include any combination of wires, coaxial cables, optical fibers, circuit switches, packet switches, etc. The router RI , interconnects a backbone network of the campus network 15 to the WAN. Connected to the backbone network are additional routers r2, r3 and r4. Each additional router r2, r3 and r4 connects a respective subnetwork A, B or C to the backbone network. The campus network 1 5 is at a middle level of the hierarchy and subnetworks A, B & C of the campus network 1 5 are at a lower level in the hierarchy. The subnetworks A,B,C are typically isolated to a single, small geographic area such as an office building or floor of an office building. The WAN, on the other hand, typically sprawls from geographic area to geographic area. The WAN itself typically includes a number of routers (not shown) for routing communications from campus network to campus network. The communication between routers on the WAN and on the backbone network is illustratively achieved according to the internet protocol (IP). (Herein, protocol means a collection of semantic and syntactic rules obeyed by the devices which communicate according to the protocol.)
The router r2 is connected to bridges bl and b2 of the subnetwork A, the router r3 is connected to bridge b3 of the subnetwork B and the router r4 is connected to the bridge b4 of the subnetwork C. Each bridge bl -b4 is connected to one or more network segments or collision domains which illustratively are local area networks (LANs). The bridge bl is connected to network segments LI and L2, the bridge b2 is connected to network segments L3 and L4, the bridge b3 is connected to network segments L5, L6 and L7 and the bridge b4 is connected to network segment L8. Each network segment L1-L8 comprises one or more interconnected hosts computers hi -hi 7. The network segment LI includes hosts hi, h2 and h3, the network segment L2 includes the host h4, the network segment L3 includes the hosts h5, h6 and h7, the network segment L4 includes the host h8, the network segment LS includes the host h9, the network segment L6 includes the host hlO and hi 1, the network segment L7 includes the hosts hl2, hl3 and hi 4 and the network segment L8 includes the hosts hlS, hl6 and hl7. The network segments L1-L8 may be Ethernet LANS, token ring LANs or FDDI LANS, for example. Communication may be achieved locally within each network segment L1-L8 according to one of a number of protocols. Since most deployed network segments L1-L8 are Ethernet LANS, the Ethernet protocol for communication is used to illustrate the invention. According to the Ethernet protocol, each host computer is connected via an I/O interface to a common broadcast medium (which broadcast medium may be carried by a coaxial cable, unshielded twisted pairs of wires, etc.). A host communicates on the medium by transmitting a bitstream organized into packets. FIG 2 illustrates an illustrative packet 20, which comprises a header section 22 and a payload section 24. A host which desires to communicate writes data in the payload section 24, and an address of the intended recipient host in the header section 22. (Illustratively, all hosts on a network segment are assigned a unique identifier or address.) If the common broadcast medium is not currently being used, then the host transmits its packet 20 from an I/O interface connected to the host onto the common broadcast medium. If the common broadcast medium is currently being used by another host to transmit a packet, then the host waits until the common broadcast medium is available. The transmitted packet 20 is received at the I/O interface of each other host on the network segment. Each host then examines the destination address written in the header section 22 of the packet 20. If the destination address matches the destination address of the host, the host accepts the packet 20 and may examine the contents of the payload section 24. If the destination address does not match, the host discards the packet 20.
It is possible that two hosts of the same network segment may attempt to transmit a packet concurrently. If this happens, a collision is said to occur. According to the Carrier Sense Multiple Access with Collision Detection (CSMA CD) protocol, in the event of a collision, each host transmits a jamming signal for a specified period of time and waits a variable amount of time before reattempting transmission of its packet. See U.S. Patent No. 5,355,375. Collisions are only possible within an individual collision domain or network segment. For instance, the communication amongst the hosts hl-h3 and bridge bl in the network segment LI does not effect the communication amongst the host h4 and bridge bl in the network segment L2. The delay incurred in transmitting a packet on a network segment (as caused by collisions or otherwise) increases with the increase of communications traffic on each segment.
Sometimes it is desirable to communicate from a host in one network segment to a host in another network segment of the same subnetwork. Such communication may be achieved using the bridges bl-b4. The bridge enables inter-segment communication while isolating the two network segments so that they operate as independent collision domains. The bridges bl-b4 also can enable communication between network segments that communicate according to different protocols. For instance, the bridge bl can enable communication by the host h4 in the network segment L2, which is a Token Ring LAN, with the host h2 in the network segment LI, Which is an Ethernet LAN. The bridges within a subnetwork (e.q., the bridges b 1 -b2 in the subnetwork A) pass control packets between each other to determine the best route for reaching each host in each attached network segment. Thereafter, each bridge receives each packet transmitted on its attached network segments. If the bridge (e.g., bridge bl) receives a packet from one network segment (e.g., LI) containing a destination address of a host in another network segment, (e.g., the host h8 in network segment L4) the bridge transmits the packet in another attached network segment on a route to the network segment that contains the destination host. For instance, the route from host hi in network segment LI to the host h8 in the network segment L4 illustratively comprises: hl-Ll-bl-L2-b2-L4-h8. Thus, the bridge bl retransmits a packet received from host hi destined to host h8 on network segment L2. In addition to enabling inter-segment communication within a subnetwork, the bridges enable the hosts in one subnetwork to communicate with the hosts in other subnetworks. To that end, IP (internet protocol) addresses may be assigned to each host which includes the destination host's address in the particular subnetwork concatenated to at least a unique address that is assigned to the subnetwork in which the destination host is located. As an example, suppose the host hi in the subnetwork A wishes to transmit a packet to the host hi 5 in the subnetwork C. The host hi writes the IP address of the node hi 5 (which includes at least the destination address of the subnetwork C concatenated to the destination address of the host hi 5) in a packet and transmits the packet on its network segment LI. The packet is received at, amongst other places, the bridge bl. If a bridge (e.g., the bridge bl) in a particular subnetwork receives a packet with a destination address that is foreign to the particular subnetwork, the bridge transmits the packet to its attached router (e.g., r2). The packet is then transmitted via the backbone network to the router that connects to the subnetwork containing the destination host. For instance, the packet may be transmitted from the router r2 via the backbone network to the router r4. To that end, each router which receives a packet illustratively uses the destination address (or a portion thereof) to index a routing table stored at the router. The indexed router table entry indicates the next router to which the packet must be transmitted. When the packet reaches the router (e.g., router r4) that attaches the subnetwork (e.g., subnetwork C) containing the destination host (e.g., host hi 5), the router transfers the packet to the attached bridge (e.g., b4). The bridge then transmits the packet to the destination host.
The discussion above has been limited to unicast packet communication wherein a packet is transmitted from a single source host to a single destination host. The network 1 0 also supports multicast communication, wherein a packet is transmitted from a single source - host to multiple hosts. U.S. Patent No. 5,331 ,637 describes multicast routing and, in particular, how to implement multicast routing at the WAN level of the hierarchy. Illustratively, multicast communication of packets is supported in the communications network 1 0 at the network level of communications according to the Internet Group Management Protocol (IGMP), IETF RFC 112, Host Extensions for IP Multicasting. According to this protocol, multicast groups of hosts are identified, wherein each group is a collection of destination hosts for packets for a particular communication. Each multicast group is assigned a special multicast address which bears no relation to any single host of the multicast group.
Each router which connects a campus network 15 to the WAN (e.g., the router RI ) periodically transmits a "Host Membership Query" multicast control packet with a destination address that specifies all of the hosts of the campus network 1 5. In response, each host transmits back to the router (e.g., the router RI) a "Host Membership Report" multicast control packet that indicates all of the groups to which the host belongs. Furthermore, a host can transmit a "Join Host Group" or "Leave Host Group" multicast control packet to the router (e.g., the router RI) at any time to join or leave a multicast group. The router receives these messages and updates its routing tables accordingly. When a host, e.g., the host hi, desires to transmit a multicast packet, it writes a multicast address of an appropriate multicast group in the destination field. The host then transmits the packet to its attached bridge, e.g., the bridge bl (via the subnetwork LI). The bridge has no way of knowing the location of the destination host (because the multicast -destination address bears no relationship to the destination address of a single host). Thus, the bridge retransmits the multicast packet to each attached subnetwork and router, other than the subnetwork or router from which the packet originated, e.g., the subnetworks L2, L3 and the router r2. The attached router, e.g., the router r2, accesses its routing table using the multicast destination address. However, unlike before, the accessed routing table entry may indicate more than one next router to which the packet must be transmitted, e.g., the router RI and the router r3. The router transmits a copy of the packet to each indicated next router. Thus, the packet is selectively routed and replicated in route. Each router that receives a copy of the multicast packet performs the same table access procedure. Eventually, a router, e.g., the router r4, receives a packet that must be transmitted to an attached subnetwork, e.g., the subnetwork C. When a multicast packet is received at a bridge of the subnetwork, e.g., the bridge b4 of the subnetwork C, the bridge has no way of knowing to which attached network segment (or router) the packet is destined. This is because the packet has a multicast address which bears no relationship to any individual host. Furthermore, the multicast packet can be destined to more than one host in more than one attached network segment and or router. Thus, the bridge retransmits the multicast packet in each attached network segment and to each attached router. The packets transmitted in the network segments are received by each host. Each host then compares the multicast destination address to the multicast destination addresses of the groups of which it is a member. If the host is a member of the same group as indicated in the packet, the host receives the packet. Otherwise, the host discards the packet. The problem with the above-noted multicast communication scheme is that it wastes bandwidth in the subnetworks. In particular, a bridge retransmits a received multicast packet in each attached network segment even if one of the attached network segments is devoid of destination hosts of the multicast packet (i.e., even if the network segment does not have any hosts that are members of the multicast group of the multicast packet). This resulting in unnecessary bandwidth reduction in some attached network segments that are devoid of destination hosts. Considering that much multicast traffic in the future is intended to be bandwidth intensive multimedia traffic, i.e., video and/or audio, the wasted bandwidth can be - o - very high and can noticeably degrade performance on a network segment. In the past, the solution to improving network segment performance is to reconfigure the campus network by increasing the number of routers and redistributing (i.e., reconnecting) the network segments or hosts amongst the routers. However, this solution is disadvantageous because routers are relatively expensive and difficult to manage.
S. Deering, Multicast Routing in Internetworks and Extended LANS, ACM SYMPOSIUM ON COMMUNICATION ARCHITECTURES AND PROTOCOLS, ACM SIGCOMM pp.55-64, Aug. 1988 proposes an alternative solution. According to the Deering reference, bridges only retransmit multicast packets over "links" on routes to destination host of the multicast packets (wherein a "link" is a communication connection). To that end, each bridge constructs a multicast forwarding table which is maintained at the bridge. The bridge accesses the multicast forwarding table using the multicast group as an address to determine onto which links a received multicast packet must be retransmitted. The Deering reference teaches that the hosts transmit special control packets that are destined to all bridges of the campus network indicating to which multicast group the host belongs. The bridges compile such information, in order to construct the multicast forwarding, table and to determine when entries of the multicast forwarding table have become stale and therefore must be discarded.
There are two problems with the proposed Deering solution. First, extra control packets must be transmitted between the hosts and the bridges in order to construct the multicast forwarding tables. This increases traffic on the network segments. Second, and more importantly, all hosts are specially adapted in accordance with the Deering scheme so that they periodically transmit the special multicast control packets in order to maintain their memberships. The solution is therefore not entirely "plug-and-play" from the perspective of the hosts. It is therefore an object of the present invention to overcome the disadvantages of the prior art. It is a particular object of the present invention to prevent multicast communication traffic that originates from, or is destined to, outside of a subnetwork from degrading the communication performance within the subnetwork.
Summary of the Invention
These and other objects are achieved by the present, invention. The environment of the present invention is a hierarchically organized communications network. The illustrative communications network environment of the present invention is a subnetwork of a campus network which campus network provides for inter-subnetwork unicast and multicast packet communication. The subnetwork includes an internetworking device, such as a bridge, for connecting the subnetwork to the campus network. According to one embodiment, a bridge internetworking device constructs a multicast forwarding table (for retransmitting multicast packets) as follows. Selected hosts transmit, on a route to one or more routers, a host membership packet indicating at least one multicast group to which the hosts belong, (for instance, according to IGMP, the hosts may transmit Join Host Group, Leave Host Group or Host Membership Report packets.) A bridge on the route to a router receives each host membership packet. Using the host membership packet, the bridge updates multicast forwarding table entries corresponding to one or more multicast groups of the host which transmitted the packet. In this fashion, the bridge ensures that the multicast forwarding table entries corresponding to each multicast group only indicate those network segments on routes to hosts that are members of the corresponding multicast groups. The bridge then routes the host membership packet to the router in the normal fashion, i.e., retransmits the host membership packet on the route to the router. (The router in turn uses the membership packet to update routing tables thereat.) The bridge then retransmits multicast message packets received thereat, which are destined to the multicast groups joined by the hosts according to the multicast forwarding table maintained at the bridge. Thus, in accordance with the present invention, a bridge utilizes host membership packets normally destined to a router for purposes of maintaining a multicast table. This is a very efficient way to maintain a multicast routing table with a bridge.
This provides a robust solution for preventing multicast packets from flooding all attached network segments without requiring that the individual hosts be adapted in any special fashion.
Multicast message packets are received in a subnetwork at the internetworking device (bridge). The multicast message packet may have originated from outside the subnetwork or from a host within the subnetwork. In any event, the internetworking device retransmits the packet to only those network segments of the subnetwork on a route to a destination host for the received multicast message packets.
In the simplest case of a route, the destination host is contained in a network segment that is directly connected to the internetworking device. In such a case, the route to the destination host may include only the network segment containing the host. In a more complex case of a route, the destination host is contained in a network segment that is not directly connected to the internetworking device. Rather, the network segment containing the destination host is connected to a second internetworking device. The second, internetworking device, in turn, is connected via an intervening network segment to the internetworking device which received the multicast packet. In such a case, the route to the destination, host includes the intervening network segment, the second internetworking device and the network segment containing the destination host. In the former case, the internetworking device retransmits the packet in the directly connected network segment containing the destination host while in the latter case the internetworking device retransmits the packet in the intervening network segment. In short, an apparatus and method are provided for controlling the retransmission of multicast packets within a subnetwork to conserve bandwidth. Thus, multicast packets originating from, or destined to, outside the subnetwork do not interfere with the network segments that do not contain any hosts that belong to the multicast group of the multicast packets.
Brief Description of the Drawing
FIG 1 shows a conventional communications network. FIG 2 shows a conventional packet. FIG 3 shows a subnetwork including a bridge according to the present invention.
FIG 4 shows an illustrative forwarding table according to an embodiment of the present invention.
FIG 5 is a flowchart which schematically illustrates a multicast forwarding table maintenance process according to an embodiment of the present invention. FIG 6 is a flow chart which schematically illustrates a multi-cast message packet routing process according to an embodiment of the present invention.
Detailed Description of the Invention
FIG 3 shows a subnetwork 100 according to the present invention. As shown, the subnetwork 100 is connected to a router rlOO of a campus network or directly to a WAN. The subnetwork 100 includes a bridge b 100 connected to three network segments, namely, LI 00, L101 and L102. The network segment L100 includes a number of hosts WOO, hlOl, W02, W03, hl04, hl05, hl06, hl07 and hl08 interconnected to form a LAN such as an Ethernet LAN. Likewise, the network segment 102 includes a number of hosts hllO, hi 11, hi 12, hi 13, hi 14, hi 15, hi 16, hi 17, hi 18, hi 19 connected to form a LAN. The network segment L101 only includes the host 109 which is also connected to form a LAN. As shown, the bridge bl 00 includes a bus 110, a processor 120, a memory 130 and 4 I/O interfaces 141, 142, 143 and 144. However, this is illustrative. An arbitrary number of I/O interfaces may be provided to support each router and network segment attached to the bridge blOO. The I/O interface 141 is connected to the router rlOO. The I/O interface 142 is connected to the network segment L100. The I/O interface 143 is connected to the network segment L 101. The I/O interface 144 is connected to the network segment L 102. Each I/O interface 141-144 is capable of receiving packets and transmitting packets according to the protocol of the router or network segment to which the I/O interface is attached. For instance, the I/O interface 142 can transmit packets, receive all packets, detect a collision on the network segment LI 00 and transmit a jamming signal, if necessary, as per the Ethernet and CSMA/CD protocols. Thus, the I/O interfaces enable the bridge b 100 to receive packets from the router rlOO and network segments LI 00, LI 01 and LI 02 and to transmit packets thereto.
Packets which may be received via the I/O interfaces 141-144 may be transferred via the bus 110 to the processor 120 or memory 130. Illustratively, the memory 130 is for, amongst other things, temporarily buffering received packets. The processor 120 can access the packets in the memory 130, for example, to read or write data in the header portions of the packets for purposes of translating a packet from one protocol to another protocol. The processor 120 can also examine the address of the packet header to determine from which I/O interface 141-144 the packet should be retransmitted. By selectively retransmitting unicast packets from only the I/O interfaces 141-144 connected to network segment (or router) containing the destination host of the packet, the bridge bl 00 conserves the bandwidth of the other network segments (or routers) which do not contain the destination host of the packet.
According to an embodiment of the present invention, multicast packets received at the bridge blOO (from the router r 100 or from a host hlOO-hl 19 in an attached network segment LI 00, LI 01 or LI 02) are only retransmitted onto the network segments L100, L101 or L102 that contain destination hosts of the multicast packets. Stated another way, the bridge bl 00 refrains from retransmitting multicast packets onto those attached network segments L100, L101 or L102 that are devoid of destination hosts of the multicast packets. To that end, the processor 120 maintains a forwarding table with entries corresponding to multicast addresses. Alternatively, additional forwarding table entries as described below may be added to a forwarding table already maintained by the bridge blOO.
An illustrative forwarding table 200 is shown in FIG 4. As shown, each table entry 210, 220, 230, 240, 250, 260, 270, and 280 includes a multicast destination address index field 212, 222, 232, 242, 252, 262, 272, or 282. The multicast destination address index field contains a multicast destination address of a particular multicast group. This field is used by the processor 120 for retrieving a multicast forwarding table entry 210-280 that corresponds to a particular multicast group. The table entry also includes an I/O interface field 214, 224, 234, 244, 254, 264, 274 and 284. This field is for storing indications of only those I/O interfaces 142- 144 that connect the bridge blOO to a network segment that contains a destination host of the multicast address. This field 214-284 also stores indications of I/O interfaces 141 that connect the bridge blOO to a router rlOO that provides communication access external to the network segment 100. Furthermore, each table entry 210-280 includes a list field 216, 226, 236, 246, 256, 266, 276 or. 286 for storing a list of the hosts which are members of the multicast group corresponding to the table entry. For example, the multicast forwarding table entry 230 corresponds to the multicast group for an audio-video teleconference which has the address AV 1 stored in the multicast destination address index field 232. The multicast forwarding table entry 230 also includes the indications of the I/O interfaces 143, 144 and 141 (from which the packets must be retransmitted) stored in the I/O interface field 234. Furthermore, the multicast forwarding table entry 230 includes a list of the hosts hl09, hll4, hi 17 and hi 19 which are members of the multicast group AVI stored in the host list field 236.
FIG 5 is a flowchart that illustrates a process executed by the bridge blOO in constructing and modifying the multicast forwarding table entries 210-280 of FIG 4. In a first step si , the processor 120 determines if a received packet is a multicast control packet.
Examples of such packets according to the IGMP protocol are Host Membership Query packets, Host Membership Report packets, Join Host Group packets and Leave Host Group packets. Such packets have a well defined and easily identifiable form. If the received packet is not a multicast control packet, the processor executes a routing process (step S2) described below. If the received packet is a multicast control packet, the processor 120 executes step S3. In step S3, the processor 120 determines if the packet contains an instruction from the attached router to each host hlOl-hl 19 to report all of its current multicast group memberships (e.g., a Host Membership Query packet). If so, then the processor 120 keeps track of from which router and via which I/O interface 141-144 the packet was received, e.g., by temporarily storing this information in the memory 130. As discussed in greater detail below, the processor 120 uses such information in the construction of forwarding table entries corresponding to multicast groups. In particular, such information is used to update the forwarding tables to ensure that multicast packets originating in the subnetwork 100, and destined outside the subnetwork 100, are transmitted from the bridge bl 00 to the routers rlOO that can deliver multicast packets to such destinations external to the subnetwork 100. If the packet is not a Host Membership Quay packet, the processor 120 proceeds to step S5. In step S5, the processor determines if the packet contains a report from a host of all of its current multicast group memberships (e.g., a Host Membership Report packet). Such a packet contains the multicast destination address of each multicast group of which the host wishes to be a member. If a Host Membership Report packet is received, then, in accordance with step S6, the processor 120 executes steps S13-S15 for each multicast destination address (of each multicast group) specified in the packet. If the packet is not a Host Membership Report packet then the processor 120 proceeds to step S7.
In step S7, the processor 120 determines if the packet contains an indication that a host is leaving a multicast group (e.g., is a Leave Host Group packet). If not, the processor 120 executes step SI 1. If the packet does contain an indication that the host is leaving a multicast group, the processor 120 executes steps S8-S10. In step S8, the processor 120 retrieves the multicast forwarding table entry corresponding to the destination address of the multicast group designated in the received packet. For example, suppose the packet contained an indication that host hl09 desired to leave the multicast group AVI. The processor 120 would thus retrieve from the memory 130 the forwarding table entry 230 that has the multicast destination address AVI stored in the multicast destination address index field 232. Next, in step S9, the processor 120 deletes the indication of the host which transmitted the packet from the list of hosts contained in the entry. For instance, the processor 120 would delete the indication for hl09 from the host list field 236 of the multicast forwarding table entry 230. Thereafter, the processor 120 executes step S10, wherein the processor 120 updates the indicators stored in the I/O interface field 234 of the I/O interfaces from which the packet must be transmitted. In particular, the processor 120 examines each remaining host indication contained in the host list field 236. If necessary, the processor 120 deletes an indicator for an I/O interface from the I/O interface field 234 if none of the remaining hosts in the host list are connected via that I/O interface. Such would be the case if the host which transmitted the multicast control packet was formerly the only host on a particular network segment that belonged to that multicast group. Continuing with the above example, the host hl09 was formerly the only host of the list 236 connected to the bridge blOO by the I/O interface 143. Thus, the indication for the I/O interface 143 is deleted from the I/O interface field 234.
In step SI 1., the processor 120 determines if the received packet contains an indication that a host wishes to join a particular multicast group (e.g., a Join Host Group packet). If not, then the packet must be some unidentifiable multicast control packet. In such a case, in step SI 2, the processor executes the routing process described below. If a multicast control packet for joining a multicast group was received, the processor 120 executes steps S13-S15. In step SI 3, the processor 120 first attempts to retrieve a multicast forwarding table entry using, as an index, the multicast forwarding address of the group that the host wishes to join. If the processor 120 is able to retrieve a corresponding multicast forwarding table entry from the memory 130, the processor 120 then executes step S14. However, it is possible that the host which transmitted the packet wishes to join a multicast group for which no multicast forwarding table entry exists at the bridge blOO. Such is the case if the multicast forwarding table was recently flushed or if this host is the first host in the subnetwork 100 (FIG 3) to join this particular multicast group. If no multicast forwarding table entry exists for the multicast group, then the processor 120 generates one in the memory 130. In so doing, the processor 120 writes the multicast destination address for the group in the multicast destination address index field. The processor 120 also writes the indication of the I/O interfaces 141-144 connected to one or more routers, i.e., the interface 141, that can deliver multicast traffic to destinations external to the subnetwork 100, in the I/O interface field. This is so the bridge blOO will retransmit multicast packets that are locally generated in the subnetwork 100 to other subnetworks via the router rlOO. As noted above, the processor 120 can determine which I/O interfaces 141 are connected to such routers rlOO in response to receiving Host Membership Query Packets (steps S3-S4). The processor 120 can thus use the previously stored indication of the host interface 141 of the router rlOO which issues such multicast query packets to construct the table entry. The processor 120 then executes step SI 4. In step SI 4, the processor 120 adds the destination address of the host which transmitted the control packet to the host list field of the multicast forwarding table entry. Next, in step SI 5, the processor 120 updates the I/O interface indications in the I/O interface field of the multicast forwarding table entry in accordance with the revised host list. That is, suppose the newly added host is connected to the bridge blOO via an I/O interface not already indicated in the I O interface field. Such- ould be the case if the newly added host is the only multicast group member on a particular network segment. If such is the case, then an indicator for the I/O interface which connects the network segment of the newly added host must be added to the I/O interface field of the table entry.
After each of the steps S4, S6, S10 and SI 5, the bridge also routes the received packet towards its intended destination. In the case of step S4, the multicast packet contains an "all hosts" address. This packet is thus retransmitted on every network segment on a route to a host of the subnetwork 100. In the cases of steps S6, S 10 and S 15, such multicast control packets are destined to an attached router, such as the router rlOO. The bridge blOO retransmits such packets on a route to that router. The router in turn updates its internal routing tables in response to receiving such packets in a well known manner.
In any event, it should be noted that the hosts need not transmit special packets to the bridges. Rather, the bridges blOO according to the present invention "eavesdrop" on the very same packets used to change host membership on the WAN or campus network level according to, for instance, IGMP protocol. Thus, network segment bandwidth is conserved since a single multicast control packet serves two purposes. Moreover, neither the hosts nor routers need be specially adapted to implement the invention. Rather, only the bridges need be adapted. While not shown in FIGS, the processor 120 also performs an "aging-out" process. Generally speaking, the forwarding table 200 is only accurate for a limited period of time. This is because of various reasons such as the turning on and off of hosts, the reconfiguration (the changing of the interconnection of routers, bridges and hosts) of the network 100, the failing of a router, bridge, etc. Thus, the forwarding table 100 is presumed to be stale or inaccurate after a fixed period of time, e.g., every five minutes. At each such regular interval, the processor 120 flushes or discards the forward table 200 in the memory 130 and begins constructing a new forwarding table 200 as per the above-described -process. See S. Deering, Multicast Routing in Internetworks and Extended LANs, ACM Symposium On Communication- Architectures and Protocols, ACM SIGCOMM pp. 55-64, Aug., 1988 for an exemplary "aging- out" process.
FIG 6 shows a process executed by the bridge blOO in routing, i.e., retransmitting received packets. In step SI 6, the processor 120 examines the received packet in the memory to determine if it is a multicast message packet (i.e., a packet for delivering data to multiple destinations). If not, the processor 120 executes step SI 7 wherein the processor routes the packet using conventional unicast routing (described above). If the packet is a multicast message packet, the processor 120 executes step SI 8. In step SI 8, the processor 120 uses the multicast destination address as an index to retrieve a corresponding entry from the multicast forwarding table 200 (FIG 4). If the table does not have an entry corresponding to the multicast destination address of the received packet then the processor 120 executes step SI 9. This may occur for various reasons including:
(a) a multicast message packet was received destined to a multicast group not known by the bridge b 100,
(b) the processor 120 aged out the forwarding table 200,
(c) the bridge blOO was recently installed and has not yet determined all of the multicast groups,
(d) the bridge bl 00 did not receive all of the multicast control packets, and (e) the memory 130 ran out of storage locations and therefore could not complete the forwarding table 200.
In step 19, the processor 120 discards or retransmits the received packets depending on why the multicast destinating group is not contained in the forwarding table 200. For example, in the event of conditions (a)-(b), the received packet is discarded. On the other hand, in the event of conditions (c)-(e) the processor 120 retransmits the received packet in a conventional fashion, namely, the processor 120 retransmits the received packet from each I/O interface 142-144 other than the I/O interface 141 from which the packet was received.
If, on the other hand, the multicast forwarding table has an entry corresponding to the multicast address of the packet, the processor 120 executes step S20. In step S20, the processor 120 retrieves the indications of the I/O interfaces stored in the I/O interface field of the retrieved multicast forwarding table entry. The processor 120 then retransmits the received multicast packet only from the I/O interfaces 141-144 indicated in the I/O interface field except for the I/O interface from which the packet was received. For example, suppose the bridge blOO receives a multicast packet from the router rlOO destined to the multicast group VI . This packet is received via I/O interface 141 and temporarily stored in the memory 130. Using VI as an index, the processor 120 retrieves the table entry 250 corresponding to the multicast group of the address VI. The processor then retrieves all of the I/O interface indications from the I/O interface field 254. The only indicated I/O interfaces are 141 and 142. However, the packet was received from I/O interface 141. Thus, the received multicast packet is only retransmitted from the I/O interface 142. As such, the received multicast packet is retransmitted on the attached segment L100 but not on the attached network segments LI 01 or LI 02.
Consider now a second example, where the host hi 01 wishes to transmit a multicast message packet to the multicast group AV2. The host 101 writes the multicast destination address AV2 into the packet header and transmits the multicast message packet in the network segment L100. This packet is received at hosts hl02-hl03 which accept the packet. The packet is also received at the I/O interface 142 of the bridge blOO. The received packet is temporarily stored in the memory 1 30. The processor 120 retrieves the multicast forwarding table entry 240. The indicated I/O interfaces are 142, 144, and 141. However, because the packet was received from I/O interface 142, the processor 130 only retransmits the packet from I/O interfaces 144 and 141. Thus, the packet is transmitted to the router rlOO (from which the packet may be transmitted to host external to the subnetwork 100) and to the hosts hi 13, hll4 via the network segment LI 02. However, the packet is not retransmitted on the network segment L101.
Note the improvement over the conventional multicast routing system wherein a conventional bridge simply retransmits all received multicast packets over each network segment (other than the network segment from which the packet was received). In contrast, according to the present invention, the received multicast packets are retransmitted from the bridge onto only those network segments containing hosts that are members of the pertinent multicast group. This is especially important in the context of multimedia, i.e., audio-video multicast packet communication traffic. Such traffic tends to be continuous rather than bursty and tends to require a high bandwidth. The invention has been described so far with reference to only a single internetworking device (e.g., bridge) subnetwork. However, the invention is also equally applicable to a multiple internetworking device (e.g., multi-bridge) subnetwork.
In such a case, it is possible that some network segments are not directly connected to all of the bridges. For instance, consider the topology of the subnetwork A of FIG 1. As shown, the network segment LI is directly connected to bridge bl but not to bridge b2. Likewise, the network segments L3 and L4 are directly connected to the bridge b2 but not the bridge bl. As noted above, the bridges bl and b2 self-configure routes to the hosts of subnetworks to which they are not directly attached by passing control packets back and forth to each other. For instance, the bridge bl may determine that packets destined to hosts in the subnetworks L3 and L4 may be transmitted thereto via the intervening network segment L2 and the bridge b2. Thus, in the multiple internetworking device topology, consideration must be made for routing to multicast destination hosts via intervening subnetworks. This can be achieved by modifying steps S10. and SI 5. In particular, when the processor 120 updates the I/O interface field, the processor 120 ensures that only I/O interfaces that attach network segments on a route to a host of the host list are included therein. Such I/O interfaces include those that attach network segments which contain multicast destination hosts and those which attach intervening network segments on a route to multicast destination hosts.
In short, a system and method are disclosed for routing multicast packets in a subnetwork so as to conserve bandwidth in at least some of the network segments or collision domains of the subnetwork. In particular, multicast packets are only retransmitted in the network segments that are on a path to a host that is a member of the multicast group of hosts to which the multicast packet is destined.
Finally, the invention has been described above with reference to illustrative embodiments. Numerous alternative embodiments may be devised by those having ordinary skill in the art without departing from the spirit and scope of the following claims.

Claims

1. In a hierarchical communications network comprising: plurality of interconnected routers and a plurality of subnetworks connected to said routers, wherein each of said subnetworks comprises: one or more network segments, and one or more bridges interconnecting said network segments and connecting said subnetwork to one or more of said routers, and each network segment comprises one or more hosts a process for providing multicast communication comprising the steps of: transmitting from a selected one of said hosts on a route to one of said routers a host membership packet indicating a multicast group to which said host belongs, receiving said host membership packet at a bridge on a route to said one router, using said host membership packet, updating a multicast forwarding table entry corresponding to said multicast group at said bridge, retransmitting said host membership packet from said bridge on said route to said one router, using said membership packet, updating a routing table at said one router, and at said bridge, retransmitting multicast message packets destined to said at least one multicast group according to said multicast forwarding table maintained at said bridge.
2. The process of claim 1 further comprising the step of: in response to receiving a multicast control packet from a host of said subnetwork reporting each multicast group of which said host is a member, updating said multicast forwarding table entries corresponding to each of said multicast groups to indicate said network segment of said host from which said multicast control packet was received.
3. The process of claim 1 further comprising the step of: in response to receiving a multicast control packet from a host of said subnetwork indicating that said host wishes to join a particular multicast group, updating said multicast forwarding table entry corresponding to said particular multicast group to indicate said network segment of said host from which said multicast control packet was received.
4. The process of claim 1 further comprising the step of in response to receiving a multicast control packet from a host of said subnetwork indicating that said host wishes to leave a particular multicast group, updating said multicast forwarding table entry corresponding to said particular multicast group to remove an indication for said network segment of said host from which said multicast control packet was received, if said host was formerly the only host contained in said network segment that was also a member of said particular multicast group.
5. The process of claim 1 further comprising the steps of: receiving a message packet at said bridge via one of a plurality of I/O interfaces of said bridge, using a destination address of a received multicast message packet as an index, retrieving a corresponding entry from said multicast forwarding table maintained at said bridge, and if no entry exists for said destination address, retransmitting said received multicast message packet from each of said I/O interfaces except for said one I/O interface via which said multicast message packet was received.
6. The process of claim 1 wherein the route from a particular bridge of a subnetwork to a particular host that is a member of a particular multicast group includes at least one intervening network segment connected directly to said particular bridge, said process comprising the steps of: receiving at said particular bridge a multicast message packet destined to said particular multicast group, and - 19 - retransmitting said multicast message packet in said at least one intervening network segment.
7. The process of claim 1 wherein each entry of said multicast forwarding table corresponds to a different multicast group and wherein each table entry indicates only those I/O interfaces connected to network segments on a route to a host that is a member of said corresponding multicast group.
8. A bridge in a hierarchical communications network comprising: a plurality of I/O interfaces for transmitting packets to, and for receiving packets from, routers and network segments attached to said bridge, said plurality of I/O interfaces including one I/O interface connected to each of said routers and one I/O interface connected to each of said network segments, and a processor connected to said I/O interfaces, for receiving a host membership packet transmitted from a host of one of said network segments to one of said routers via a route including said bridge, for updating multicast forwarding table entry corresponding to a multicast group of said host membership packet, for causing said I/O interface connected to said destination router of said host membership packet to retransmit said host membership packet, and for causing said I/O interfaces to retransmit multicast message packets destined to said multicast group according to said multicast forwarding table.
9.The communications network of claim 8 wherein said bridge further comprises: bus interconnecting said I/O interfaces and said processor, and memory connected to said bus for storing said multicast forwarding table.
PCT/US1996/005853 1995-04-25 1996-04-25 Broadcast transmission in a data network WO1996034474A1 (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
AU55792/96A AU5579296A (en) 1995-04-25 1996-04-25 Broadcast transmission in a data network

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US08/428,403 US5608726A (en) 1995-04-25 1995-04-25 Network bridge with multicast forwarding table
US08/428,403 1995-04-25

Publications (1)

Publication Number Publication Date
WO1996034474A1 true WO1996034474A1 (en) 1996-10-31

Family

ID=23698750

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/US1996/005853 WO1996034474A1 (en) 1995-04-25 1996-04-25 Broadcast transmission in a data network

Country Status (3)

Country Link
US (3) US5608726A (en)
AU (1) AU5579296A (en)
WO (1) WO1996034474A1 (en)

Cited By (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP0841782A1 (en) * 1996-11-07 1998-05-13 Hewlett-Packard Company Broadcast isolation and level 3 network switch
GB2337674A (en) * 1998-05-21 1999-11-24 3Com Technologies Ltd Network device which functions as a bridge and a router
EP1029263A1 (en) * 1997-04-23 2000-08-23 Motorola, Inc. System, device, and method for managing multicast group memberships in a multicast network
US6442162B1 (en) 1998-11-17 2002-08-27 3Com Technologies Credit-based scheme for high performance communication between devices in a packet-based communication system
KR100437860B1 (en) * 2001-03-30 2004-06-26 주식회사 이지씨앤씨 Method of intermediating multicasting signal for multicasting embodiment
US6807175B1 (en) 2000-05-10 2004-10-19 3Com Corporation Distributed multicast routing in packet-based communication network devices
US6975627B1 (en) 1998-11-11 2005-12-13 3Com Technologies Modification of tag fields in Ethernet data packets
US7411916B2 (en) * 1998-02-26 2008-08-12 Nortel Networks Limited Data forwarding method and apparatus
US7877508B1 (en) 2001-10-19 2011-01-25 Foundry Networks, Llc Method and system for intelligently forwarding multicast packets

Families Citing this family (229)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5608726A (en) 1995-04-25 1997-03-04 Cabletron Systems, Inc. Network bridge with multicast forwarding table
US6370142B1 (en) 1995-07-12 2002-04-09 Nortel Networks Limited Method and apparatus for performing per-port IP multicast pruning
US6097718A (en) 1996-01-02 2000-08-01 Cisco Technology, Inc. Snapshot routing with route aging
US6147996A (en) 1995-08-04 2000-11-14 Cisco Technology, Inc. Pipelined multiple issue packet switch
US5924112A (en) * 1995-09-11 1999-07-13 Madge Networks Limited Bridge device
US6182224B1 (en) 1995-09-29 2001-01-30 Cisco Systems, Inc. Enhanced network services using a subnetwork of communicating processors
US5818838A (en) * 1995-10-12 1998-10-06 3Com Corporation Method and apparatus for transparent intermediate system based filtering on a LAN of multicast packets
DE69532448T2 (en) * 1995-10-20 2004-10-21 Ibm Bridge device for filtering traffic in communication networks
US5923853A (en) * 1995-10-24 1999-07-13 Intel Corporation Using different network addresses for different components of a network-based presentation
JP3097525B2 (en) * 1995-11-10 2000-10-10 株式会社日立製作所 Data transmission method for performing information filtering
US6091725A (en) 1995-12-29 2000-07-18 Cisco Systems, Inc. Method for traffic management, traffic prioritization, access control, and packet forwarding in a datagram computer network
US6035105A (en) 1996-01-02 2000-03-07 Cisco Technology, Inc. Multiple VLAN architecture system
JP2838998B2 (en) * 1996-02-07 1998-12-16 日本電気株式会社 Mobile terminal and mobile network
US5740375A (en) * 1996-02-15 1998-04-14 Bay Networks, Inc. Forwarding internetwork packets by replacing the destination address
US5937163A (en) * 1996-03-26 1999-08-10 Industrial Technology Research Institute Method and system at a host node for hierarchically organizing the links visited by a world wide web browser executing at the host node
US7266686B1 (en) * 1996-05-09 2007-09-04 Two-Way Media Llc Multicasting method and apparatus
US6308148B1 (en) * 1996-05-28 2001-10-23 Cisco Technology, Inc. Network flow data export
US6243667B1 (en) 1996-05-28 2001-06-05 Cisco Systems, Inc. Network flow switching and flow data export
JP2842524B2 (en) * 1996-06-06 1999-01-06 日本電気株式会社 Multicast group configuration method and multicast communication network
US6212182B1 (en) 1996-06-27 2001-04-03 Cisco Technology, Inc. Combined unicast and multicast scheduling
US6434120B1 (en) 1998-08-25 2002-08-13 Cisco Technology, Inc. Autosensing LMI protocols in frame relay networks
JP3150624B2 (en) * 1996-09-13 2001-03-26 株式会社ディジタル・ビジョン・ラボラトリーズ Communication system and communication path control method
US6564262B1 (en) * 1996-09-16 2003-05-13 Microsoft Corporation Multiple multicasting of multimedia streams
US5963547A (en) 1996-09-18 1999-10-05 Videoserver, Inc. Method and apparatus for centralized multipoint conferencing in a packet network
US6304546B1 (en) 1996-12-19 2001-10-16 Cisco Technology, Inc. End-to-end bidirectional keep-alive using virtual circuits
KR100467708B1 (en) * 1996-12-21 2005-05-11 삼성전자주식회사 Cell processing apparatus and method of asynchronous transfer mode switching system
EP0854604A1 (en) * 1997-01-21 1998-07-22 International Business Machines Corporation Multicast group addressing
JP3090194B2 (en) * 1997-02-24 2000-09-18 日本電気株式会社 Mobile Host Multicast Communication Method
US6728775B1 (en) 1997-03-17 2004-04-27 Microsoft Corporation Multiple multicasting of multimedia streams
US6189039B1 (en) 1997-04-10 2001-02-13 International Business Machines Corporation Selective tunneling of streaming data
US6122272A (en) 1997-05-23 2000-09-19 Cisco Technology, Inc. Call size feedback on PNNI operation
US6356530B1 (en) 1997-05-23 2002-03-12 Cisco Technology, Inc. Next hop selection in ATM networks
US6862284B1 (en) 1997-06-17 2005-03-01 Cisco Technology, Inc. Format for automatic generation of unique ATM addresses used for PNNI
US5920566A (en) * 1997-06-30 1999-07-06 Sun Microsystems, Inc. Routing in a multi-layer distributed network element
US6119196A (en) * 1997-06-30 2000-09-12 Sun Microsystems, Inc. System having multiple arbitrating levels for arbitrating access to a shared memory by network ports operating at different data rates
US6081512A (en) * 1997-06-30 2000-06-27 Sun Microsystems, Inc. Spanning tree support in a high performance network device
US6128666A (en) * 1997-06-30 2000-10-03 Sun Microsystems, Inc. Distributed VLAN mechanism for packet field replacement in a multi-layered switched network element using a control field/signal for indicating modification of a packet with a database search engine
US6081522A (en) * 1997-06-30 2000-06-27 Sun Microsystems, Inc. System and method for a multi-layer network element
US6088356A (en) * 1997-06-30 2000-07-11 Sun Microsystems, Inc. System and method for a multi-layer network element
US6052738A (en) * 1997-06-30 2000-04-18 Sun Microsystems, Inc. Method and apparatus in a packet routing switch for controlling access at different data rates to a shared memory
US6049528A (en) * 1997-06-30 2000-04-11 Sun Microsystems, Inc. Trunking ethernet-compatible networks
US6246680B1 (en) 1997-06-30 2001-06-12 Sun Microsystems, Inc. Highly integrated multi-layer switch element architecture
US6094435A (en) * 1997-06-30 2000-07-25 Sun Microsystems, Inc. System and method for a quality of service in a multi-layer network element
US6044418A (en) * 1997-06-30 2000-03-28 Sun Microsystems, Inc. Method and apparatus for dynamically resizing queues utilizing programmable partition pointers
US6044087A (en) * 1997-06-30 2000-03-28 Sun Microsystems, Inc. Interface for a highly integrated ethernet network element
US6016310A (en) * 1997-06-30 2000-01-18 Sun Microsystems, Inc. Trunking support in a high performance network device
US6021132A (en) * 1997-06-30 2000-02-01 Sun Microsystems, Inc. Shared memory management in a switched network element
US6078590A (en) 1997-07-14 2000-06-20 Cisco Technology, Inc. Hierarchical routing knowledge for multicast packet routing
US6055364A (en) * 1997-07-31 2000-04-25 Cisco Technology, Inc. Content-based filtering of multicast information
US6330599B1 (en) 1997-08-05 2001-12-11 Cisco Technology, Inc. Virtual interfaces with dynamic binding
US5982775A (en) * 1997-08-14 1999-11-09 Tektronix, Inc. Forwarding multicast frames on an ethernet bridge
US6212183B1 (en) 1997-08-22 2001-04-03 Cisco Technology, Inc. Multiple parallel packet routing lookup
US6512766B2 (en) 1997-08-22 2003-01-28 Cisco Systems, Inc. Enhanced internet packet routing lookup
US6157641A (en) 1997-08-22 2000-12-05 Cisco Technology, Inc. Multiprotocol packet recognition and switching
US6259701B1 (en) * 1997-09-11 2001-07-10 At&T Corp. Method and system for a unicast endpoint client to access a multicast internet protocol (IP) session
US6058113A (en) * 1997-09-30 2000-05-02 Lucent Technologies, Inc. Method for enhancing resource reservation communication
US6343072B1 (en) 1997-10-01 2002-01-29 Cisco Technology, Inc. Single-chip architecture for shared-memory router
US6147993A (en) 1997-10-14 2000-11-14 Cisco Technology, Inc. Method and apparatus for implementing forwarding decision shortcuts at a network switch
US6216167B1 (en) * 1997-10-31 2001-04-10 Nortel Networks Limited Efficient path based forwarding and multicast forwarding
JP3493309B2 (en) * 1997-10-31 2004-02-03 富士通株式会社 Multicast transmission method
EP0935368A1 (en) 1997-11-03 1999-08-11 Canon Kabushiki Kaisha Path detection in a distributed network
EP0913965A1 (en) * 1997-11-03 1999-05-06 Canon Kabushiki Kaisha Reduction of the message traffic in a distributed network
US6185623B1 (en) 1997-11-07 2001-02-06 International Business Machines Corporation Method and system for trivial file transfer protocol (TFTP) subnet broadcast
US6671276B1 (en) * 1997-11-18 2003-12-30 Nec Corporation Switch based network architecture for IP multicast and integrated services
US6272134B1 (en) * 1997-11-20 2001-08-07 International Business Machines Corporation Multicast frame support in hardware routing assist
US7570583B2 (en) * 1997-12-05 2009-08-04 Cisco Technology, Inc. Extending SONET/SDH automatic protection switching
US6424649B1 (en) 1997-12-31 2002-07-23 Cisco Technology, Inc. Synchronous pipelined switch using serial transmission
US6111877A (en) 1997-12-31 2000-08-29 Cisco Technology, Inc. Load sharing across flows
US6549519B1 (en) 1998-01-23 2003-04-15 Alcatel Internetworking (Pe), Inc. Network switching device with pipelined search engines
US6161144A (en) 1998-01-23 2000-12-12 Alcatel Internetworking (Pe), Inc. Network switching device with concurrent key lookups
US6216173B1 (en) * 1998-02-03 2001-04-10 Redbox Technologies Limited Method and apparatus for content processing and routing
CA2323772A1 (en) * 1998-03-16 1999-09-23 British Telecommunications Public Limited Company Data transport system
US6853638B2 (en) * 1998-04-01 2005-02-08 Cisco Technology, Inc. Route/service processor scalability via flow-based distribution of traffic
US6320861B1 (en) * 1998-05-15 2001-11-20 Marconi Communications, Inc. Hybrid scheme for queuing in a shared memory ATM switch buffer
JP4080599B2 (en) * 1998-06-17 2008-04-23 富士通株式会社 Communication control apparatus and communication control method applied to multicast-compatible LAN
US6356548B1 (en) 1998-06-29 2002-03-12 Cisco Technology, Inc. Pooled receive and transmit queues to access a shared bus in a multi-port switch asic
US6370121B1 (en) 1998-06-29 2002-04-09 Cisco Technology, Inc. Method and system for shortcut trunking of LAN bridges
US6377577B1 (en) 1998-06-30 2002-04-23 Cisco Technology, Inc. Access control list processing in hardware
US6434144B1 (en) * 1998-07-06 2002-08-13 Aleksey Romanov Multi-level table lookup
US6144651A (en) * 1998-07-17 2000-11-07 Motorola, Inc. Data transmission within a wireless communication system
JP2000041176A (en) * 1998-07-24 2000-02-08 Canon Inc Controller, control system, control method and storage medium
US6182147B1 (en) 1998-07-31 2001-01-30 Cisco Technology, Inc. Multicast group routing using unidirectional links
US6308219B1 (en) 1998-07-31 2001-10-23 Cisco Technology, Inc. Routing table lookup implemented using M-trie having nodes duplicated in multiple memory banks
US6639917B1 (en) * 1998-08-04 2003-10-28 International Business Machines Corporation Converged service for interconnected local area networks
US6389506B1 (en) 1998-08-07 2002-05-14 Cisco Technology, Inc. Block mask ternary cam
US6101115A (en) 1998-08-07 2000-08-08 Cisco Technology, Inc. CAM match line precharge
US6600743B1 (en) * 1998-08-25 2003-07-29 International Business Machines Corporation IP multicast interface
US6445715B1 (en) 1998-08-27 2002-09-03 Cisco Technology, Inc. Dynamic trunk protocol
US6295296B1 (en) 1998-09-08 2001-09-25 Cisco Technology, Inc. Use of a single data structure for label forwarding and imposition
ATE300821T1 (en) * 1998-09-18 2005-08-15 British Telecomm HIERARCHICAL MULTIPLE SHIPMENT
US6304914B1 (en) 1998-09-22 2001-10-16 Microsoft Corporation Method and apparatus for pre-compression packaging
US6266705B1 (en) 1998-09-29 2001-07-24 Cisco Systems, Inc. Look up mechanism and associated hash table for a network switch
US6920146B1 (en) 1998-10-05 2005-07-19 Packet Engines Incorporated Switching device with multistage queuing scheme
US6678269B1 (en) 1998-10-05 2004-01-13 Alcatel Network switching device with disparate database formats
JP3266188B2 (en) 1998-10-19 2002-03-18 日本電気株式会社 Multicast communication device and multicast communication method
KR20000027471A (en) * 1998-10-28 2000-05-15 구자홍 Method for transmitting session data of a multicast router
US7246168B1 (en) 1998-11-19 2007-07-17 Cisco Technology, Inc. Technique for improving the interaction between data link switch backup peer devices and ethernet switches
US6563832B1 (en) 1998-11-30 2003-05-13 Cisco Technology, Inc. Token ring bridge distributed in a switched fabric
US6704318B1 (en) 1998-11-30 2004-03-09 Cisco Technology, Inc. Switched token ring over ISL (TR-ISL) network
US6587943B1 (en) 1998-12-03 2003-07-01 Nortel Networks Ltd. Apparatus and method for limiting unauthorized access to a network multicast
KR100310843B1 (en) * 1998-12-28 2001-11-15 윤종용 Method and aparatus for controlling flow in ethernet
US6771642B1 (en) 1999-01-08 2004-08-03 Cisco Technology, Inc. Method and apparatus for scheduling packets in a packet switch
JP2000242574A (en) * 1999-02-22 2000-09-08 Mitsubishi Electric Corp Data transfer method and scheduled transfer destination database generating method
US6711163B1 (en) 1999-03-05 2004-03-23 Alcatel Data communication system with distributed multicasting
US6542503B1 (en) 1999-03-16 2003-04-01 Cisco Technologies, Inc. Multicast echo removal
US7643481B2 (en) * 1999-03-17 2010-01-05 Broadcom Corporation Network switch having a programmable counter
WO2000056024A2 (en) * 1999-03-17 2000-09-21 Broadcom Corporation Network switch
US6757791B1 (en) 1999-03-30 2004-06-29 Cisco Technology, Inc. Method and apparatus for reordering packet data units in storage queues for reading and writing memory
US6760331B1 (en) 1999-03-31 2004-07-06 Cisco Technology, Inc. Multicast routing with nearest queue first allocation and dynamic and static vector quantization
US7474660B1 (en) 1999-03-31 2009-01-06 Cisco Technology, Inc. MAC address extension to maintain router information in source routed computer networks
US6603772B1 (en) 1999-03-31 2003-08-05 Cisco Technology, Inc. Multicast routing with multicast virtual output queues and shortest queue first allocation
US6317434B1 (en) * 1999-04-14 2001-11-13 Verizon Laboratories Inc. Data link layer switch with multicast capability
US6654371B1 (en) 1999-04-15 2003-11-25 Nortel Networks Limited Method and apparatus for forwarding multicast data by relaying IGMP group membership
US6721275B1 (en) * 1999-05-03 2004-04-13 Hewlett-Packard Development Company, L.P. Bridged network stations location revision
US6401127B1 (en) 1999-05-04 2002-06-04 Cisco Technology, Inc. Adaptive timer for LLC type 2 reliable transport in a computer network
US6850987B1 (en) * 1999-06-01 2005-02-01 Fastforward Networks, Inc. System for multipoint infrastructure transport in a computer network
US6657969B1 (en) 1999-06-29 2003-12-02 Cisco Technology, Inc. Generation of synchronous transport signal data used for network protection operation
US6577599B1 (en) * 1999-06-30 2003-06-10 Sun Microsystems, Inc. Small-scale reliable multicasting
US6714541B1 (en) 1999-08-10 2004-03-30 Cisco Technology, Inc. Method and apparatus for encoding bridging/switching information within a routing information filed in a token ring environment
US6983350B1 (en) * 1999-08-31 2006-01-03 Intel Corporation SDRAM controller for parallel processor architecture
US6529983B1 (en) 1999-11-03 2003-03-04 Cisco Technology, Inc. Group and virtual locking mechanism for inter processor synchronization
US6594272B1 (en) * 1999-11-23 2003-07-15 3Com Corporation Simple wireless network with store and forward methods incorporating anti-looping codes
US6532509B1 (en) 1999-12-22 2003-03-11 Intel Corporation Arbitrating command requests in a parallel multi-threaded processing system
US6785738B1 (en) 1999-12-23 2004-08-31 Cisco Technology, Inc. ARP packet to preserve canonical form of addresses
US6694380B1 (en) 1999-12-27 2004-02-17 Intel Corporation Mapping requests from a processing unit that uses memory-mapped input-output space
US6661794B1 (en) * 1999-12-29 2003-12-09 Intel Corporation Method and apparatus for gigabit packet assignment for multithreaded packet processing
US6614785B1 (en) * 2000-01-05 2003-09-02 Cisco Technology, Inc. Automatic propagation of circuit information in a communications network
WO2001052482A1 (en) * 2000-01-10 2001-07-19 British Telecommunications Public Limited Company Communications network
US6850530B1 (en) * 2000-02-04 2005-02-01 Cisco Technology, Inc. Methods and apparatus for providing and obtaining resource usage information
EP1133101A1 (en) * 2000-03-07 2001-09-12 BRITISH TELECOMMUNICATIONS public limited company Data distribution
US7225243B1 (en) * 2000-03-14 2007-05-29 Adaptec, Inc. Device discovery methods and systems implementing the same
US6892237B1 (en) * 2000-03-28 2005-05-10 Cisco Technology, Inc. Method and apparatus for high-speed parsing of network messages
KR20000036891A (en) * 2000-03-31 2000-07-05 김지혜 Method and system for filtering multicast data stream and converting to unicast data stream
JP4347497B2 (en) * 2000-04-03 2009-10-21 株式会社日立製作所 Communication control apparatus and packet conversion method
US7301952B2 (en) * 2000-04-06 2007-11-27 The Distribution Systems Research Institute Terminal-to-terminal communication connection control method using IP transfer network
US6718361B1 (en) 2000-04-07 2004-04-06 Network Appliance Inc. Method and apparatus for reliable and scalable distribution of data files in distributed networks
US6748447B1 (en) 2000-04-07 2004-06-08 Network Appliance, Inc. Method and apparatus for scalable distribution of information in a distributed network
US6993587B1 (en) 2000-04-07 2006-01-31 Network Appliance Inc. Method and apparatus for election of group leaders in a distributed network
US6751219B1 (en) 2000-04-20 2004-06-15 Aztech Partners, Inc. Multicast packet duplication at random node or at egress port with frame synchronization
US7573915B1 (en) * 2000-04-25 2009-08-11 Cisco Technology, Inc. Method and apparatus for transporting network management information in a telecommunications network
US6963563B1 (en) * 2000-05-08 2005-11-08 Nortel Networks Limited Method and apparatus for transmitting cells across a switch in unicast and multicast modes
US6505269B1 (en) 2000-05-16 2003-01-07 Cisco Technology, Inc. Dynamic addressing mapping to eliminate memory resource contention in a symmetric multiprocessor system
EP1158731A3 (en) * 2000-05-25 2003-08-13 Roke Manor Research Limited Improvements in or relating to packet switches
JP4501230B2 (en) * 2000-05-30 2010-07-14 株式会社日立製作所 IPv4-IPv6 multicast communication method and apparatus
US7924837B1 (en) * 2000-07-31 2011-04-12 Avaya Communication Israel Ltd. IP multicast in VLAN environment
JP4351368B2 (en) * 2000-08-11 2009-10-28 富士通株式会社 Data transfer method and communication apparatus using the same
US7072955B1 (en) * 2000-08-31 2006-07-04 Intel Corporation Controlling remote storage devices
US6822958B1 (en) * 2000-09-25 2004-11-23 Integrated Device Technology, Inc. Implementation of multicast in an ATM switch
US6894990B1 (en) * 2000-10-13 2005-05-17 Viasat, Inc. IP multicasting in mesh TDMA satellite networks
US6993024B1 (en) * 2000-11-16 2006-01-31 Chiaro Networks, Ltd. System and method for router multicast control
AU2002227075A1 (en) * 2000-11-29 2002-06-11 Pulsent Corporation Method and apparatus for combining dedicated and shared networks for efficient data transmission
US7007100B1 (en) * 2000-12-20 2006-02-28 Nortel Networks Limited Method for synchronization of multicast routing table changes with a plurality of multicast routing protocols
US6819666B2 (en) * 2001-01-30 2004-11-16 The Regents Of The University Of California Optical layer multicasting using multiple sub-carrier headers with header detection, deletion, and insertion via reflective single sideband optical processing
US6850515B2 (en) * 2001-01-30 2005-02-01 The Regents Of The University Of California Optical layer multicasting using a single sub-carrier header and a multicast switch with active header insertion via light circulation
US6813276B2 (en) * 2001-01-30 2004-11-02 The Regents Of The University Of California Optical layer multicasting using a single sub-carrier header with active header detection, deletion, and re-insertion via a circulating optical path
WO2002080456A1 (en) * 2001-03-30 2002-10-10 Egc & C Co., Ltd. Method of intermediating multicasting signal for multicasting embodiment
US20020143951A1 (en) * 2001-03-30 2002-10-03 Eyeball.Com Network Inc. Method and system for multicast to unicast bridging
JP3943859B2 (en) * 2001-05-01 2007-07-11 株式会社エヌ・ティ・ティ・ドコモ Mobile communication system, mobile communication method, and mobile station
US7058827B2 (en) * 2001-07-18 2006-06-06 Intel Corporation Power saving circuit has an input line coupled to an external host and a keeper to hold the line in a weakly held state
US7103011B2 (en) * 2001-08-30 2006-09-05 Motorola, Inc. Use of IP-multicast technology for 2-party calls in mobile communication networks
US7006495B2 (en) * 2001-08-31 2006-02-28 Intel Corporation Transmitting multicast data packets
US7110404B1 (en) * 2001-09-04 2006-09-19 Cisco Technology, Inc. System and method for sending a packet to multiple destinations using a pipeline network processor
US20030048501A1 (en) * 2001-09-12 2003-03-13 Michael Guess Metropolitan area local access service system
US7302700B2 (en) * 2001-09-28 2007-11-27 Juniper Networks, Inc. Method and apparatus for implementing a layer 3/layer 7 firewall in an L2 device
US7457883B2 (en) * 2001-10-12 2008-11-25 Cisco Technology, Inc. Mechanism for implementing network discovery in a cable network
US20030088620A1 (en) * 2001-11-05 2003-05-08 Microsoft Corporation Scaleable message dissemination system and method
US7647422B2 (en) * 2001-11-06 2010-01-12 Enterasys Networks, Inc. VPN failure recovery
US7383354B2 (en) 2002-02-12 2008-06-03 Fujitsu Limited Spatial reuse and multi-point interconnection in bridge-interconnected ring networks
US7092943B2 (en) 2002-03-01 2006-08-15 Enterasys Networks, Inc. Location based data
US9998321B2 (en) * 2002-03-19 2018-06-12 Apple Inc. Method and apparatus for supporting duplicate suppression when issuing multicast queries using DNS-format message packets
US7471688B2 (en) * 2002-06-18 2008-12-30 Intel Corporation Scheduling system for transmission of cells to ATM virtual circuits and DSL ports
DE10234939A1 (en) * 2002-07-31 2004-02-19 Siemens Ag Transmitting circulation information via communications network involves using at least one virtual connection for individual subscriber information transmission from central communications unit
US7263099B1 (en) * 2002-08-14 2007-08-28 Juniper Networks, Inc. Multicast packet replication
GB2394386A (en) * 2002-10-16 2004-04-21 Nokia Corp Multicast data transfer
US20050111474A1 (en) * 2002-10-31 2005-05-26 Fujitsu Limited IP multicast communication system
JP4297875B2 (en) * 2002-11-05 2009-07-15 富士通株式会社 Network relay method and apparatus
US7433307B2 (en) * 2002-11-05 2008-10-07 Intel Corporation Flow control in a network environment
KR100475852B1 (en) * 2002-11-29 2005-03-10 한국전자통신연구원 Method for managing layer-2 multicast group using IGMP packet in Ethernet switch
US20040218591A1 (en) * 2003-04-29 2004-11-04 Craig Ogawa Bridge apparatus and methods of operation
KR100503422B1 (en) * 2003-06-13 2005-07-22 한국전자통신연구원 Ethernet switch, apparatus for expanding the port and method therefor
JP2005057373A (en) * 2003-08-07 2005-03-03 Ntt Docomo Inc Radio packet communication apparatus
US7317722B2 (en) * 2003-08-20 2008-01-08 3Com Corporation System and method for distributed multicast routing
US7761589B1 (en) 2003-10-23 2010-07-20 Foundry Networks, Inc. Flow control for multi-hop networks
US7639608B1 (en) 2003-10-23 2009-12-29 Foundry Networks, Inc. Priority aware MAC flow control
US7581249B2 (en) * 2003-11-14 2009-08-25 Enterasys Networks, Inc. Distributed intrusion response system
JP2005159430A (en) * 2003-11-20 2005-06-16 Hitachi Ltd Packet distribution method, information relaying apparatus, and network system
FR2862835B1 (en) * 2003-11-24 2006-04-14 Medialive SECURED AND CUSTOMIZED DIFFUSION OF AUDIOVISUAL FLOWS BY A UNICAST / MULTICAST HYBRID SYSTEM
US7639713B2 (en) * 2004-01-21 2009-12-29 Emc Corporation Database block network attached storage packet joining
US7565448B1 (en) * 2004-02-03 2009-07-21 Sprint Communications Company L.P. Network control system for a communication network
US20050195756A1 (en) * 2004-02-26 2005-09-08 Frattura David E. Status announcement system and method
US7580403B2 (en) * 2004-02-26 2009-08-25 Enterasys Networks, Inc. Status transmission system and method
EP1725946A4 (en) * 2004-03-10 2012-07-11 Enterasys Networks Inc Dynamic network detection system and method
JP4403893B2 (en) * 2004-06-21 2010-01-27 株式会社日立製作所 Multicast packet forwarding device
US7945945B2 (en) * 2004-08-06 2011-05-17 Enterasys Networks, Inc. System and method for address block enhanced dynamic network policy management
TWI391018B (en) 2004-11-05 2013-03-21 Ruckus Wireless Inc Throughput enhancement by acknowledgment suppression
US8619662B2 (en) * 2004-11-05 2013-12-31 Ruckus Wireless, Inc. Unicast to multicast conversion
US7505447B2 (en) 2004-11-05 2009-03-17 Ruckus Wireless, Inc. Systems and methods for improved data throughput in communications networks
US8638708B2 (en) * 2004-11-05 2014-01-28 Ruckus Wireless, Inc. MAC based mapping in IP based communications
US7347628B2 (en) 2004-11-08 2008-03-25 Enterasys Networks, Inc. Optical interface identification system
US20060153088A1 (en) * 2004-11-23 2006-07-13 Wong Allen T Method and system of insuring that a user receives a multicast television signal when changing channels during a control mode switch over
US7729350B2 (en) * 2004-12-30 2010-06-01 Nokia, Inc. Virtual multicast routing for a cluster having state synchronization
CN100456752C (en) * 2005-04-04 2009-01-28 华为技术有限公司 Method for realizing group broadcasting under fast generating tree ring network
US7760727B2 (en) * 2005-06-27 2010-07-20 Lsi Corporation System & method for fabric storage utilizing multicast with distributed intelligence
US8086232B2 (en) * 2005-06-28 2011-12-27 Enterasys Networks, Inc. Time synchronized wireless method and operations
US20070058646A1 (en) * 2005-08-25 2007-03-15 Siemens Aktiengesellschaft Device and method for forwarding multicast traffic in a hybrid device
US20070097970A1 (en) * 2005-11-01 2007-05-03 Georgios Margaritis Packet retransmitter
CN1980178A (en) * 2005-12-03 2007-06-13 鸿富锦精密工业(深圳)有限公司 Network apparatus and method for retransmitting multi-casting package
US7738403B2 (en) * 2006-01-23 2010-06-15 Cisco Technology, Inc. Method for determining the operations performed on packets by a network device
US8769091B2 (en) 2006-05-25 2014-07-01 Cisco Technology, Inc. Method, device and medium for determining operations performed on a packet
US8041804B2 (en) 2006-05-25 2011-10-18 Cisco Technology, Inc. Utilizing captured IP packets to determine operations performed on packets by a network device
US7532621B2 (en) * 2006-08-30 2009-05-12 Cornell Research Foundation, Inc. Lateral error correction for time-critical multicast
US20080107109A1 (en) * 2006-11-03 2008-05-08 General Instrument Corporation Method and Apparatus for Managing Multicast Traffic in a Network at the Data Link or Level 2 Layer
US8547899B2 (en) 2007-07-28 2013-10-01 Ruckus Wireless, Inc. Wireless network throughput enhancement through channel aware scheduling
US8625500B2 (en) * 2007-12-18 2014-01-07 Nokia Siemens Networks Oy Enhanced dynamical fast-feedback channel allocations
US8355343B2 (en) * 2008-01-11 2013-01-15 Ruckus Wireless, Inc. Determining associations in a mesh network
KR101624868B1 (en) * 2008-08-06 2016-06-07 삼성전자주식회사 Method for controlling of virtualization apparatus and virtualization apparatus
US7978607B1 (en) * 2008-08-29 2011-07-12 Brocade Communications Systems, Inc. Source-based congestion detection and control
AU2009339348B2 (en) 2009-02-09 2015-05-28 Robert Bosch Gmbh Method for using a computer network
EP2410809B1 (en) * 2009-03-17 2017-08-30 Huawei Technologies Co., Ltd. Method, device and system for setting up radio bearer
US8971335B2 (en) * 2009-07-02 2015-03-03 Exafer Ltd System and method for creating a transitive optimized flow path
US8325733B2 (en) * 2009-09-09 2012-12-04 Exafer Ltd Method and system for layer 2 manipulator and forwarder
WO2011060454A2 (en) * 2009-11-16 2011-05-19 Ruckus Wireless, Inc. Establishing a mesh network with wired and wireless links
US9979626B2 (en) 2009-11-16 2018-05-22 Ruckus Wireless, Inc. Establishing a mesh network with wired and wireless links
JP5569057B2 (en) * 2010-03-15 2014-08-13 ヤマハ株式会社 Communication system, switching hub, and router
CN103368015B (en) * 2012-04-10 2016-08-17 泰科电子(上海)有限公司 Intelligent connector and bus control unit
WO2014084845A1 (en) * 2012-11-30 2014-06-05 Hewlett-Packard Development Company Path to host in response to message
US9673937B2 (en) * 2015-10-12 2017-06-06 International Business Machines Corporation Adaptive network communication protocols
US10681417B2 (en) * 2017-05-12 2020-06-09 Google Llc Enhanced multicast network communications
JP2022542422A (en) * 2019-07-30 2022-10-03 サフラン パッセンジャー イノベーションズ, エルエルシー System and method for smart broadcasting for multicast communication over IP-based TDMA networks

Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO1995001023A1 (en) * 1993-06-17 1995-01-05 Ascom Timeplex Trading Ag Hub for segmented virtual local area network

Family Cites Families (17)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
GB8407102D0 (en) * 1984-03-19 1984-04-26 Int Computers Ltd Interconnection of communications networks
US5136580A (en) * 1990-05-16 1992-08-04 Microcom Systems, Inc. Apparatus and method for learning and filtering destination and source addresses in a local area network system
US5481540A (en) * 1990-08-24 1996-01-02 At&T Corp. FDDI bridge frame learning and filtering apparatus and method
US5956335A (en) * 1991-01-25 1999-09-21 Cabletron Systems, Inc. Many to few group address translation through a network bridge
US5500860A (en) * 1991-06-14 1996-03-19 Digital Equipment Corporation Router using multiple hop redirect messages to enable bridge like data forwarding
KR960014983B1 (en) * 1992-08-31 1996-10-23 가부시끼가이샤 도시바 Local area network bridge apparatus with dedicated packet fittering mechanism
US5448565A (en) * 1992-11-12 1995-09-05 International Business Machines Corp. Multiport LAN bridge
ATE176744T1 (en) * 1992-11-27 1999-02-15 Ibm MULTIPLE END ROUTING BETWEEN AREAS
US5355375A (en) * 1993-03-18 1994-10-11 Network Systems Corporation Hub controller for providing deterministic access to CSMA local area network
JP2520563B2 (en) * 1993-05-19 1996-07-31 日本電気株式会社 Packet switching network
US5511168A (en) * 1993-07-01 1996-04-23 Digital Equipment Corporation Virtual circuit manager for multicast messaging
US5434855A (en) * 1993-07-23 1995-07-18 Digital Equipment Corporation, Patent Law Group Method and apparatus for selective interleaving in a cell-switched network
US5331637A (en) * 1993-07-30 1994-07-19 Bell Communications Research, Inc. Multicast routing using core based trees
US5400326A (en) * 1993-12-22 1995-03-21 International Business Machines Corporation Network bridge
US5530703A (en) * 1994-09-23 1996-06-25 3Com Corporation Remote communication server with automatic filtering
US5517494A (en) * 1994-09-30 1996-05-14 Apple Computer, Inc. Method and system of multicast routing for groups with a single transmitter
US5608726A (en) * 1995-04-25 1997-03-04 Cabletron Systems, Inc. Network bridge with multicast forwarding table

Patent Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO1995001023A1 (en) * 1993-06-17 1995-01-05 Ascom Timeplex Trading Ag Hub for segmented virtual local area network

Non-Patent Citations (2)

* Cited by examiner, † Cited by third party
Title
D.R. CHERITON ET AL.: "Host groups: a multicast extension for datagram internetworks", NINTH DATA COMMUNICATIONS SYMPOSIUM, September 1985 (1985-09-01), USA, pages 172 - 179, XP000560608 *
S.E. DEERING: "Multicast routing in internetworks and extended LANs", SYMPOSIUM ON COMMUNICATION ARCHITECTURES AND PROTOCOLS, August 1988 (1988-08-01), USA, pages 55 - 64, XP000573648 *

Cited By (15)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5920699A (en) * 1996-11-07 1999-07-06 Hewlett-Packard Company Broadcast isolation and level 3 network switch
EP0841782A1 (en) * 1996-11-07 1998-05-13 Hewlett-Packard Company Broadcast isolation and level 3 network switch
EP1029263A1 (en) * 1997-04-23 2000-08-23 Motorola, Inc. System, device, and method for managing multicast group memberships in a multicast network
EP1029263A4 (en) * 1997-04-23 2000-09-06 Motorola Inc System, device, and method for managing multicast group memberships in a multicast network
US7411916B2 (en) * 1998-02-26 2008-08-12 Nortel Networks Limited Data forwarding method and apparatus
GB2337674A (en) * 1998-05-21 1999-11-24 3Com Technologies Ltd Network device which functions as a bridge and a router
GB2337674B (en) * 1998-05-21 2000-05-17 3Com Technologies Ltd Integrated data table in a network device
US6661787B1 (en) 1998-05-21 2003-12-09 3Com Technologies Integrated data table in a network
US6975627B1 (en) 1998-11-11 2005-12-13 3Com Technologies Modification of tag fields in Ethernet data packets
US6442162B1 (en) 1998-11-17 2002-08-27 3Com Technologies Credit-based scheme for high performance communication between devices in a packet-based communication system
US6807175B1 (en) 2000-05-10 2004-10-19 3Com Corporation Distributed multicast routing in packet-based communication network devices
KR100437860B1 (en) * 2001-03-30 2004-06-26 주식회사 이지씨앤씨 Method of intermediating multicasting signal for multicasting embodiment
US7877508B1 (en) 2001-10-19 2011-01-25 Foundry Networks, Llc Method and system for intelligently forwarding multicast packets
US8443103B2 (en) 2001-10-19 2013-05-14 Foundry Networks, Llc Method and system for intelligently forwarding multicast packets
US9112715B2 (en) 2001-10-19 2015-08-18 Foundry Networks, Llc Method and system for intelligently forwarding multicast packets

Also Published As

Publication number Publication date
US5898686A (en) 1999-04-27
US6539022B1 (en) 2003-03-25
US5608726A (en) 1997-03-04
AU5579296A (en) 1996-11-18

Similar Documents

Publication Publication Date Title
US6539022B1 (en) Network device with multicast forwarding data
US5999530A (en) Method and apparatus for transparent intermediate system based filtering on a LAN of multicast packets
JP3279319B2 (en) Method and apparatus for synchronizing data transmission over an on-demand link in a network
Waitzman et al. Distance vector multicast routing protocol
JP3621646B2 (en) Communication network with variable address learning, switching and routing
EP0937353B1 (en) Routing in a multi-layer distributed network element
US7706258B2 (en) System and method for detecting loops in a customer-provider bridge domain
US6538997B1 (en) Layer-2 trace method and node
US6785274B2 (en) Efficient network multicast switching apparatus and methods
US6556574B1 (en) Duplicate ignore delay timer for ARP like protocol messages using are protocol
US8085770B2 (en) Method of transporting a multipoint stream in a local area network and device for connection implementing the method
US8493989B2 (en) Network device and data control program
US5291490A (en) Node for a communication network
KR20080089285A (en) Method for protection switching in ethernet ring network
US20080107109A1 (en) Method and Apparatus for Managing Multicast Traffic in a Network at the Data Link or Level 2 Layer
Waitzman et al. RFC1075: Distance Vector Multicast Routing Protocol
US6965577B1 (en) Identifying an edge switch and port to which a network user is attached
US7474660B1 (en) MAC address extension to maintain router information in source routed computer networks
Cisco Configuring IP Multicast MLS
Cisco Configuring Transparent Bridging
Cisco Switching ISO CLNS
Cisco Concepts
Cisco Concepts
Cisco Concepts
Cisco Concepts

Legal Events

Date Code Title Description
AK Designated states

Kind code of ref document: A1

Designated state(s): AL AM AT AU AZ BB BG BR BY CA CH CN CZ DE DK EE ES FI GB GE HU IS JP KE KG KP KR KZ LK LR LS LT LU LV MD MG MK MN MW MX NO NZ PL PT RO RU SD SE SG SI SK TJ TM TR TT UA UG UZ VN AM AZ BY KG KZ MD RU TJ TM

AL Designated countries for regional patents

Kind code of ref document: A1

Designated state(s): KE LS MW SD SZ UG AT BE CH DE DK ES FI FR GB GR IE IT LU MC NL PT SE BF BJ CF CG CI CM GA GN ML

DFPE Request for preliminary examination filed prior to expiration of 19th month from priority date (pct application filed before 20040101)
121 Ep: the epo has been informed by wipo that ep was designated in this application
REG Reference to national code

Ref country code: DE

Ref legal event code: 8642

122 Ep: pct application non-entry in european phase
NENP Non-entry into the national phase

Ref country code: CA