Source: http://www.google.com/patents/US20030079040?dq=6,788,314
Timestamp: 2017-01-19 15:21:36
Document Index: 24042771

Matched Legal Cases: ['art 200', 'art 200', 'art 200', 'art 300', 'art 300', 'art 300']

Patent US20030079040 - Method and system for intelligently forwarding multicast packets - Google PatentsSearch Images Maps Play YouTube News Gmail Drive More »Sign inPatentsA routing system utilizes a layer 2 switch interconnecting several routers to intelligently forward multicast packets throughout an internet exchange carrying multicast content. The layer 2 switch performs protocol snooping to extract a lookup key that is based on network layer protocol information....http://www.google.com/patents/US20030079040?utm_source=gb-gplus-sharePatent US20030079040 - Method and system for intelligently forwarding multicast packetsAdvanced Patent SearchTry the new Google Patents, with machine-classified Google Scholar results, and Japanese and South Korean patents.Publication numberUS20030079040 A1Publication typeApplicationApplication numberUS 09/982,106Publication dateApr 24, 2003Filing dateOct 19, 2001Priority dateOct 19, 2001Also published asEP1444598A1, US7389359, US7877508, US8443103, US9112715, US20100238927, US20110064078, WO2003036503A1Publication number09982106, 982106, US 2003/0079040 A1, US 2003/079040 A1, US 20030079040 A1, US 20030079040A1, US 2003079040 A1, US 2003079040A1, US-A1-20030079040, US-A1-2003079040, US2003/0079040A1, US2003/079040A1, US20030079040 A1, US20030079040A1, US2003079040 A1, US2003079040A1InventorsNitin Jain, Lee Chen, Earl Ferguson, Min ZhuOriginal AssigneeNitin Jain, Lee Chen, Earl Ferguson, Min ZhuExport CitationBiBTeX, EndNote, RefManPatent Citations (18), Referenced by (104), Classifications (4), Legal Events (12) External Links: USPTO, USPTO Assignment, EspacenetMethod and system for intelligently forwarding multicast packets
DETAILED DESCRIPTION OF THE INVENTION [0021] I. Introduction [0022] The method and system of the present invention provides protocol snooping to intelligently forward multicast packets to those ports of a switch that are connected to a neighboring device that directly or indirectly services the members of a multicast group. In an embodiment, the protocol type is Protocol Independent Multicast (PIM). However the present invention supports other multicast protocols and/or standards. [0023] Protocol snooping limits the multicast content to only those routers, within a VLAN domain, that require the content. Therefore, multicast traffic is not required to be seen by all multicast routers in the VLAN. As a result, the present invention can be implemented to conserve bandwidth on the VLAN because not all receivers are required to see the multicast traffic. The switch of the present invention also is not required to be configured for any special tagging technique because intelligent forwarding is based on information learned from control messages exchanged between the multicast routers. [0024] II. System Overview [0025] [0025]FIG. 1 illustrates a switch 100 according to an embodiment of the present invention. Switch 100 includes a plurality of input/output (I/O) physical ports 102 a-102 n, a plurality of packet processors 104 a-104 n, a forwarding content addressable memory (CAM) 106, an outgoing port lookup table (LUT) 108, a discovery list 110, a central processor (CPU) 112, a switch fabric 114, a shared memory buffer 116, a forwarding engine 118, and one or more neighboring switch interfaces (I/F) 120. The I/O physical ports 102 a-102 n (collectively referred to herein as I/O ports 102) serve as a physical layer interface supporting bi-directional communication between switch 100 and another neighboring device, such as an end station, a router, and/or like network device. Each individual I/O port 102 is connected to one or more neighboring devices. The connection between each I/O port 102 and the neighboring device(s) comprises wired, wireless, or both transmission media, including satellite, terrestrial (e.g., fiber optic, copper, coaxial, hybrid fiber-coaxial (HFC), or the like), radio, microwave, and/or any other form or method of transmission. [0026] The I/O ports 102 are connected to packet processors 104 a-104 n (collectively referred to herein as packet processors 104). Each I/O port 102 exchanges packetized signals (e.g., electronic, electromagnetic, optical, or the like), demodulates the packetized signals, and delivers the packets to a packet processor 104. Each packet processor 104 parses and examines the packets for further processing. Further processing depends on whether the packets contain a control message and/or content payload(s). [0027] If a packet contains content payload(s) (e.g., voice, data, and/or other forms of media, multimedia, or the like), packet processor 104 examines the packet to determine forwarding information (FID) regarding the disposition of the packet. The FID includes a destination port, port mirror requirement, packet type, VLAN handling, prioritization, multicast group membership, and/or like features. The destination port indicates which of the plurality of I/O ports 102 will receive the packet. As described in greater detail below, packet processor 104 interacts with forwarding CAM 106, outgoing port LUT 108, and/or CPU 112 to determine the FID. Packet processor 104 postpends the FID to the packet before the packet is forwarded to switch fabric 114. [0028] Forwarding engine 118 communicates with each packet processor 104, switch fabric 114, CPU 112, and other components of switch 100, as required. Forwarding engine 118 uses the FID, or the like, to direct traffic from one location to the next. [0029] Switch fabric 114 is connected to shared memory buffer 116 and neighboring switch interface(s) 120. Switch fabric 114 stores packets in shared memory buffer 116. Shared memory buffer 116 assigns a shared memory location identifier (SMID) to each received packet, and stores the SMID in a priority queue located in the shared memory buffer 116. The priority queue is associated with the I/O port(s) 102 and/or neighboring switch interface(s) 120 designated in the FID. When the SMID reaches the front of the queue, the priority queue is emptied on a FIFO basis and the associated packet is forwarded to the associated I/O port(s) 102 and/or neighboring switch interface(s) 120. I/O port(s) 102 and/or neighboring switch interface(s) 120 operate to modulate packets and send packetized signals to a designated device(s). [0030] In regards to I/O port(s) 102, the designated device(s) can be a neighboring end station, a router, and/or like network device, as described above. In regards to neighboring switch interface(s) 120, the designated device(s) is one or more neighboring switches, such as another switch 100, or like switching device(s). As described with respect to I/O ports 102, the connection between neighboring switch interface(s) 120 and a neighboring switch(es) comprises wired, wireless, or both transmission media, including satellite, terrestrial (e.g., fiber optic, copper, coaxial, hybrid fiber-coaxial (HFC), or the like), radio, microwave, and/or any other form or method of transmission. [0031] On the other hand, if a packet received at packet processor 104 is a control message or if a content packet contains a control message (for example, in a header frame), packet processor 104 forwards the control message to discovery list 110 or CPU 112, as described in greater detail below. The present invention supports two types of control messages for determining FID: a hello message and a join/prune message. Both control message types are defined in Experimental Internet Protocol Standard, Request for Comments (RFC) 2362 (Internet Architecture Board). However the present invention includes any similar control messages created and/or exchanged to provide the functions described herein. [0032] Accordingly, a neighboring router periodically transmits a hello message to switch 100 to announce its presence to switch 100 and/or other upstream designated router(s). Packet processor 104 forwards the hello message to discovery list 110. Discovery list 110 stores the hello message until it is retrieved by CPU 112, as described in greater detail below. [0033] The second type of control message is a join/prune message. A neighboring router periodically exchanges join/prune messages with switch 100 and/or other neighboring router(s) to designate group memberships for a multicast. A join/prune message contains both a join set and a prune set. The join set lists the groups that receivers have requested, and the prune set lists the groups that are not required by receivers. Packet processor 104 forwards the join/prune message to CPU 112 for further processing, as described in greater detail below. [0034] [0034]FIG. 1 is a conceptual illustration of switch 100 that facilitates explanation of the present invention. It would be apparent to one skilled in the relevant art(s) that one or more of the blocks can be performed by the same piece of hardware, module of software, or a combination thereof. It should also be understood that embodiments of the present invention can be implemented in hardware, software, or a combination thereof. In such an embodiment, the various components and steps would be implemented in hardware and/or software to perform the functions of the present invention. It should be understood that either of discovery list 110, forwarding CAM 106, and outgoing port LUT 108 can be any type of memory, including RAM, SDRAM, or the like. [0035] III. Constructing and Updating Forwarding Information [0036] As described in reference to FIG. 1, packet processor 104 examines each content packet to determine its FID. The FID is postpended to the content packet, and switch 100 subsequently uses the FID to handle the disposition of the content packet. To determine the FID, packet processor 104 interacts with other system components to query one or more FID tables stored in the system memories (i.e., forwarding CAM 106, outgoing LUT 108, and/or discovery list 110). The FID tables are periodically populated and refreshed by control messages exchanged by the neighboring routers. [0037] Referring to FIG. 2, flowchart 200 represents the general operational flow of an embodiment of the present invention. More specifically, flowchart 200 shows an example of a control flow for processing control messages to create or update forwarding information for multicasts. [0038] The control flow of flowchart 200 begins at step 201 and passes immediately to step 203. At step 203, an I/O port 102 receives a packetized signal having a control message from a neighboring device. The physical form of the signal can be electronic, electromagnetic, optical, or the like. The signal is demodulated and delivered to packet processor 104. [0039] At step 206, packet processor 104 determines the type of control message. As described above, in an embodiment, the control message is either a hello message or a join/prune message. If a hello message is detected, forwarding engine 118 sends the hello message to CPU 112, or stores the control packet in discovery list 110. Afterwards, the control passes to step 209. [0040] At step 209, CPU 112 processes the hello message to create or update a neighbor list. The neighbor list identifies the neighboring router that sent the hello message, the address (e.g., IP address) of the neighboring router, the incoming I/O port 102 that received the hello message, and the like. As such, switch 100 is able to track and update a list of IP addresses and I/O port(s) 102 that are associated with a neighboring router that transmits a hello message. [0041] If the hello message is received from neighboring switch interface(s) 120, CPU 112 makes note that the corresponding router(s) is being serviced by a neighboring switch. Therefore, the incoming neighboring switch interface(s) 120 is noted in the neighbor list instead of noting an incoming I/O port 102. [0042] On the contrary, if at step 206, a join/prune message is detected, the control passes to step 212. At step 212, the multicast mode of operation is considered. In an embodiment, switch 100 supports two operational modes for multicasting: shared source distribution multicasting and single source distribution multicasting. In an embodiment, shared source distribution multicasting is defined by protocol independent multicasting (PIM) sparse mode (SM) operational mode, and explicit source distribution multicasting is defined by PIM single source multicasting (SSM) operational mode. In an embodiment, the operational mode is established manually by a systems operator. In another embodiment, the operational mode is set and/or altered by CPU 112 and/or another application software in communication with CPU 112. [0043] It should be understood, however, that the present invention supports other multicast protocols in addition to PIM SM and PIM SSM, as would be apparent to one skilled in the relevant art(s). For example, the switch of the present invention can be configured to support the Multiprotocol Label Switching (MPLS) standards defined by the Internet Engineering Task Force, the Point-to-Point Protocol (PPP) defined in Internet Protocol Standard (STD) 51, Request for Comments (RFC) 1661 (Internet Architecture Board), and/or like standards and/or protocols governing layer 2 switching. [0044] Therefore, referring back to FIG. 2, the control passes to step 215 if the control message establishes shared source distribution trees (e.g., PIM SM operational mode), and the control passes to step 218 if the control message establishes explicit source distribution trees (e.g., PIM SSM operational mode). [0045] At step 215, forwarding engine 118 transfers the join/prune message from packet processor 104 to CPU 112. In turn, CPU 112 processes the join/prune message to construct or update one or more FID tables within forwarding CAM 106. Generally, the FID tables include a source-group table and a forwarding table and/or a session table. With respect to step 215, the FID tables include a source-group table and a forwarding table. The source-group table includes various data about the members of a multicast group. Such data includes, but is not limited to, a source address, destination address, and an outgoing port index associated with the source and/or destination address. The source address can be undefined or a wildcard since a multicast packet may have multiple sources. Accordingly, CPU 112 processes the join/prune message to update the aforementioned entries in the source-group table. CPU 112 also notes the incoming I/O port 102 that received the join/prune message and add an outgoing port index to the source-group table that identifies the incoming I/O port 102. Thereafter, CPU 112 also creates an entry in outgoing port LUT 108 to associate the outgoing port index to the receiving incoming I/O port 102. [0046] Another FID table residing in forwarding CAM 106 is a forwarding table. Forwarding table comprises one or more forwarding entries that include a destination MAC address and an outgoing port index. Accordingly, CPU 112 updates the forwarding entries if the join/prune message is related to an existing destination MAC address. [0047] Specifically, CPU 112 extracts multicast group information from the join/prune message to derive the destination MAC address. As described, the join list identifies the network addresses for neighboring routers that have been added to a distribution tree to support multicasts from the request group. The prune list, conversely, identifies the network addresses for the neighboring routers that will be removed from a distribution tree. Thus, the prune list specifies a holdover period stipulating a time for discontinuing the membership of a neighboring router from a distribution tree. [0048] Thus the multicast group information, extracted by CPU 112, includes network addresses (e.g., destination IP addresses) for designated neighboring routers. CPU 112 derives a destination MAC address from this multicast group information. In an embodiment, the MAC address is derived by reading the first three octets (bytes) of the multicast group address (e.g., IP address). As known to one skilled in the relevant art(s), the first three bytes of any multicast address are 01:00:5e. These three bytes are used as the first three octets in the MAC address. Next, the remaining three octets are constructed from the multicast group address which has 32 bits. Only the lower 23 bits of the multicast group address is used to construct the multicast MAC address. [0049] Once constructed, the destination MAC address serves as a shared source lookup key. Accordingly, when packet processor 104 receives a multicast content packet, the destination MAC address is used as the lookup key to determine an outgoing port index for the received packet. The outgoing port index serves as a lookup key into outgoing port LUT 108. As such, outgoing port LUT 108 specifies one or more “outgoing” I/O ports 102 (and/or neighboring switch interface(s) 120) for each outgoing port index. When queried, outgoing port LUT 108 returns the outgoing I/O port(s) 102 (and/or neighboring switch interface(s) 120) to packet processor 104 to identify the destination neighboring device(s). Packet processor 104 postpends this forwarding information to the packet and forwards the packet to switch fabric 114, as described in greater detail below. [0050] Therefore, after deriving the destination MAC address for the group, CPU 112 searches for a forwarding entry having a matching destination MAC address, and updates the forwarding table in forwarding CAM 106. This is accomplished by CPU 112 retrieving the associated outgoing port index. Thereafter, CPU 112 utilizes the outgoing port index to query the associated tuple in outgoing port LUT 108. CPU 112 then updates the tuple by revising the associated outgoing ports (i.e., I/O port(s) 102 and/or neighboring switch interface(s) 120) according to the designated routers and/or other device(s) in the new group. [0051] As the multicast group information comprises network addresses, CPU 112 performs layer 3 processing to derive the MAC address. CPU 112 thus populates forwarding CAM 106 with the layer 3 information. Therefore, when packet processor 104 queries forwarding CAM 106, packet processor 104, in essence, utilizes information derived from layer 3 processing (i.e., protocol type and network address) to intelligently forward a packet during layer 2 processing. [0052] As described, the present invention supports both shared trees and explicit source trees. For shared trees, forwarding is based on the MAC destination address lookup described in reference to step 215. However, for a source specific tree, a session lookup methodology is implemented as described with respect to step 218. [0053] At step 218, the join/prune message has specified an explicit source distribution tree (e.g., PIM SSM operational mode). Hence, forwarding engine 118 transfers the join/prune message from packet processor 104 to CPU 112. In turn, CPU 112 processes the join/prune message to construct or update the FID table(s). With respect to step 218, the FID tables include a source-group table and a session table. The source-group table includes various data about the members of a multicast group, as described above in reference to step 215. The session table includes a session entry comprising a multicast source IP address, a destination IP address, an incoming port (i.e., I/O port 102 or neighboring switch interface 120), and protocol type as part of the explicit source lookup key, and outgoing port index being the result of lookup. The incoming port is used to specify which I/O port(s) 102 (and/or neighboring switch interface(s) 120) are eligible for a session match once a packet arrives on an I/O port 102. [0054] Therefore, when processing a join/prune message, CPU 112 derives the explicit source lookup key information from the control message, and searches for a matching session entry. If an matching entry is determined, CPU 112 retrieves the associated outgoing port index. Thereafter, CPU 112 utilizes the outgoing port index to query the associated tuple in outgoing port LUT 108. CPU 112 then updates the tuple by revising the associated outgoing ports (i.e., I/O port(s) 102 and/or neighboring switch interface(s) 120) according to the designated routers and/or other device(s) in the new group. [0055] As described in detail below, a session entry is queried, or created if necessary, when a multicast content packet is received by packet processor 104 and forwarded to CPU 112. The outgoing port index, resulting from a lookup in the session table, serves as a lookup key into outgoing port LUT 108. The list of outgoing ports (i.e., I/O port(s) 102 and/or neighboring switch interface(s) 120) are constructed and maintained according to join/prune messages as described above. [0056] Once discovery list 110, forwarding CAM 106, and/or outgoing port LUT 108 have been properly constructed or updated, the control passes to step 221. At step 221, CPU 112, interacting with forwarding engine 118, either returns the hello message or join/prune message to packet processor 104, or forwards the control message to switch fabric 114. If the control message is destined for another router within the VLAN domain, the control message is associated with a SMID, queued according to the designated neighboring router, and forwarded to the router so that the neighboring router can update its forwarding table or neighbor list. After the packet has been transmitted to the designated neighboring router(s), the control flow ends as indicated by step 295. [0057] IV. Intelligent Forwarding Shared and Explicit Source Multicasts [0058] Referring to FIG. 3, flowchart 300 represents the general operational flow of an embodiment of the present invention. More specifically, flowchart 300 shows an example of a control flow for intelligently forwarding multicast content packets in shared source distribution multicast operational mode or explicit source distribution multicast operational mode. [0059] The control flow of flowchart 300 begins at step 301 and passes immediately to step 303. At step 303, an I/O port 102 receives a packetized content signal from a neighboring device. The physical form of the signal can be electronic, electromagnetic, optical, or the like. The signal is demodulated and delivered to packet processor 104. [0060] At step 306, packet processor 104 determines whether the signal comprises a unicast content packet or a multicast content packet. In an embodiment, packet processor 104 examines the destination address to determine if the packet is a unicast packet or a multicast packet. For instance, a multicast content packet has a Class D IP destination address ranging from “224.1.0.0” to “239.255.255.255.” If packet processor 104 detects a unicast packet, the control flow passes immediately to step 321, as described below. Otherwise, the control flow passes to step 309 for multicast processing. [0061] At step 309, packet processor 104 derives or reads a lookup key. As described in reference to FIG. 2, switch 100 supports two modes of operation: shared source distribution multicasting and explicit source distribution multicasting. [0062] Referring back to step 309, if switch 100 is operating with shared source distributions (e.g., PIM SM), packet processor 104 extracts a shared source lookup key. Packet processor 104 reads or derives a destination MAC address from the content packet, and the destination MAC address is used as the shared source lookup key. In an embodiment, the destination MAC address is derived by reading the first thee octets and constructing the remaining three octets from the multicast group address, as described above in reference to step 215 in FIG. 2. [0063] On the other hand, if, at step 309, switch 100 is operating with explicit source distributions (e.g., PIM SSM), packet processor 104 extracts an explicit source lookup key from the content packet. The explicit source lookup key is based on the source IP address, destination IP address, protocol type derived from the multicast packet, and the incoming I/O port 102 that received the packet. [0064] At step 312, packet processor 104 utilizes the lookup key to query a FID table stored in forwarding CAM 106. More specifically, for shared source distributions, packet processor 104 utilizes the destination MAC address as the lookup key to query a forwarding table located in forwarding CAM 106. For explicit source distributions, packet processor 104 utilizes the explicit source lookup key to query a session table located in forwarding CAM 106. If a match is found, the control flow passes immediately to step 321, as described below. Otherwise, the control flow passes to step 315. [0065] At step 315, the content packet is delivered to CPU 112 for further processing since no match exists for the extracted lookup key. Using other information extracted from the content packet, CPU 112 queries the source-group table residing in forwarding CAM 106. In an embodiment, CPU 112 uses the destination group address and, if available, the destination source address(es) to locate a matching entry. If a match is determined, CPU reads the corresponding outgoing port index, and control passes to step 318. [0066] At step 318, CPU 112 creates a new entry in either the forwarding table or session table. For shared source distributions, a new forwarding entry is added to the forwarding table based on the derived destination MAC address. For explicit source distributions, a new session entry is added to the session table based on the session lookup key. From the information returned from the source-group table, CPU 112 adds the returned outgoing port index to the forwarding entry or session entry. [0067] However, if a match is not determined at step 315, control passes to step 317. At step 317, CPU 112 identifies the outgoing I/O port(s) 102 (and/or neighboring switch interface(s) 120) that currently services the destination router(s) or other network device(s) associated with the destination address from the content packet. To identify the outgoing I/O port(s) 102 (and/or neighboring switch interface(s) 120), CPU 112 queries discovery list 110 to determine if a hello message has been received from the destination router(s). If a hello message has been received, CPU 112 reads the outgoing I/O port(s) 102 (and/or neighboring switch interface(s) 120) from the neighbor list. Thereafter, control passes to step 321. [0068] If no hello message has been received from the destination router(s), the packet is dropped for that router(s), and the control flow passes immediately to step 395. However, in an alternative embodiment, the packet is multicast to all routers within the VLAN if no hello message has been received from the destination router(s). As such, CPU 112 would identify all outgoing I/O port(s) 102 (and/or neighboring switch interface(s) 120) that service each router within the VLAN. In this embodiment, the control flow would then pass to step 321. [0069] At step 321, packet processor 104 receives the outgoing I/O port(s) 102 and/or neighboring switch interface(s) 120 for the content packet. More specifically, if a lookup match is found at step 312, forwarding CAM 106 returns the outgoing port index corresponding to the lookup key (i.e., destination MAC address or explicit source lookup key). Subsequently, outgoing port LUT 108 is queried to identify the outgoing I/O port(s) 102 and/or neighboring switch interface(s) 120 corresponding to the outgoing port index. The corresponding list of outgoing I/O port(s) 102 and/or neighboring switch interface(s)120 is sent to packet processor 104. [0070] However, if a new table entry is created at step 318, the corresponding outgoing I/O port(s) 102 and/or neighboring switch interface(s) 120 are retrieved from outgoing port LUT 108 based on the outgoing port index returned from the source-group table. Additionally, if the corresponding outgoing I/O port(s) 102 and/or neighboring switch interface(s) 120 are determined from the neighbor list as described at step 317, the corresponding list is simply forwarded to packet processor 104. [0071] If a unicast packet is detected at step 306, then, at step 321, forwarding CAM 106 returns the FID for the packet. The FID includes the outgoing I/O port(s) 102 or neighboring switch interface(s) 120 for the destination neighboring device. The FID is sent to packet processor 104, and the control flow passes to step 324. [0072] At step 324, packet processor 104 receives the list of outgoing I/O port(s) 102 and/or neighboring switch interface(s) 120 corresponding to the content packet. Packet processor 104 postpends the list to the packet. [0073] At step 327, forwarding engine 118 interacts with packet processor 104 to forward the packet to switch fabric 114. At step 330, switch fabric 114 creates a SMID for the packet, and stores the packet in shared memory buffer 116. Switch fabric 114 also stores the corresponding SMID in a priority queue also located in shared memory buffer 116. At step 333, switch fabric 114 sends the packet to the outgoing I/O port(s) 102 and/or neighboring switch interface(s) 120 linked to the designated neighboring device(s). The outgoing I/O port(s) 102 and/or neighboring switch interface(s) 120 modulate the packetized signal and transmit the signal to the designated neighboring device(s). After the packet has been transmitted to the designated neighboring device(s), the control flow ends as indicated by step 395. [0074] V. Conclusion [0075] FIGS. 1-3 are conceptual illustrations that facilitates explanation of the present invention. It will be apparent to one skilled in the relevant art(s) that the same piece of hardware or module of software can perform one or more of the blocks. It should also be understood that embodiments of the present invention could be implemented in hardware, software, or a combination thereof. In such an embodiment, the various components and steps would be implemented in hardware and/or software to perform the functions of the present invention. [0076] While various embodiments of the present invention have been described above, it should be understood that they have been presented by way of example, and not limitation. It will be apparent to persons skilled in the relevant art(s) that various changes in form and detail can be made therein without departing from the spirit and scope of the invention. Moreover, it should be understood that the method and system of the present invention should not be limited to a network with one layer 2 switch. The present invention can be implemented in any network of routers interconnected via several layer 2 switches in the core. Thus, the present invention should not be limited by any of the above-described exemplary embodiments, but should be defined only in accordance with the following claims and their equivalents. Patent CitationsCited PatentFiling datePublication dateApplicantTitleUS5394402 *Jun 10, 1994Feb 28, 1995Ascom Timeplex Trading AgHub for segmented virtual local area network with shared media accessUS5790554 *Oct 4, 1995Aug 4, 1998Bay Networks, Inc.Method and apparatus for processing data packets in a networkUS5938736 *Jun 30, 1997Aug 17, 1999Sun Microsystems, Inc.Search engine architecture for a high performance multi-layer switch elementUS5959989 *Jun 25, 1997Sep 28, 1999Cisco Technology, Inc.System for efficient multicast distribution in a virtual local area network environmentUS6094435 *Jun 30, 1997Jul 25, 2000Sun Microsystems, Inc.System and method for a quality of service in a multi-layer network elementUS6111874 *Dec 18, 1997Aug 29, 2000Advanced Micro Devices, Inc.Shared address table with source and destination two-pass algorithmUS6122669 *Dec 18, 1997Sep 19, 2000Advanced Micro Devices, Inc.Method and apparatus for auto-incrementing through table and updating single register in memoryUS6128665 *Dec 30, 1996Oct 3, 2000Cabletron Systems, Inc.System for broadcasting messages to each of default VLAN ports in subset of ports defined as VLAN portsUS6147995 *Aug 31, 1999Nov 14, 2000Cabletron Systems, Inc.Method for establishing restricted broadcast groups in a switched networkUS6226686 *Sep 28, 1999May 1, 2001HearmeServer-group messaging system for interactive applicationsUS6233618 *Mar 31, 1998May 15, 2001Content Advisor, Inc.Access control of networked dataUS6301257 *Mar 19, 1997Oct 9, 2001Nortel Networks LimitedMethod and apparatus for transmitting data frames between switches in a meshed data networkUS6539022 *Apr 26, 1999Mar 25, 2003Enterasys Networks, Inc.Network device with multicast forwarding dataUS6560236 *Oct 4, 1999May 6, 2003Enterasys Networks, Inc.Virtual LANsUS6606706 *Feb 8, 1999Aug 12, 2003Nortel Networks LimitedHierarchical multicast traffic security system in an internetworkUS6839348 *Apr 30, 1999Jan 4, 2005Cisco Technology, Inc.System and method for distributing multicasts in virtual local area networksUS6847638 *Oct 16, 2000Jan 25, 2005Cisco Technology, Inc.Multicast system for forwarding desired multicast packets in a computer networkUS20010034793 *Mar 9, 2001Oct 25, 2001The Regents Of The University Of CaliforniaCore assisted mesh protocol for multicast routing in ad-hoc networks* Cited by examinerReferenced byCiting PatentFiling datePublication dateApplicantTitleUS7236492 *Nov 21, 2001Jun 26, 2007Alcatel-Lucent Canada Inc.Configurable packet processorUS7453379Mar 12, 2007Nov 18, 2008Citrix Systems, Inc.Systems and methods for identifying long matches of data in a compression historyUS7460038Mar 12, 2007Dec 2, 2008Citrix Systems, Inc.Systems and methods of clustered sharing of compression historiesUS7512124 *Nov 14, 2003Mar 31, 2009Alcatel LucentMulticast optimization in a VLAN tagged networkUS7532134Mar 12, 2007May 12, 2009Citrix Systems, Inc.Systems and methods for sharing compression histories between multiple devicesUS7554921Oct 14, 2003Jun 30, 2009Cisco Technology, Inc.Method and apparatus for generating routing information in a data communication networkUS7580360Oct 14, 2003Aug 25, 2009Cisco Technology, Inc.Method and apparatus for generating routing information in a data communications networkUS7590114 *Feb 5, 2004Sep 15, 2009Marvell International LtdEfficient IP multicast bridging in ethernet switchesUS7606187Oct 28, 2004Oct 20, 2009Meshnetworks, Inc.System and method to support multicast routing in large scale wireless mesh networksUS7619545Mar 12, 2007Nov 17, 2009Citrix Systems, Inc.Systems and methods of using application and protocol specific parsing for compressionUS7623517 *Jun 27, 2003Nov 24, 2009Hitachi, Ltd.Multicast packet forwarding equipmentUS7630298Oct 27, 2004Dec 8, 2009Cisco Technology, Inc.Method and apparatus for forwarding data in a data communications networkUS7707307Jan 9, 2003Apr 27, 2010Cisco Technology, Inc.Method and apparatus for constructing a backup route in a data communications networkUS7710882Mar 3, 2004May 4, 2010Cisco Technology, Inc.Method and apparatus for computing routing information for a data communications networkUS7720994 *Jan 13, 2005May 18, 2010Cisco Technology, Inc.Method for suppression of multicast join/prune messages from extranet receiversUS7827237Mar 12, 2007Nov 2, 2010Citrix Systems, Inc.Systems and methods for identifying long matches of data in a compression historyUS7835312Jul 20, 2005Nov 16, 2010Cisco Technology, Inc.Method and apparatus for updating label-switched pathsUS7848224 *Jul 5, 2005Dec 7, 2010Cisco Technology, Inc.Method and apparatus for constructing a repair path for multicast dataUS7848240Jun 1, 2004Dec 7, 2010Cisco Technology, Inc.Method and apparatus for forwarding data in a data communications networkUS7865585Mar 12, 2007Jan 4, 2011Citrix Systems, Inc.Systems and methods for providing dynamic ad hoc proxy-cache hierarchiesUS7869350Jan 15, 2003Jan 11, 2011Cisco Technology, Inc.Method and apparatus for determining a data communication network repair strategyUS7872597Oct 5, 2009Jan 18, 2011Citrix Systems, Inc.Systems and methods of using application and protocol specific parsing for compressionUS7894342 *Feb 27, 2009Feb 22, 2011Cisco Technology, Inc.Efficient pruning of virtual services in bridged computer networksUS7916047Oct 16, 2008Mar 29, 2011Citrix Systems, Inc.Systems and methods of clustered sharing of compression historiesUS7933197Feb 22, 2005Apr 26, 2011Cisco Technology, Inc.Method and apparatus for constructing a repair path around a non-available component in a data communications networkUS7940776Jun 13, 2007May 10, 2011Cisco Technology, Inc.Fast re-routing in distance vector routing protocol networksUS7983262 *Sep 15, 2009Jul 19, 2011Marvell International Ltd.Efficient IP multicast bridging in ethernet switchesUS8040884 *Aug 8, 2005Oct 18, 2011Cisco Technology, Inc.Constraining multicast traffic between a layer 2 network device and a routerUS8051127May 26, 2010Nov 1, 2011Citrix Systems, Inc.Systems and methods for identifying long matches of data in a compression historyUS8063799Mar 30, 2009Nov 22, 2011Citrix Systems, Inc.Systems and methods for sharing compression histories between multiple devicesUS8090805Feb 17, 2004Jan 3, 2012Cisco Technology, Inc.System and method for performing cascaded lookups to forward packetsUS8224361Jun 17, 2008Jul 17, 2012Sybase 365, Inc.System and method for enhanced message routingUS8238232Jan 2, 2008Aug 7, 2012Cisco Technolgy, Inc.Constructing a transition route in a data communication networkUS8255570Mar 12, 2007Aug 28, 2012Citrix Systems, Inc.Systems and methods of compression history expiration and synchronizationUS8340095Sep 7, 2010Dec 25, 2012Media Patents, S.L.Equipment in a data network and methods for monitoring, configuring and/or managing the equipmentUS8352605Dec 29, 2010Jan 8, 2013Citrix Systems, Inc.Systems and methods for providing dynamic ad hoc proxy-cache hierarchiesUS8391898Feb 13, 2009Mar 5, 2013Sybase 365, Inc.System and method for enhanced message routingUS8416777May 21, 2012Apr 9, 2013Media Patents, S.L.Method for managing multicast traffic in a data network and network equipment using said methodUS8416778May 21, 2012Apr 9, 2013Media Patents, S.L.Method for managing multicast traffic in a data network and network equipment using said methodUS8467405 *Nov 17, 2009Jun 18, 2013Hitachi, Ltd.Packet forwarding equipmentUS8565140 *Jul 29, 2010Oct 22, 2013Media Patents, S.L.Methods and apparatus for managing multicast traffic through a switchUS8605727 *Jul 18, 2011Dec 10, 2013Marvell International Ltd.Efficient IP multicast bridging in ethernet switchesUS8786473Oct 18, 2011Jul 22, 2014Citrix Systems, Inc.Systems and methods for sharing compression histories between multiple devicesUS8832300Aug 6, 2012Sep 9, 2014Citrix Systems, Inc.Systems and methods for identifying long matches of data in a compression historyUS8902728Jul 11, 2012Dec 2, 2014Cisco Technology, Inc.Constructing a transition route in a data communications networkUS8908700Sep 7, 2007Dec 9, 2014Citrix Systems, Inc.Systems and methods for bridging a WAN accelerator with a security gatewayUS9031068Nov 3, 2010May 12, 2015Media Patents, S.L.Methods and apparatus for managing multicast traffic through a switchUS9065662 *Dec 10, 2013Jun 23, 2015Marvell International Ltd.Method and apparatus for using a bridge table as a routing table to route an ethernet packet received from a networkUS9189951 *Jun 1, 2007Nov 17, 2015Iii Holdings 2, LlcPortable device emergency beaconUS9210081Oct 24, 2014Dec 8, 2015Citrix Systems, Inc.Systems and methods for bridging a WAN accelerator with a security gatewayUS9219718May 7, 2014Dec 22, 2015Oracle International CorporationSystem and method for supporting sub-subnet in an infiniband (IB) networkUS9240981Jun 4, 2012Jan 19, 2016Oracle International CorporationSystem and method for authenticating identity of discovered component in an infiniband (IB) networkUS9270650Jun 4, 2012Feb 23, 2016Oracle International CorporationSystem and method for providing secure subnet management agent (SMA) in an infiniband (IB) networkUS9455898Sep 16, 2011Sep 27, 2016Oracle International CorporationSystem and method for facilitating protection against run-away subnet manager instances in a middleware machine environmentUS9510176 *Oct 19, 2015Nov 29, 2016Iii Holdings 2, LlcPortable device emergency beaconUS20030103499 *Nov 21, 2001Jun 5, 2003Tom DavisConfigurable packet processorUS20040100983 *Jun 27, 2003May 27, 2004Shinsuke SuzukiPacket forwarding equipmentUS20040125803 *Nov 14, 2003Jul 1, 2004Sangroniz Robert LeonMulticast optimization in a VLAN tagged networkUS20040174826 *Dec 26, 2002Sep 9, 2004George PopovichMethod and apparatus for minimizing dense mode multicast flooding between a local area network switch and a routerUS20050211170 *Jun 22, 2004Sep 29, 2005Applied Materials, Inc.Chemical vapor deposition plasma reactor having plural ion shower gridsUS20050211171 *Jun 22, 2004Sep 29, 2005Applied Materials, Inc.Chemical vapor deposition plasma reactor having an ion shower gridUS20050211546 *Jun 22, 2004Sep 29, 2005Applied Materials, Inc.Reactive sputter deposition plasma process using an ion shower gridUS20050214477 *Jun 22, 2004Sep 29, 2005Applied Materials, Inc.Chemical vapor deposition plasma process using an ion shower gridUS20050214478 *Jun 22, 2004Sep 29, 2005Applied Materials, Inc.Chemical vapor deposition plasma process using plural ion shower gridsUS20060067348 *Sep 30, 2004Mar 30, 2006Sanjeev JainSystem and method for efficient memory access of queue control data structuresUS20060087965 *Oct 27, 2004Apr 27, 2006Shand Ian Michael CMethod and apparatus for forwarding data in a data communications networkUS20060098607 *Oct 28, 2004May 11, 2006Meshnetworks, Inc.System and method to support multicast routing in large scale wireless mesh networksUS20060109807 *Nov 14, 2005May 25, 2006Min-Kyu LeeMulticasting using tunneling methodUS20060140203 *Dec 28, 2004Jun 29, 2006Sanjeev JainSystem and method for packet queuingUS20060143373 *Dec 28, 2004Jun 29, 2006Sanjeev JainProcessor having content addressable memory for block-based queue structuresUS20060153220 *Dec 22, 2004Jul 13, 2006AlcatelSystem and method for reducing OAM frame leakage in an ethernet OAM domainUS20060155959 *Dec 21, 2004Jul 13, 2006Sanjeev JainMethod and apparatus to provide efficient communication between processing elements in a processor unitUS20060168047 *Jan 13, 2005Jul 27, 2006Jennifer LiMethod for suppression of multicast join/prune messages from extranet receiversUS20070019646 *Jul 5, 2005Jan 25, 2007Bryant Stewart FMethod and apparatus for constructing a repair path for multicast dataUS20070019652 *Jul 20, 2005Jan 25, 2007Shand Ian M CMethod and apparatus for updating label-switched pathsUS20070030817 *Aug 8, 2005Feb 8, 2007Senthil ArunachalamConstraining multicast traffic between a layer 2 network device and a routerUS20070206599 *May 10, 2007Sep 6, 2007Bhalala Hardik BPriority Content Addressable Memory (PCAM)US20080101259 *Jan 2, 2008May 1, 2008Bryant Stewart FConstructing a transition route in a data communication networkUS20080205397 *Mar 7, 2008Aug 28, 2008Huawei Technologies Co., Ltd.Method for forwarding multicast packets in a virtual private local area network serviceUS20080224902 *Mar 12, 2007Sep 18, 2008Allen SamuelsSystems and methods of using application and protocol specific parsing for compressionUS20080224903 *Mar 12, 2007Sep 18, 2008Allen SamuelsSystems and methods for sharing compression histories between multiple devicesUS20080224906 *Mar 12, 2007Sep 18, 2008Robert PlamondonSystems and methods for identifying long matches of data in a compression historyUS20080228850 *Mar 12, 2007Sep 18, 2008Allen SamuelsSystems and methods of clustered sharing of compression historiesUS20080228939 *Mar 12, 2007Sep 18, 2008Allen SamuelsSystems and methods for providing dynamic ad hoc proxy-cache hierarchiesUS20080229137 *Mar 12, 2007Sep 18, 2008Allen SamuelsSystems and methods of compression history expiration and synchronizationUS20080299941 *Jun 1, 2007Dec 4, 2008Stephens Jr Michael ClaudePortable device emergency beaconUS20080310433 *Jun 13, 2007Dec 18, 2008Alvaro RetanaFast Re-routing in Distance Vector Routing Protocol NetworksUS20080318600 *Jun 17, 2008Dec 25, 2008Sybase 365, Inc.System and method for enhanced message routingUS20090083901 *Oct 1, 2007Apr 2, 2009Pardillo Joseph MProtective pad assembly magnetically attachable to garmentUS20090149186 *Feb 13, 2009Jun 11, 2009Sybase 365, Inc.System and method for enhanced message routingUS20090234966 *Mar 30, 2009Sep 17, 2009Allen SamuelsSystems and methods for sharing compression histories between multiple devicesUS20100061369 *Nov 17, 2009Mar 11, 2010Shinsuke SuzukiPacket forwarding equipmentUS20100085966 *Oct 5, 2009Apr 8, 2010Allen SamuelsSystems and methods of using application and protocol specific parsing for compressionUS20100220730 *Feb 27, 2009Sep 2, 2010Cisco Technology, Inc.Efficient pruning of virtual services in bridged computer networksUS20100254580 *May 26, 2010Oct 7, 2010Robert PlamondonSystems and methods for identifying long matches of data in a compression historyUS20100299442 *Jan 11, 2008Nov 25, 2010Johannes Van ElburgMessage Handling in an IP Multimedia SubsystemUS20110010441 *Sep 7, 2010Jan 13, 2011Media Patents, S.L.Equipment in a data network and methods for monitoring, configuring and/or managing the equipmentUS20110058548 *Jul 29, 2010Mar 10, 2011Media Patents, S.L.Methods and apparatus for managing multicast traffic through a switchUS20110058551 *Nov 3, 2010Mar 10, 2011Media Patents, S.L.Methods and apparatus for managing multicast traffic through a switchUS20120072564 *Sep 16, 2011Mar 22, 2012Oracle International CorporationSystem and method for providing ethernet over infiniband virtual hub scalability in a middleware machine environmentUS20160044482 *Oct 19, 2015Feb 11, 2016Iii Holdings 2, LlcPortable device emergency beaconCN102986178A *Jul 19, 2011Mar 20, 2013华为技术有限公司Multicast forwarding method and multicast forwarding device in sparse mode-protocol independent multicastWO2006050085A3 *Oct 28, 2005Apr 2, 2009Avinash JoshiSystem and method to support multicast routing in large scale wireless mesh networksWO2008157543A1 *Jun 17, 2008Dec 24, 2008Sybase 365, Inc.System and method for enhanced message routing* Cited by examinerClassifications U.S. Classification709/238International ClassificationH04L12/18Cooperative ClassificationH04L12/1886European ClassificationH04L12/18TLegal EventsDateCodeEventDescriptionJan 22, 2002ASAssignmentOwner name: FOUNDRY NETWORKS, INC., CALIFORNIAFree format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNORS:JAIN, NITIN;CHEN, LEE;FERGUSON, EARL;AND OTHERS;REEL/FRAME:012491/0481;SIGNING DATES FROM 20020110 TO 20020116Dec 22, 2008ASAssignmentOwner name: BANK OF AMERICA, N.A. AS ADMINISTRATIVE AGENT, CALFree format text: SECURITY AGREEMENT;ASSIGNORS:BROCADE COMMUNICATIONS SYSTEMS, INC.;FOUNDRY NETWORKS, INC.;INRANGE TECHNOLOGIES CORPORATION;AND OTHERS;REEL/FRAME:022012/0204Effective date: 20081218Owner name: BANK OF AMERICA, N.A. AS ADMINISTRATIVE AGENT,CALIFree format text: SECURITY AGREEMENT;ASSIGNORS:BROCADE COMMUNICATIONS SYSTEMS, INC.;FOUNDRY NETWORKS, INC.;INRANGE TECHNOLOGIES CORPORATION;AND OTHERS;REEL/FRAME:022012/0204Effective date: 20081218Apr 14, 2009CCCertificate of correctionJul 21, 2009CCCertificate of correctionJan 20, 2010ASAssignmentOwner name: WELLS FARGO BANK, NATIONAL ASSOCIATION, AS COLLATEFree format text: SECURITY AGREEMENT;ASSIGNORS:BROCADE COMMUNICATIONS SYSTEMS, INC.;FOUNDRY NETWORKS, LLC;INRANGE TECHNOLOGIES CORPORATION;AND OTHERS;REEL/FRAME:023814/0587Effective date: 20100120Jul 21, 2010ASAssignmentOwner name: FOUNDRY NETWORKS, LLC, CALIFORNIAFree format text: CHANGE OF NAME;ASSIGNOR:FOUNDRY NETWORKS, INC.;REEL/FRAME:024733/0739Effective date: 20090511Sep 23, 2011FPAYFee paymentYear of fee payment: 4Jan 21, 2015ASAssignmentOwner name: FOUNDRY NETWORKS, LLC, CALIFORNIAFree format text: RELEASE BY SECURED PARTY;ASSIGNOR:BANK OF AMERICA, N.A., AS ADMINISTRATIVE AGENT;REEL/FRAME:034792/0540Effective date: 20140114Owner name: BROCADE COMMUNICATIONS SYSTEMS, INC., CALIFORNIAFree format text: RELEASE BY SECURED PARTY;ASSIGNOR:BANK OF AMERICA, N.A., AS ADMINISTRATIVE AGENT;REEL/FRAME:034792/0540Effective date: 20140114Owner name: INRANGE TECHNOLOGIES CORPORATION, CALIFORNIAFree format text: RELEASE BY SECURED PARTY;ASSIGNOR:BANK OF AMERICA, N.A., AS ADMINISTRATIVE AGENT;REEL/FRAME:034792/0540Effective date: 20140114Jan 22, 2015ASAssignmentOwner name: BROCADE COMMUNICATIONS SYSTEMS, INC., CALIFORNIAFree format text: RELEASE BY SECURED PARTY;ASSIGNOR:WELLS FARGO BANK, NATIONAL ASSOCIATION, AS COLLATERAL AGENT;REEL/FRAME:034804/0793Effective date: 20150114Owner name: FOUNDRY NETWORKS, LLC, CALIFORNIAFree format text: RELEASE BY SECURED PARTY;ASSIGNOR:WELLS FARGO BANK, NATIONAL ASSOCIATION, AS COLLATERAL AGENT;REEL/FRAME:034804/0793Effective date: 20150114Jan 29, 2016REMIMaintenance fee reminder mailedFeb 23, 2016FPAYFee paymentYear of fee payment: 8Feb 23, 2016SULPSurcharge for late paymentYear of fee payment: 7RotateOriginal ImageGoogle Home - Sitemap - USPTO Bulk Downloads - Privacy Policy - Terms of Service - About Google Patents - Send FeedbackData provided by IFI CLAIMS Patent Services