Source: http://www.google.com/patents/US20030202536?dq=5,742,768
Timestamp: 2017-02-20 16:27:13
Document Index: 113504264

Matched Legal Cases: ['Application No. 60', 'Application No. 60', 'Application No. 60', 'Application No. 60', 'Application No. 60', 'Application No. 60', 'Application No. 60', 'Application No. 60', 'Application No. 60', 'Application No. 60']

Patent US20030202536 - Integrated analysis of incoming data transmissions - Google PatentsSearch Images Maps Play YouTube News Gmail Drive More »Sign inPatentsA method, system, and computer-readable medium for integrating multiple techniques for processing data communications is described in which the processing steps shared by multiple of the techniques do not have to be duplicated by each of the techniques. In some situations, some or all of the multiple...http://www.google.com/patents/US20030202536?utm_source=gb-gplus-sharePatent US20030202536 - Integrated analysis of incoming data transmissionsAdvanced Patent SearchTry the new Google Patents, with machine-classified Google Scholar results, and Japanese and South Korean patents.Publication numberUS20030202536 A1Publication typeApplicationApplication numberUS 10/066,159Publication dateOct 30, 2003Filing dateOct 26, 2001Priority dateApr 27, 2001Also published asUS6993023, US6996058, US7042877, US7068666, US7068667, US7164656, US20020159389, US20020159437, US20020159446, US20020159451, US20020159452, US20020159453, US20020159456, US20020159458, US20020159468, US20020161887, US20020161923, US20020167902, US20020181395, US20020184529, US20020188754, US20030189927, US20030202535, US20030204618, US20040004966Publication number066159, 10066159, US 2003/0202536 A1, US 2003/202536 A1, US 20030202536 A1, US 20030202536A1, US 2003202536 A1, US 2003202536A1, US-A1-20030202536, US-A1-2003202536, US2003/0202536A1, US2003/202536A1, US20030202536 A1, US20030202536A1, US2003202536 A1, US2003202536A1InventorsMichael Foster, Michael DorsettOriginal AssigneeFoster Michael S., Dorsett Michael A.Export CitationBiBTeX, EndNote, RefManPatent Citations (99), Referenced by (106), Classifications (31), Legal Events (3) External Links: USPTO, USPTO Assignment, EspacenetIntegrated analysis of incoming data transmissions
DETAILED DESCRIPTION [0013] A software facility is described below that integrates multiple techniques for processing data communications in such a manner that some or all of the processing steps shared by multiple of the techniques are performed only once. In some embodiments, some or all of the multiple processing techniques are performed in parallel, such as on different processors, in order to further speed their performance. Integrating the multiple processing techniques provides a variety of benefits, as discussed in greater detail below. [0014] In some embodiments, a Multi-Protocol Edge Switch (“MPEX”) is used to integrate multiple processing techniques for received data communications from one network that are to be forwarded to a destination on a different network. Such MPEXs are typically designed to act as a gateway that bridges networks using multiple data link layer network protocols (i.e., layer 2 of the 7-layer ISO network model), such as Ethernet and Fibre Channel. In particular, such MPEXs typically receive incoming data communications that are encoded with a source network protocol used by a source network to which the MPEX belongs, and perform protocol translation in order to construct an outgoing data communication that corresponds to the received data communication but is encoded with a different destination network protocol used by a different destination network. In embodiments discussed in greater detail below, MPEXs are enhanced so as to integrate one or more additional data communication processing techniques in such a manner that common processing steps, such as deconstructing incoming data frames or packets in order to identify relevant header and payload information, are performed only once. Moreover, some MPEX embodiments use specialized hardware, such as a network processor (e.g., a C-Port C-5 network processor from C-Port Corporation), to enhance the speed of the common processing steps and/or the non-common processing steps. [0015] In some embodiments, enhanced MPEXs provide multiple processing techniques that can include some or all of protocol translation processing, load balancing between multiple alternative destinations on one or more of the networks to which the MPEX belongs, firewall and other content-based analysis for any or all of the nodes on one or more of the networks to which the MPEX belongs, and content-based routing of data communications in order to identify appropriate destinations and/or transmission routes. Various other data communication processing techniques can similarly be integrated together. Moreover, some embodiments of the MPEX perform some or all of the additional processing techniques and protocol translation processing in parallel (e.g., the non-common processing steps), such as on individual general-purpose processors (e.g., PowerPC processors from Motorola, Inc.) that are appropriately configured. [0016] In other embodiments, multiple data communication processing techniques are integrated together by devices other than an MPEX, such as by any intermediate device or component that receives data communications before forwarding them to an ultimate destination. In addition, various specialized hardware can be used in some embodiments to assist in the performance of some or all of the data communication processing techniques. For example, content-based routing of data communications (e.g., by analyzing data communications at some or all of layers 4-7 of the ISO networking model, such as to assist in determining appropriate destinations) and/or load balancing may be assisted with products such as the CSS 11000 series of switches (e.g., the CSS 11154) and/or the Content Router 4400 from Cisco Systems, Inc., the WebSphere Edge Server from IBM Corporation, and the ACEdirector Web switch from Alteon WebSystems. [0017] In addition, some embodiments of the MPEX or other intermediate device use virtual identifiers to route communications through one or more of the networks to which that MPEX or other intermediate device belongs. Each virtual identifier is assigned in some embodiments to a path through a network to one or more destinations, such as by a network manager for that network. Using virtual identifiers for routing of communications, rather than network addresses or logical names that are specific to a destination, provides a variety of benefits as discussed in greater detail below. [0018] In particular, embodiments of MPEXs or other intermediate devices that use virtual identifiers to route data communications include one or more Virtual Identifier (“VI”) Network Interface Controller (“NIC”) facilities (e.g., one VI NIC for each network interface). When a VI NIC receives an indication that a data communication to one or more remote nodes on a network is to occur, such as from a local or remote application, the VI NIC will identify an appropriate transmittal virtual identifier that can be used to route the data communication through the network to the appropriate remote destination nodes without being assigned to or directly associated with those destination nodes. Such data communications can include both transitory connectionless transmittals of data (e.g., unidirectional transmittals from a source to a destination) and non-transitory connections that allow multiple distinct transmittals of data (e.g., a persistent dedicated connection that allows a connection-initiating source and a connection destination to transmit data back and forth). [0019] The VI NIC can identify an appropriate transmittal virtual identifier for routing a data communication in various ways. In some embodiments, the VI NIC will register some or all outgoing data communications with a network manager for a network, and will receive an appropriate transmittal virtual identifier to be used for that communication through that network from the network manager. If an indicated data communication corresponds to a previously registered data communication (e.g., to an existing connection or to a previous communication to the same destination and in the same transmission manner), however, the VI NIC could instead in some embodiments use the previously received transmittal virtual identifier for that data communication rather than perform an additional registration for the indicated data communication. The manners in which a data communication can be transmitted vary with the transmission characteristics that are supported by a network, and can include factors such as a particular Class Of Service (“COS”) or transmission priority. [0020] In some embodiments in which virtual identifiers are assigned to paths through a network, the assignment of paths to such virtual path identifiers is performed in a dynamic fashion after an indication is received that a data communication is to occur, such as by the network manager upon receipt of a data communication registration. The assigning of a virtual path identifier to a path can include the configuring of each of one or more intermediate routing devices (e.g., routers or switches) along the path to the destination, such as by the network manager, so that when one of the routing devices receives a data communication that includes the virtual identifier it will forward the communication in an appropriate manner either directly to the destination or instead to a next routing device along the path that is similarly configured. [0021] The VI NIC can also assist in some embodiments in determining appropriate destinations for an indicated data communication, either directly or in conjunction with the network manager (e.g., by registering the data communication with the network manager), with the transmittal virtual identifier for that data communication selected so as to route the data communication to those destinations. In some situations, the indicated data communication may explicitly specify a destination, such as with a destination network address, while in other situations a destination may not be specified, such as when an application is publishing information and is relying on a third party to route the information to one or more current subscribers for that information. Regardless of whether a destination is specified, however, the VI NIC and/or the network manager in those embodiments can select one or more destinations that are appropriate for the indicated data communication, even if the specified destination is not among the selected destinations. This destination selection can be made by considering one or more of various factors, including any destinations specified, any expressions of interest made by potential recipients in the data communication (e.g., subscription requests), the type or classification of data being communicated, the manner of the data communication (e.g., a specified COS and/or transmission priority), the identity or type of the source node and/or source application, the type of a destination application, etc. [0022] In some situations, a source of an indicated data communication may specify a destination using a destination network address that is not mapped to any node in the network, and if so the VI NIC and/or the network manager could then select an appropriate destination for that destination network address. Multiple destinations can also be selected for an indicated data communication, even if that data communication specified a single destination (which may or may not be one of the selected destinations). If so, a single transmittal virtual identifier can be used to route the data communication to each of the multiple selected destinations such as by configuring one or more intermediary routing devices to divide received communications that use that transmittal virtual identifier so as to forward a copy of such received communications to each of multiple destinations (or multiple next routing devices). [0023] In some embodiments, virtual identifiers correspond to paths through a network that are specific to a source. If so, a single virtual identifier can be used by different sources for different paths, such as to different destinations if the different paths do not overlap. The use of virtual addresses also allows a path corresponding to a virtual identifier to be reconfigured in a manner transparent to a source using that virtual identifier, such as to correspond to a different path to the same destination or to a path to a different destination. [0024] In some embodiments, when a data communication indicated by a source can result in bidirectional communication (e.g., a response from one or more of the destinations), the VI NIC also identifies a response virtual identifier that can be used for routing data from one or more of the destinations back to the source. If the VI NIC registers the data communication with a network manager, this response virtual identifier may be received from the network manager. After identifying this response virtual identifier, the VI NIC associates it with information indicating how to process received data communications that are routed using the response virtual identifier. Such received data communications can be processed in various ways, such as by forwarding the data communications to one or more resources associated with the destination node (e.g., an executing application program, a file on storage, or a device that is part of the node). For example, if a source application on a source node initiates a bidirectional communication, a VI NIC for the source node may associate the response virtual identifier with that source application so that received responses can be forwarded to that source application (which then becomes the destination application for those received communications). Alternatively, a VI NIC on an MPEX could process received data communications using one or more of the previously mentioned processing techniques before forwarding a corresponding created outgoing data communication to a remote node on another network. [0025] The association of a virtual identifier with a corresponding destination application to which a data communication will be forwarded can be performed in various ways. For example, software applications that communicate using TCP/IP mechanisms often use TCP/IP sockets, which include a combination of an IP address and a software port number specific to a computing device using that IP address. Thus, in those embodiments the response virtual identifier can be associated with socket information for the source application. In a similar manner, in some embodiments a destination node associates transmittal virtual identifiers used to route data communications to that destination with an appropriate resource local to the destination node, such as based on information provided to the destination node by the network manager as part of the registering of those data communications and/or based on information included as part of the data communications. [0026] When the VI NIC has access to application-specific information for a destination application for a received communication, such as TCP/IP socket information that is associated with a response virtual identifier, the VI NIC can use the information to provide additional benefits. For example, many network nodes and/or applications executing on such nodes require that various information be correctly specified in a received communication in order for that communication to be accepted, such as for security reasons. One example is that a destination application using TCP/IP communication mechanisms may require that any received transmissions include the correct TCP/IP socket information corresponding to that application. However, the previously discussed use of transmittal virtual identifiers can result in valid communications being received having incorrect TCP/IP socket information for a destination application, as discussed in greater detail below. When this occurs, the VI NIC that receives the communication can replace the incorrect included TCP/IP socket information with the correct information for the application by using the TCP/IP socket information that is associated with the transmittal virtual identifier used to route the communication. In addition, in some embodiments the VI NIC may verify the accuracy of the received communication in various ways before performing such information replacement. [0027] The use of virtual identifiers can result in valid received communications that have incorrect information for a destination application in various ways. For example, if a source application specifies a destination IP address and that destination IP address is included in the data being communicated (e.g., in a location reserved for such a destination network address), but a VI NIC for that source application identifies one or more destinations that do not correspond to that destination IP address (e.g., that have other IP addresses), then the data communication will include a specified destination IP address that does not correspond to the IP addresses used by applications at the identified destinations. In addition, if multiple destinations with different IP addresses are identified by the VI NIC when only a single destination IP address was specified, most of the destinations will receive communications that do not include correct IP address information. In such situations, the VI NIC that receives the communication can replace the incorrect included IP address information with the correct IP address information for the application by using the TCP/IP socket information that is associated with the virtual identifier used to route the communication. Those skilled in the art will appreciate that a similar information replacement can be used for other communication mechanisms. In addition, in situations in which a data communication is being routed to only a single destination, the VI NIC that sends the data communication can perform the information replacement if that VI NIC has access to the necessary application-specific information for the destination application. [0028] In some embodiments, a VI NIC can also identify information related to routing a data communication other than a transmittal virtual identifier, either directly or in conjunction with the network manager (e.g., by registering the data communication with the network manager). For example, the VI NIC may identify one or more QOS parameters that relate to a manner in which the data communication should occur, such as a specified COS and/or a priority to be used for the transmission of the data. If so, the VI NIC can also use such QOS parameters when transmitting data for that data communication. [0029] Additional details about integrating multiple data communication processing techniques and about the use of virtual identifiers are discussed in the following patent applications, each of which are incorporated by reference in their entirety: Provisional U.S. Application No. 60/287,068, filed Apr. 27, 2001, entitled “GENERATION OF SYNCHRONIZED 50% DUTY CYCLE CLOCKS” (attorney docket no. 030048011US); Provisional U.S. Application No. 60/287,121, filed Apr. 27, 2001, entitled “FREQUENCY DETECTION AND LOCK FOR PHASED LOCK LOOP” (attorney docket no. 030048012US); Provisional U.S. Application No. 60/287,069, filed Apr. 27, 2001, entitled “METHOD FOR IMPLEMENTING A CLUSTER NETWORK FOR HIGH PERFORMANCE AND HIGH AVAILABILITY USING A FIBRE CHANNEL SWITCH FABRIC” (attorney docket no. 030048013US); Provisional U.S. Application No. 60/287,120, filed Apr. 27, 2001, entitled “MULTI-PROTOCOL NETWORK FOR ENTERPRISE DATA CENTERS” (attorney docket no. 030048014US); Provisional U.S. Application No. 60/286,918, filed Apr. 27, 2001, entitled “UNIFIED ENTERPRISE NETWORK SWITCH (UENX) PRODUCT SPECIFICATION” (attorney docket no. 030048015US); Provisional U.S. Application No. 60/286,922, filed Apr. 27, 2001, entitled “QUALITY OF SERVICE EXAMPLE” (attorney docket no. 030048016US); Provisional U.S. Application No. 60/287,081, filed Apr. 27, 2001, entitled “COMMUNICATIONS MODEL” (attorney docket no. 030048017US); and Provisional U.S. Application No. 60/287,075, filed Apr. 27, 2001, entitled “UNIFORM ENTERPRISE NETWORK SYSTEM” (attorney docket no. 030048018US). Each of the following patent applications similarly include additional details about integrating multiple data communication processing techniques and about the use of virtual identifiers, and are also each hereby incorporated by reference in their entirety: Provisional U.S. Application No. 60/314,088 (attorney docket no. 030048015US1), filed Aug. 21, 2001 and entitled “INTERCONNECT FABRIC MODULE”, and Provisional U.S. Application No. 60/314,158 (attorney docket no. 030048036US), filed Aug. 21, 2001 and entitled “USING VIRTUAL IDENTIFIERS TO ROUTE TRANSMITTED DATA THROUGH A NETWORK”. [0030] For illustrative purposes, some embodiments are described below in which an MPEX is used to connect a Fibre Channel-based network to a network using another network protocol and/or in which an MPEX is used as part of an EDN architecture. However, those skilled in the art will appreciate that the techniques of the invention can be used in a wide variety of other situations and with other types of devices and networks, including InfiniBand-based networks and devices, and that the invention is not limited to use with Fibre Channel networks or with EDN architectures. Additional details about Fibre Channel are available in “Fibre Channel: A Comprehensive Introduction,” which is authored by Robert W. Kembel and published by Northwest Learning Associates, Inc., and which is hereby incorporated by reference in its entirety. Additional details about InfiniBand is available in the “InfiniBand Architecture Specification, Volumes 1 and 2, Release 1.0.a”, dated Jun. 19, 2001 and available at the time of this writing at the website for the InfiniBand Trade Association at “www.infinibandta.org”, and which is hereby incorporated by reference in its entirety. [0031] [0031]FIG. 1 is a network diagram illustrating various nodes of an example Fibre Channel fabric-based interconnect network that are inter-communicating using virtual identifiers. In this example embodiment, multiple interconnect fabric modules (“IFMs”) 110 with high-speed switching capabilities are used as intermediate routing devices to form an interconnect fabric, and multiple nodes 105, a network manager 115 and a Multi-Protocol Edge Switch (“MPEX”) 120 are connected to the fabric. Each of the nodes has at least one VI NIC that uses virtual identifiers when communicating and receiving data. The MPEX is used to connect the Fibre Channel network to an external network, such as an Ethernet-based network or InfiniBand-based network, and similarly includes at least one VI NIC Data is transmitted through the interconnect fabric using frames such as those defined by the Fibre Channel standard. [0032] In this example embodiment, an IFM can be dynamically configured to interconnect its communications ports so that data can be transmitted through the interconnected ports. When the network manager receives a registration indication from a VI NIC for a data communication from a source node to a destination node, the network manager selects transmittal and response virtual identifiers to be used by the source and destination nodes when sending frames to each other. When the VI NIC is part of an MPEX, the transmittal and response virtual identifiers can be supplied to the MPEX and/or to the source or destination node on the remote network for use. The network manager also identifies a path through the IFMs and their ports which frames will use when moving between the nodes. The network manager then configures the IFMs of the identified path so that when a frame that indicates the transmittal or response virtual identifiers is received at one of the IFMs, that frame is forwarded to the destination or source nodes via the path as appropriate. While the transmittal and response virtual identifiers thus use the same path (in opposite directions) in this example embodiment, they can use distinct paths in other embodiments. [0033] Each IFM may maintain a virtual identifier table for each of its ports that maps virtual identifiers to its destinations ports. When a frame is received at a source port, the IFM then uses the virtual identifier for that frame and the virtual identifier table for the source port to identify a destination port through which the frame is to be forwarded. Thus, in this embodiment, a virtual identifier identifies a path between devices, rather than identifying a source or a destination device. In one embodiment, a virtual identifier includes both a domain address and a virtual address. Each IFM is assigned a domain address, with the IFMs that are assigned the same domain address being in the same domain. The IFMs use the domain addresses to forward frames between domains, and the network manager may also configure the IFMs with inter-domain paths. When an IFM receives a frame whose virtual identifier has a domain address that matches its domain address then the frame has arrived at its destination domain. The IFM then forwards the frame in accordance with the virtual address of the virtual identifier. If, however, the domain addresses do not match, then the frame has not arrived at its destination domain, and the IFM forwards the frame using an inter-domain path. The virtual identifier table for an IFM port may thus be divided in some embodiments into a domain address table and a virtual address table that respectively map domain addresses and virtual addresses to destination ports through which frames are to be forwarded. [0034] As an illustrative example of processing a data frame that is encoded using a first data link layer network protocol (i.e., layer 2 of the 7-layer ISO network model), FIG. 2A illustrates an incoming Ethernet-encoded data frame. Multiple processing techniques will be performed on the incoming data frame, and a new data frame will be constructed that corresponds to the incoming data frame but that is encoded using a second data link layer network protocol, as illustrated in FIG. 2B with an example outgoing Fibre Channel-encoded data frame. The Fibre Channel data frame can then be forwarded to a determined destination, such as by using a destination network address or a virtual identifier to route the Fibre Channel data frame to a node on a Fibre Channel network. [0035] In the illustrated embodiment, the Ethernet data frame illustrated in FIG. 2A contains a payload that is an encapsulated TCP/IP packet whose payload includes an HTTP Request message. The header of the Ethernet data frame is illustrated in entries 202-208, and includes information such as a destination physical address (e.g., a MAC address) for the data frame, a source physical address, and a type of the Ethernet data frame payload. In this illustrated embodiment, the Ethernet data frame is being routed to an MPEX that connects two or more distinct Local Area Networks (“LANs”) using different data link layer network protocols, and thus the destination physical address in entry 204 is the destination physical address for the MPEX on the Ethernet-based LAN from which the Ethernet data frame is received. [0036] Upon receiving the Ethernet data frame, the MPEX performs various types of processing in an integrated manner before forwarding a corresponding data frame to a next (and possibly ultimate) destination on a different LAN to which the MPEX belongs that uses the Fibre Channel protocol. In particular, the MPEX in the illustrated embodiment first deconstructs the received Ethernet data frame in order to identify various information in the Ethernet data frame header and payload to be used for the processing. This deconstructing of the data frame is done in a manner specific to the Ethernet protocol, such as based on the knowledge that the payload type information is in the 21st and 22nd bytes of the data frame and that the payload information begins at byte 23 of the data frame. This deconstructing can be performed in various ways, such as by a general-purpose processor configured in an appropriate manner or instead by an appropriate network processor that is optimized to efficiently perform the deconstruction. [0037] After the deconstruction of the received data frame is performed, the deconstructed data frame information can be used by various processing techniques in either a serial or parallel manner. Deconstructing the received data frame only once and then performing multiple processing techniques using the deconstructed information allows the processing to be performed quickly and efficiently, particularly in situations in which some or all of the techniques can be performed in parallel. In some embodiments, multiple general-purpose processors or other distinct processing capabilities are available to the MPEX (e.g., as part of a network processor), and if so each analysis technique could be performed in parallel on one of the distinct processing capabilities. [0038] In the illustrated embodiment, the analysis techniques to be performed on the received data frame include classifying the type of content included in the data frame payload, analyzing the payload to determine whether any disallowed content types are present, selecting one or more of multiple possible destinations to which a corresponding data frame will be forwarded (e.g., to balance the load among those possible destinations), and constructing a new data frame based on the data link layer network protocol used by the network to which the selected destinations belong. [0039] The content classification analysis is performed so as to determine the information that will be eventually supplied to a destination application, and thus corresponds to classification at layers 4-7 of the 7-layer ISO networking model. In the illustrated embodiment, the content classification analysis uses the payload type information included in entry 208 to determine that the Ethernet data frame payload is an IP packet. The content classification analysis then analyzes information in the IP packet header in entries 210-220, including the type of the protocol of the IP packet payload in entry 212. Upon determining that the IP packet payload is a TCP protocol-based packet, the content classification then analyzes various information in the TCP packet header in entries 222-226, including the destination software port address in entry 224. In the illustrated embodiment, the content classification analysis then determines that the payload of the TCP packet is likely to be an HTTP protocol-based message based on the use of the well-known port 80 for HTTP application layer (i.e., layer 7 of the 7-layer ISO model) protocol-based messages. [0040] In some embodiments, the content type classification may end after determining that the application layer type of content is an HTTP message, while in the illustrated embodiment the analysis technique continues to analyze the TCP packet payload in entries 228-236 in a manner specific to the application layer protocol used to encode the TCP packet payload. For example, by analyzing the first line of the HTTP message illustrated in entry 228, the content classification technique can determine that the HTTP message is a Request message (i.e., by the presence of the “GET” command). In addition, various other types of information can be determined, such as the specific Uniform Resource Identifier (“URI”) requested by the message. In the illustrated message, such analysis involves combining the Host HTTP message header field value “www.XYZ.com” in entry 230 with the path portion of the URI after the “GET” command in entry 228 to form a requested URI of “http://www.XYZ.com/pub/text.html”. Those skilled in the art will appreciate that other types of information may be of interest for HTTP messages, such as the presence or values of other HTTP message header fields or information in an HTTP message body, and that information encoded using other application layer protocols (e.g., telnet, FTP, SMTP, DNS, NFS, etc.) and other types of data (e.g., video data or streaming audio data) can similarly be analyzed in a manner specific to that application layer protocol or type of data. [0041] The information obtained from the content type classification can then be used in various ways, such as to assist other processing techniques that are performed after the content classification and/or to assist in determining a manner of transmitting the corresponding data frame to a selected destination (e.g., specifying minimum Quality of Service (“QoS”) parameters for video data or preempting an existing connection to a selected destination for a high priority type of request or response). [0042] In addition to classifying the content type of the Ethernet data frame payload, the deconstructed data frame information can also be analyzed in various other ways, such as to detect the presence or absence of required or prohibited content in the payload. In some embodiments, a content analysis technique provides firewall capabilities in which prohibited types of data are prevented from entering a destination network. For example, the firewall may block data frames based on a high-level source and/or or destination network address specified in the payload, such as the source and destination IP addresses in entries 216 and 218 of the IP packet header. In addition, the payload of the Ethernet data frame, IP packet and/or TCP packet could also be analyzed to the detect the presence or absence of specified information (e.g., strings of characters that match a specified pattern). If higher-level information is available from the content type classification analysis, the content analysis techniques could additionally use such information to perform more sophisticated analysis. For example, a firewall could prohibit only certain types of messages, such as all FTP traffic, all HTTP Request (but not Response) messages, or messages that specify certain URIs. [0043] If the content analysis techniques identify the presence of prohibited information, a variety of responses could be performed, such as to prevent the forwarding of a corresponding data frame to a selected destination that corresponds to the destination IP address indicated in entry 218, or to instead modify or remove the prohibited content (e.g., any executable code or an attached file of a specified type). In a similar manner, if required content is not present, the content analysis techniques could similarly prevent the forwarding of a corresponding data frame or instead add the required content (e.g., a confidentiality notice at the end of outgoing e-mail) to the corresponding data frame before forwarding. [0044] The deconstructed data frame information can also be analyzed to determine an appropriate destination to which a corresponding data frame will be forwarded. In some embodiments, the destination determination will be performed after the content type classification and/or the content analysis, such as to eliminate the need to perform the processing if the forwarding of the corresponding data frame is to be prevented or to use information provided by the other techniques to assist in the determination of an appropriate destination. In some embodiments, the destination selection analysis merely uses specified logical destination network address information (e.g., the destination IP address specified in entry 218) and determines a single node that corresponds to that destination network address on one of the networks to which the MPEX belongs. In other embodiments, more sophisticated analysis is performed, such as to load balance multiple alternative nodes that correspond to the indicated destination network address and/or to select one or more destinations based on other information from the deconstructed data frame, such as a type of data (e.g., video data) or type of application layer protocol information (e.g., FTP or HTTP) included in the received data frame. If the content type classification analysis further provides information specific to the type of content (e.g., the specific URI requested in an HTTP Request message), such information can similarly be used in selecting the destination. [0045] The deconstructed data frame information can also be used to construct a new data frame that corresponds to the received data frame, such as by a protocol translation technique that constructs a new data frame encoded using a different data link layer network protocol than that of the deconstructed data frame. Such data frame construction processing allows the MPEX in the illustrated embodiment to act as a gateway that bridges networks using Ethernet and Fibre Channel network protocols. If information is available from the content type classification, content analysis and/or destination selection analysis techniques, such information can be incorporated in the new data frame as it is constructed. Alternatively, if the construction of the new data frame occurs before those other analysis techniques have completed (e.g., if performed in parallel with the other techniques), relevant information can be added to the newly-constructed data frame after the completion of those techniques, such as to add a high-level destination network address for the selected destination. [0046] [0046]FIG. 2B illustrates an example of a newly-constructed Fibre Channel-based data frame that corresponds to the deconstructed Ethernet data frame. In particular, in the illustrated embodiment a destination has been selected on a Fibre Channel-based network to which the MPEX belongs, and an indication of the destination has been placed in entry 256 of the new data frame, which is defined to hold the physical address of the destination hardware port on the node to receive the data frame. As described above, however, in some embodiments the MPEX uses a destination physical address in entry 256, while in other embodiments a virtual identifier that is not associated with a destination (e.g., that is associated with a path through the network from the MPEX to the destination) is instead specified in entry 256. Various other information is specified in entries 252-264 that correspond to the header of the data frame, including Class Specific Control information specified in entry 258 of the new data frame that affects the manner in which the data frame will be transmitted with transmission priority information and preemption information related to existing dedicated connections. In the illustrated embodiment, the payload of the new data frame is specified in a manner similar to that of the payload of the received Ethernet data frame, with the TCP/IP packet information encapsulated in the payload. As previously noted, however, in other situations payloads may be altered for various reasons, such as in response to modifications performed by the content analysis techniques. After constructing the new data frame and if no indications are received to prevent its forwarding, the newly-constructed data frame is then forwarded along the Fibre Channel-based network to the selected destination. Before performing the forwarding, an additional step may be performed in some embodiments of registering the newly constructed data frame with a network manager for the Fibre Channel-based network, such as to determine an appropriate virtual identifier to be used for the transmitting of the data frame and/or to assist in selecting one or more appropriate destinations for the data frame. [0047] [0047]FIG. 3A is a block diagram illustrating an embodiment of an MPEX computing device 300 suitable for performing the data frame deconstruction and integrated data communication processing techniques discussed, and also illustrates various node computing devices 355 and 365 with which the MPEX can inter-communicate. The illustrated MPEX belongs to a Fibre Channel-based Interconnect Fabric network 350 that includes the nodes 355 and a Network Manager 357, and also belongs to a Ethernet-based network 360 to which the nodes 365 belong. [0048] The illustrated embodiment of the MPEX includes one or more CPUs 305, various I/O devices 310, storage 320 and memory 330. The I/O devices include a Fibre Channel network interface 312 which connects the MPEX to the Interconnect Fabric, an Ethernet network interface 316 that connects the MPEX to the Ethernet network, a computer-readable media drive 313, and various other I/O devices 314. An embodiment of an Incoming Ethernet Frame Processor component 340 and an embodiment of an Incoming Fibre Channel Frame Processor component 331 are executing in memory, as are an optional Node Load Determiner component 333 and an optional VI NIC component 335. While the Frame Processor components 331 and 340 in the illustrated embodiment include components executing in the main memory of the node, those skilled in the art will appreciate that other arrangements are possible in other embodiments, such as implementing a Frame Processor component together with a corresponding network interface on a single plug-in card that can be added to an MPEX, with the plug-in card providing stand-alone memory and/or various processing capabilities including hard-wired logic. [0049] In the illustrated embodiment, the Incoming Ethernet Frame Processor component contains various sub-components that include an Ethernet Frame Deconstructor 341, a Content Type Classifier 343, a Content Analyzer 345 with firewall capabilities, a Destination Selector 347 with load balancing capabilities, and a Fibre Channel Frame Constructor 349. In the illustrated embodiment, when one of the nodes 365 on the Ethernet network sends a communication that is received by the Ethernet network interface and is destined for one of the nodes 355 on the Interconnect Fabric network, the Incoming Ethernet Frame Processor is notified of the received data frame. In response, the Ethernet Frame Deconstructor deconstructs the received data frame to identify the payload of the data frame and various information in the data frame header. This deconstructed data frame information is then made available to the other sub-components 343-349. The Content Type Classifier, Content Analyzer, Destination Selector, and Fibre Channel Frame Constructor sub-components then process the deconstructed data frame information in various ways, either serially or in parallel. [0050] If the MPEX includes multiple CPUs, for example, each of the analysis techniques could be performed on a different CPU. One of or more of the sub-components may also use various accessible information in performing their analyses. For example, the Destination Selector component 347 in the illustrated embodiment determines the destination IP address specified in the incoming Ethernet data frame and determines if that IP address corresponds to multiple alternative destination nodes 355 able to receive and respond to the data frame. In the illustrated embodiment, a Load Balancing Table 321 is present on storage 320, and it maps specified destination IP addresses to multiple alternative destination IP addresses which can be used in place of the specified destination IP address. In some embodiments, the Load Balancing Table may also contain various load information for some or all of the nodes corresponding to the alternative destination IP addresses (e.g., response times or other indications of processing load), such as if the Node Load Determiner component obtains such load information for some or all of the nodes 355 (e.g., from the nodes or from the Network Manager) and stores that information in the Load Balancing Table. [0051] Those skilled in the art will appreciate that the Incoming Fibre Channel Frame Processor can in some embodiments have the same sub-components as does the Incoming Ethernet Frame Processor, and if so will process data frames received from nodes 355 in a corresponding manner. Alternatively, in other embodiments incoming data frames from the Fibre Channel Interconnect Fabric network may be processed in a distinct manner, such as if the data frames are deconstructed and translated to data frames using an alternative data link layer network protocol without performing additional analysis such as content type classification, content analysis, and/or load balancing. [0052] In addition, in some embodiments the MPEX includes an optional VI NIC component to assist in routing incoming Ethernet data frames to appropriate destination nodes 355 in an appropriate manner as previously discussed. If so, the VI NIC can register some or all of the incoming Ethernet data frames with the Network Manager, such as by supplying information about the selected destination IP address and/or or an indication of the type of date being communicated (e.g., from the content type classification), and can receive in response an appropriate transmittal virtual identifier to use to transmit the corresponding newly constructed Fibre Channel-based data frame to one or more appropriate destination nodes 355. The VI NIC may use Network Manager communication parameters 327 on storage to communicate with the Network Manager, and may store mappings from selected destination IP addresses (as well as destination application software port numbers) and/or data type information to corresponding virtual identifiers in the Virtual Identifier Translation [0053] Table 325 on storage, such as for use with additional received data frames that are part of the same or a similar data communication. [0054] Those skilled in the art will appreciate that MPEX 300 is merely illustrative and is not intended to limit the scope of the present invention. The MPEX may be connected to other devices that are not illustrated, including one or more additional networks (e.g., that are part of the Internet). In addition, the MPEX could be part of an EDN, such as by connecting a storage area network of the EDN to another part of the EDN. Those skilled in the art will also appreciate that the functionality provided by the illustrated Frame Processor components may in some embodiments be combined in fewer components or distributed in additional components. Similarly, in some embodiments, the functionality of some of the illustrated components may be not be provided and/or other additional functionality may be available, such as selecting destinations in a manner other than or in addition to load balancing. [0055] Those skilled in the art will also appreciate that, while various items are illustrated as being stored in memory while being used, those items or portions of them can be transferred between memory and other storage devices for purposes of memory management and data integrity. Similarly, items illustrated as being present on storage while being used can instead be present in memory and transferred between storage and memory. Some or all of the components and data structures may also be stored (e.g., as instructions or structured data) on a computer-readable medium, such as a hard drive, a memory, a network, or a portable article to be read by an appropriate drive. The components and data structures can also be transmitted as generated data signals (e.g., as part of a carrier wave on a variety of computer-readable transmission mediums, including wireless-based and wired/cable-based mediums). Accordingly, the present invention may be practiced with other computer system configurations. [0056] [0056]FIG. 3B is a block diagram illustrating an alternative embodiment of an Ethernet Frame Processor component 370 that includes various dedicated hardware to assist in the integrated multi-technique processing of a received Ethernet data frame. The illustrated Ethernet Frame Processor could be used in place of the software component 340 and the network interface 316 illustrated in FIG. 3A, such as by being implemented as a plug-in card that is part of the MPEX. In other embodiments, the Ethernet Frame Processor could act as a stand-alone device that provides protocol translation back-and-forth between Ethernet and another networking protocol and that optionally performs other types processing on received data frames encoded in one or both protocols. [0057] In the illustrated embodiment, the Ethernet Frame Processor 370 includes an Ethernet network interface 371 that can receive and transmit Ethernet frames. When an Ethernet frame is received, the Network Processor 372 receives the data frame from the network interface and deconstructs the data frame in a manner specific to the Ethernet protocol, such as by using specialized hardware components to provide accelerated deconstruction. The Network Processor then provides deconstructed data frame information to various processors 373-376 for analysis of the information. These processors may be general-purpose processors programmed in specific manners or may instead by hardware specialized for the various analysis tasks, and may perform their analysis techniques either in parallel or in a serial manner. [0058] In particular, the Content Classifier Processor 373 will classify the type of content of the deconstructed data frame, the Content Analyzer Processor 374 will analyze the content of the deconstructed data frame such as to provide firewall capabilities, the Load Balancer Processor component 375 will provide load balancing and/or other destination selection capabilities, and the Ethernet-To-Other Protocol Gateway Processor 376 will construct a data frame specific to a non-Ethernet data link layer network protocol that corresponds to the received Ethernet data frame. The Ethernet Frame Processor 370 also includes memory 379, which may be used by one or more of the processors 372-376 when performing their tasks. For example, the Load Balancer Processor 375 may store load balancing information in the memory. Alternatively, one or more of the processors 372-376 may communicate with external resources (e.g., memory or storage) in order to obtain necessary information. [0059] The Ethernet Frame Processor 370 additionally includes a network interface 378 that is specific to a data link layer network protocol other than Ethernet. For example, the network interface 378 may be a Fibre Channel network interface, and if so the Gateway Processor 376 would produce a Fibre Channel-based data frame for transmittal to a selected destination. Alternatively, the Ethernet Frame Processor could be one of multiple Frame Processors that interact, and the network interface 378 may correspond to an intermediate protocol common to all of the Frame Processors (e.g., PCI or InfiniBand). In such an embodiment, a new data frame could be constructed in that intermediate format, and could be forwarded to a different Frame Processor component that receives the data frame on a network interface for that intermediate format and converts the data frame to a non-Ethernet data link layer network protocol (e.g., Fibre Channel) before forwarding the converted data frame to a destination on a distinct network to which another network interface of that Frame Processor is connected. In such embodiments, each of the Frame Processors would have the capability to process data frames received over either of the network interfaces for that Frame Processor. [0060] Those skilled in the art will appreciate that the various sub-components of the Ethernet Frame Processor 370 can communicate in various ways, such as with a PCI or InfiniBand-based bus. Similarly, in other embodiments the illustrated Frame Processor could include additional functionality (e.g., Node Load Determination capabilities and/or VI NIC capabilities), and/or could be used as a stand-alone MPEX. [0061] [0061]FIG. 3C is a block diagram illustrating an alternative embodiment of an MPEX 380 that integrates multiple disparate data communication processing techniques. In particular, the illustrated embodiment of the MPEX contains multiple Frame Processors that are each specific to a data link layer network protocol for a network to which they are connected, and the Frame Processors each perform various types of processing techniques on incoming data frames and convert those data frames to a common intermediate format (which in the illustrated embodiment is InfiniBand). Each of the Frame Processors in the illustrated embodiment are blades that connect to an InfiniBand backplane 385, with each of the blade slots connecting to a corresponding InfiniBand port 392 on a multi-port InfiniBand switch 390. The switch will route each InfiniBand data communication received on an incoming InfiniBand port 392 to an appropriate outgoing InfiniBand port 392 that corresponds to a Frame Processor blade connected to a network to which the destination of the received data communication belongs. In the illustrated embodiment, the switch 390 additionally includes an Integrated Manager component 396 to perform various administrative and management functions, as well as one or more additional InfiniBand ports 394 for other external communications. [0062] [0062]FIG. 4 is a flow diagram of an embodiment of the Incoming Frame Processor routine 400. The routine receives indications of incoming data frames in one or more data link layer network protocols, deconstructs those frames to obtain payload and header information in a manner specific to the data link layer network protocol in which the data frames are encoded, analyzes the deconstructed data frame information in various ways, and creates and transmits a corresponding data frame encoded in a different data link layer network protocol for forwarding if appropriate. [0063] The routine begins with step 405 where an indication is received of an incoming data frame. The routine continues to step 410 to deconstruct the data frame to access information from the header and payload portions of the data frame. In step 415, the routine then determines whether to perform various analysis techniques in parallel or in serial, such as based on a dynamic indication for that received data frame or instead on a type of data link layer network protocol corresponding to some or all of the received data frames. [0064] If the processing is not to be performed in parallel, the routine continues to step 420 to perform processing to classify the type of content of the payload of the data frame. The routine then continues to step 425 to analyze the payload of the data frame for various types of required or prohibited content, and may in some embodiments use content type classification information from step 420 as part of the analysis. In some embodiments, if prohibited content is detected and/or required content is not present, the content analysis may remove, replace, or add such content. Alternatively, in other embodiments the presence or absence of such information may cause the content analysis techniques to indicate that the content has been rejected. If it is determined in step 430 that the content analysis techniques have indicated to reject the content, the routine continues to step 495, and if not continues to step 435. [0065] In step 435, the destination of the data frame is selected by performing load balancing techniques on the destination network address specified for the incoming data frame. In some embodiments, content type classification information from step 420 and/or content analysis information from step 425 may be used to assist in the destination selection process, such as to select a destination optimized for the specific content of the received data frame or based on information determined during the analysis of the content. In some embodiments, the destination selection techniques in step 435 may determine that no destination is currently appropriate to receive the data frame. If in step 440 it is so determined, the routine continues to step 495, and if not the routine continues to step 445 to create a new data frame that corresponds to the received data frame but that is specific to a new data link layer network protocol for the network to which the selected destination belongs. Information from some or all of the content type classification, content analysis, and destination selection processing may be used in the creation of the new data frame, such as to add a destination network address for a selected destination, specify a manner of transmittal of the new data frame based on a classified type of content or content analysis, or to modify the payload of the new data frame based on changes made by the content analysis processing. After step 445, the routine continues to step 450 to output the frame, such as to send the frame to a network interface for the network to which the destination belongs. In alternative embodiments, the frame may be output to other components for additional processing before transmittal, such as to a VI NIC. After step 450, the routine continues to step 495 to determine if there are more data frames to receive. If so, the routine returns to step 405, and if not the routine continues to step 499 and ends. [0066] If it was instead determined in step 415 to process the deconstructed data frame information in parallel, the routine continues to perform steps 455, 460, 465 and 470 in parallel, such as on distinct processors or as distinct processes on a multitasking system. After steps 455, 460, 465, and 470, the routine continues to step 475 to determine if any of the processing indicated to reject the transmittal of the created outgoing frame (e.g., based on the content analysis or the load balancing), and if so the routine continues to step 495. If the outgoing frame was not rejected, the routine instead continues to step 480 to combine any information from the processing in steps 455, 460 and 465 to the frame created in step 470 as appropriate. The routine then continues to step 485 to output the frame in a manner similar to that of step 450, and continues to step 495. [0067] Those skilled in the art will appreciate that in other embodiments some of the types of deconstructed data frame information processing may not be performed, or that instead additional types of processing may be performed either in parallel or in serial. In addition, those skilled in the art will appreciate that a mix of serial and parallel processing can be performed for some or all of the received data frames, such as to perform the content type classification first, to perform the content analysis and load balancing in parallel next, and to then create an appropriate outgoing frame in a manner similar to that indicated for step 480. In addition, in embodiments in which the processing is performed in a serial manner, those skilled in the art will appreciate that in other embodiments the processing may be performed in other orders, and that steps illustrated as being earlier in the routine in the illustrated embodiment (e.g., the content type classification) may use information provided by other analysis techniques shown in the illustrated embodiment as being processed later (e.g., content analysis). [0068] The processing of received data communications and the use of virtual identifiers as discussed above and in the previously cited U.S. patent applications also provides various other benefits. For example, the discussed techniques allow a communication model to be used in which data to be transmitted is identified in some embodiments by its type, which can be determined in various ways, and in which the transmission of the data can then be suited to that data type. For example, in some embodiments one or more destinations can be selected that are appropriate to that data type, such as by using one or more virtual identifiers that correspond to that data type. Similarly, in some embodiments one or more QOS parameters can be selected to be used during the data transmission that are appropriate to that data type. Moreover, the use of virtual identifiers allows the routing of the data using that virtual identifier to be reconfigured in a manner transparent to the source and destination (e.g., by modifying a path to which that virtual identifier corresponds), such as to maintain a QOS for that data type. Moreover, the registering of data to be transmitted, such as registrations that include the type of data, allow a network manager for the network to provide various monitoring and configuration services. Those skilled in the art will appreciate that these various techniques can be combined in any logical combination. [0069] The discussed techniques also allow a QOS model to be used in some embodiments so that various types of QOS guarantees can be provided, such as to bandwidth, latency, jitter, and/or availability. The use of configurable label tables by switches allows a network manager to control how many and which communications will pass through each link on each switch, and thus the network manager can ensure that sufficient bandwidth is available for a communication by limiting the other communications that use any of the same links. The network traffic can also be monitored so that allocations of communications to links can be adjusted as needed. This allows guaranteed bandwidth for virtual connections in which a dedicated physical connection is not used. In addition, hunt groups between switches can also be used to provide a minimum level of bandwidth by providing alternative paths for communications. The transmission priority assigned to data communications can be used to control how quickly those communications pass through intermediate routing devices, and thus can be used to control both latency and jitter. In addition, varying the COS assigned to data communications allows guarantees to be made as to delivery, and can also be used to affect latency and jitter if different COSes are given different priorities by intermediate routing devices. Finally, the management of paths assigned to virtual identifiers, both initially and during reconfiguration based on monitoring, allows guarantees to be made for various QOS parameters. Those skilled in the art will appreciate that these various techniques can be combined in any logical combination. [0070] The discussed techniques also allow a security model to be used in some embodiments to provide various types and levels of security. The use of virtual addressing restricts a node so that it is able to communicate only with those destination nodes for which the SPC's label table on the node's corresponding switch port has valid virtual address and to which that switch port will route communications. Moreover, the node may not even know actual physical addresses or even the identity of the destinations that correspond to the virtual addresses, and other nodes cannot make use of those virtual addresses to communicate with the same destinations unless the SPC label table on that other node's corresponding switch port has been configured in a like manner. In addition, for data communication registrations, a network manager can require that a node supply various types of authorization information (e.g., a password) supplied to that node earlier (e.g., during registration of the node or during manufacture of the node). In addition, the requirement for a node to register with the network manager before it can make any other communications allows the network manager to monitor and control data communications through the network, particularly in combination with data communication registrations. In addition, a VI NIC's and/or intermediate routing device's ability to verify that combinations of transmittal and response virtual identifiers are valid and to verify that specified QOS parameters are authorized for those virtual identifiers provides various security benefits. When integrated managers for intermediate routing devices inter-communicate (e.g., for remote management of that integrated manager or its corresponding switch), or for any other communication to an integrated manager, various password or other identity verification or authorization verification schemes can be used to ensure that received communications and commands are valid and authorized. Those skilled in the art will appreciate that these various techniques can be combined in any logical combination. [0071] Those skilled in the art will also appreciate that in some embodiments the functionality provided by the routines discussed above may be provided in alternative ways, such as being split among more routines or consolidated into less routines. Similarly, in some embodiments illustrated routines may provide more or less functionality than is described, such as when other illustrated routines instead lack or include such functionality respectively, or when the amount of functionality that is provided is altered. Those skilled in the art will also appreciate that the data structures discussed above may be structured in different manners, such as by having a single data structure split into multiple data structures or by having multiple data structures consolidated into a single data structure. Similarly, in some embodiments illustrated data structures may store more or less information than is described, such as when other illustrated data structures instead lack or include such information respectively, or when the amount or types of information that is stored is altered. [0072] From the foregoing it will be appreciated that, although specific embodiments have been described herein for purposes of illustration, various modifications may be made without deviating from the spirit and scope of the invention. Accordingly, the invention is not limited except as by the appended claims. In addition, while certain aspects of the invention are presented below in certain claim forms, the inventors contemplate the various aspects of the invention in any available claim form. For example, while only one some aspects of the invention may currently be recited as being embodied in a computer-readable medium, other aspects may likewise be so embodied. Accordingly, the inventors reserve the right to add additional claims after filing the application to pursue such additional claim forms for other aspects of the invention. Patent CitationsCited PatentFiling datePublication dateApplicantTitleUS4777695 *Dec 22, 1987Oct 18, 1988Nissan Motor Co., Ltd.Windshield wiper with means for adjusting force with which wiper blade is pressed against windshieldUS4872160 *Aug 30, 1988Oct 3, 1989American Telephone And Telegraph Company, At&T Bell LaboratoriesIntegrated packetized voice and data switching systemUS5247516 *Mar 28, 1991Sep 21, 1993Sprint International Communications Corp.Configurable composite data frameUS5303233 *May 20, 1991Apr 12, 1994Nec CorporationArrangement favorably carrying out a connection by the use of an intermediate conversion parameter between input and output virtual channel identifiers (VCI's)US5327426 *Sep 27, 1991Jul 5, 1994Echelon CorporationMethod and apparatus for preventing unnecessary retransmission of messages in a networked messaging systemUS5327552 *Jun 22, 1992Jul 5, 1994Bell Communications Research, Inc.Method and system for correcting routing errors due to packet deflectionsUS5339318 *Oct 22, 1992Aug 16, 1994Fujitsu LimitedVPI and VCI assignment system in ATM systemUS5343473 *Aug 7, 1992Aug 30, 1994International Business Machines CorporationMethod of determining whether to use preempt/resume or alternate protocol for data transmissionUS5412653 *Oct 15, 1993May 2, 1995International Business Machines CorporationDynamic switch cascading systemUS5432783 *Feb 7, 1994Jul 11, 1995Bell Communications Research, Inc.System and method for providing egress policing for broadband virtual private networksUS5440547 *Jan 5, 1994Aug 8, 1995Kabushiki Kaisha ToshibaData-transfer routing management for packet-oriented digital communication system including ATM networksUS5548639 *Oct 22, 1992Aug 20, 1996Fujitsu LimitedDistributed control of telecommunication network for setting up an alternative communication pathUS5550816 *Dec 29, 1994Aug 27, 1996Storage Technology CorporationMethod and apparatus for virtual switchingUS5675807 *Jun 7, 1995Oct 7, 1997Tandem Computers IncorporatedInterrupt message delivery identified by storage location of received interrupt dataUS5680402 *Oct 5, 1994Oct 21, 1997International Business Machines CorporationPriority broadcast and multi-cast for unbuffered multi-stage networksUS5734719 *Dec 10, 1996Mar 31, 1998International Business Systems, IncorporatedDigital information accessing, delivery and production systemUS5751932 *Jun 7, 1995May 12, 1998Tandem Computers IncorporatedFail-fast, fail-functional, fault-tolerant multiprocessor systemUS5751955 *Jun 7, 1995May 12, 1998Tandem Computers IncorporatedMethod of synchronizing a pair of central processor units for duplex, lock-step operation by copying data into a corresponding locations of another memoryUS5774067 *Oct 16, 1997Jun 30, 1998International Business Machines CorporationFlash-flooding multi-stage interconnection network with parallel path seeking switching elementsUS5790546 *Dec 4, 1995Aug 4, 1998Cabletron Systems, Inc.Method of transmitting data packets in a packet switched communications networkUS5790776 *Jun 7, 1995Aug 4, 1998Tandem Computers IncorporatedApparatus for detecting divergence between a pair of duplexed, synchronized processor elementsUS5805804 *Mar 12, 1997Sep 8, 1998Oracle CorporationMethod and apparatus for scalable, high bandwidth storage retrieval and transportation of multimedia data on a networkUS5809025 *Mar 15, 1996Sep 15, 1998Motorola, Inc.Virtual path-based static routingUS5818842 *Jan 20, 1995Oct 6, 1998Newbridge Networks CorporationTransparent interconnector of LANs by an ATM networkUS5867501 *Jun 7, 1995Feb 2, 1999Tandem Computers IncorporatedEncoding for communicating data and commandsUS5872783 *Jul 24, 1996Feb 16, 1999Cisco Systems, Inc.Arrangement for rendering forwarding decisions for packets transferred among network switchesUS5881246 *Jun 12, 1996Mar 9, 1999Bay Networks, Inc.System for generating explicit routing advertisements to specify a selected path through a connectionless network to a destination by a specific routerUS5892766 *Feb 22, 1996Apr 6, 1999Fujitsu, Ltd.Method and apparatus for coordinating access to an output of a routing device in a packet switching networkUS5892923 *Dec 28, 1995Apr 6, 1999Hitachi, Ltd.Parallel computer system using properties of messages to route them through an interconnect network and to select virtual channel circuits therewithinUS5898830 *Oct 17, 1996Apr 27, 1999Network Engineering SoftwareFirewall providing enhanced network security and user transparencyUS5914953 *Jun 7, 1995Jun 22, 1999Tandem Computers, Inc.Network message routing using routing table information and supplemental enable information for deadlock preventionUS5917820 *Jun 10, 1996Jun 29, 1999Cisco Technology, Inc.Efficient packet forwarding arrangement for routing packets in an internetworkUS5940596 *Aug 4, 1997Aug 17, 1999I-Cube, Inc.Clustered address caching system for a network switchUS5943339 *Mar 21, 1996Aug 24, 1999Northern Telecom LimitedDigital communications systemUS5953338 *Dec 13, 1996Sep 14, 1999Northern Telecom LimitedDynamic control processes and systems for asynchronous transfer mode networksUS5964835 *Jun 7, 1995Oct 12, 1999Tandem Computers IncorporatedStorage access validation to data messages using partial storage address data indexed entries containing permissible address range validation for message sourceUS6021263 *Feb 16, 1996Feb 1, 2000Lucent Technologies, Inc.Management of ATM virtual circuits with resources reservation protocolUS6021495 *May 30, 1997Feb 1, 20003Com CorporationMethod and apparatus for authentication process of a star or hub network connection ports by detecting interruption in link beatUS6028863 *Mar 4, 1997Feb 22, 2000Fujitsu LimitedMethod and apparatus for negotiating connection identifierUS6032205 *Mar 6, 1998Feb 29, 2000Hitachi, Ltd.Crossbar switch system for always transferring normal messages and selectively transferring broadcast messages from input buffer to output buffer when it has sufficient space respectivelyUS6034956 *Jun 29, 1998Mar 7, 2000International Business Machines CorporationMethod of simultaneously attempting parallel path connections in a multi-stage interconnection networkUS6041049 *May 6, 1997Mar 21, 2000International Business Machines CorporationMethod and apparatus for determining a routing table for each node in a distributed nodal systemUS6047323 *Jun 27, 1996Apr 4, 2000Hewlett-Packard CompanyCreation and migration of distributed streams in clusters of networked computersUS6078963 *Jan 16, 1998Jun 20, 2000At&T Corp.Router with de-centralized processing using intelligent portsUS6085238 *Apr 22, 1997Jul 4, 2000Matsushita Electric Works, Ltd.Virtual LAN systemUS6094712 *Dec 4, 1996Jul 25, 2000Giganet, Inc.Computer network interface for direct mapping of data transferred between applications on different host computers from virtual addresses to physical memory addresses application dataUS6104700 *Feb 3, 1998Aug 15, 2000Extreme NetworksPolicy based quality of serviceUS6108708 *May 21, 1997Aug 22, 2000Nec CorporationConnection-oriented network using distributed network resources and predetermined VPIs for fast VC establishmentUS6169742 *Dec 18, 1997Jan 2, 2001Advanced Micro Devices, Inc.Multiport data network switch having direct media access control link to external managementUS6172991 *Feb 17, 1998Jan 9, 2001Nec CorporationATM Network with a filtering table for securing communicationUS6195335 *Jul 6, 1998Feb 27, 2001International Business Machines CorporationData switchUS6215412 *Jun 2, 1995Apr 10, 2001International Business Machines CorporationAll-node switch-an unclocked, unbuffered, asynchronous switching apparatusUS6216173 *Feb 3, 1998Apr 10, 2001Redbox Technologies LimitedMethod and apparatus for content processing and routingUS6216200 *Mar 14, 1995Apr 10, 2001Mips Technologies, Inc.Address queueUS6219706 *Oct 16, 1998Apr 17, 2001Cisco Technology, Inc.Access control for networksUS6262976 *Sep 17, 1999Jul 17, 2001Ordered Networks, Inc.System and method for network flow optimization using traffic classesUS6275491 *May 28, 1998Aug 14, 2001Texas Instruments IncorporatedProgrammable architecture fast packet switchUS6278714 *Feb 6, 1998Aug 21, 2001Sun Microsystems, Inc.Efficient hardware implementation of virtual circuit bunchingUS6292488 *May 22, 1998Sep 18, 2001Compaq Computer CorporationMethod and apparatus for resolving deadlocks in a distributed computer systemUS6292839 *Dec 9, 1998Sep 18, 20013Com CorporationMethod and system for reflexive tunnelingUS6301252 *Apr 16, 1998Oct 9, 2001Mantra Communications IncorporatedControl and management of ATM networks from server computersUS6304549 *May 8, 1997Oct 16, 2001Lucent Technologies Inc.Virtual path management in hierarchical ATM networksUS6381242 *Aug 29, 2000Apr 30, 2002Netrake CorporationContent processorUS6381244 *Mar 17, 1998Apr 30, 2002Fujitsu LimitedConnectionless communication methodUS6385197 *Jul 9, 1999May 7, 2002Allied Telesyn International Corp.Virtual port trunking method and apparatusUS6396815 *Aug 28, 2000May 28, 2002Virata LimitedProxy-controlled ATM subnetworkUS6400730 *Feb 8, 2000Jun 4, 2002Nishan Systems, Inc.Method and apparatus for transferring data between IP network devices and SCSI and fibre channel devices over an IP networkUS6411806 *Jul 6, 2000Jun 25, 2002Mobile Satellite Ventures LpVirtual network configuration and management system for satellite communications systemUS6430626 *Aug 1, 2000Aug 6, 2002Compaq Computer CorporationNetwork switch with a multiple bus structure and a bridge interface for transferring network data between different busesUS6510151 *Sep 19, 1996Jan 21, 2003Enterasys Networks, Inc.Packet filtering in connection-based switching networksUS6535518 *Aug 3, 2000Mar 18, 2003Simpletech Inc.System for bypassing a server to achieve higher throughput between data network and data storage systemUS6542739 *Oct 6, 2000Apr 1, 2003Mobile Satellite Ventures, LpPriority and preemption service system for satellite related communication using central controllerUS6558547 *Apr 21, 1999May 6, 2003Otkrytoe Aktsionernoe Obschestvo “Nauchno-Issledovatelsky Institut Plasticheskikh Mass Im. G. S. Petrova”Material for introducing physiologically essential inorganic elements into drinkable waterUS6563831 *Aug 19, 1998May 13, 2003Avici SystemsRouter with virtual channel allocationUS6597691 *Aug 30, 1999Jul 22, 2003Ancor Communications, Inc.High performance switchingUS6608819 *Nov 30, 2000Aug 19, 2003Mcdata CorporationMethod for scoring queued frames for selective transmission through a switchUS6614758 *Jan 10, 2002Sep 2, 2003Broadcom CorpLoad balancing in link aggregation and trunkingUS6697379 *May 17, 1999Feb 24, 2004Inria Institut National De Recherche En Informatique Et En AutomatiqueSystem for transmitting messages to improved stations, and corresponding processingUS6707800 *Oct 1, 1998Mar 16, 2004Hughes Electronics CorporationATM network with central call processorUS6760775 *Mar 6, 2000Jul 6, 2004At&T Corp.System, method and apparatus for network service load and reliability managementUS6771673 *Aug 31, 2000Aug 3, 2004Verizon Communications Inc.Methods and apparatus and data structures for providing access to an edge router of a networkUS6847613 *Mar 12, 2001Jan 25, 2005Hitachi, Ltd.Method of monitoring quality of communication for each flowUS6895006 *Oct 2, 2000May 17, 2005Juniper Networks, Inc.Unicast/multicast systemUS6914911 *Jan 17, 2001Jul 5, 2005Telefonaktiebolaget Lm EricssonCombining narrowband applications with broadband transportUS6917614 *Sep 17, 1999Jul 12, 2005Arris International, Inc.Multi-channel support for virtual private networks in a packet to ATM cell cable systemUS6938169 *Dec 10, 1999Aug 30, 2005Sun Microsystems, Inc.Channel-specific file system views in a private network using a public-network infrastructureUS6944152 *Aug 22, 2000Sep 13, 2005Lsi Logic CorporationData storage access through switched fabricUS20010010692 *Jul 24, 1997Aug 2, 2001Juniper NetworksMemory organization in a switching deviceUS20010030968 *Jan 17, 2001Oct 18, 2001Magnus HallenstalCombining narrowband applications with broadband transportUS20020028656 *Feb 1, 2001Mar 7, 2002Yechiam YeminiMethod and apparatus for providing forwarding and replication services on a dynamically addressed networkUS20020029287 *Feb 1, 2001Mar 7, 2002Yechiam YeminiMethod and apparatus for dynamically addressing a circuits based networkUS20020031131 *Feb 1, 2001Mar 14, 2002Yechiam YeminiMethod and apparatus for the exchange of data between a dynamically addressed network and a foreign networkUS20020049778 *Mar 29, 2001Apr 25, 2002Bell Peter W.System and method of information outsourcingUS20020154635 *Apr 23, 2001Oct 24, 2002Sun Microsystems, Inc.System and method for extending private networks onto public infrastructure using supernetsUS20020159389 *Oct 26, 2001Oct 31, 2002Foster Michael S.Method and system for connection preemption in a communications networkUS20020159437 *Oct 26, 2001Oct 31, 2002Foster Michael S.Method and system for network configuration discovery in a network managerUS20020159446 *Oct 26, 2001Oct 31, 2002Foster Michael S.Method and system for interswitch load balancing in a communications networkUS20030014544 *Feb 15, 2001Jan 16, 2003BanderacomInfiniband TM work queue to TCP/IP translationUS20040004966 *Oct 26, 2001Jan 8, 2004Foster Michael S.Using virtual identifiers to route transmitted data through a network* Cited by examinerReferenced byCiting PatentFiling datePublication dateApplicantTitleUS6941384Aug 17, 2000Sep 6, 2005International Business Machines CorporationMethods, systems and computer program products for failure recovery for routed virtual internet protocol addressesUS6954784 *Mar 4, 2002Oct 11, 2005International Business Machines CorporationSystems, method and computer program products for cluster workload distribution without preconfigured port identification by utilizing a port of multiple ports associated with a single IP addressUS6963917Oct 20, 2000Nov 8, 2005International Business Machines CorporationMethods, systems and computer program products for policy based distribution of workload to subsets of potential serversUS6965930Oct 20, 2000Nov 15, 2005International Business Machines CorporationMethods, systems and computer program products for workload distribution based on end-to-end quality of serviceUS6996058Oct 26, 2001Feb 7, 2006The Boeing CompanyMethod and system for interswitch load balancing in a communications networkUS6996617Aug 17, 2000Feb 7, 2006International Business Machines CorporationMethods, systems and computer program products for non-disruptively transferring a virtual internet protocol address between communication protocol stacksUS6996631Aug 17, 2000Feb 7, 2006International Business Machines CorporationSystem having a single IP address associated with communication protocol stacks in a cluster of processing systemsUS7120697May 22, 2001Oct 10, 2006International Business Machines CorporationMethods, systems and computer program products for port assignments of multiple application instances using the same source IP addressUS7237045 *Oct 28, 2003Jun 26, 2007Brocade Communications Systems, Inc.Apparatus and method for storage processing through scalable port processorsUS7283538 *Oct 12, 2001Oct 16, 2007Vormetric, Inc.Load balanced scalable network gateway processor architectureUS7430611Jan 28, 2005Sep 30, 2008International Business Machines CorporationSystem having a single IP address associated with communication protocol stacks in a cluster of processing systemsUS7474666Sep 3, 2003Jan 6, 2009Cisco Technology, Inc.Switch port analyzersUS7475141 *Jul 31, 2001Jan 6, 2009Arbor Networks, Inc.Distributed service level management for network trafficUS7590715 *Mar 3, 2004Sep 15, 2009Emc CorporationMethod and system for automatic classification of applications and services by packet inspectionUS7673074 *Apr 22, 2003Mar 2, 2010Emulex Design & Manufacturing CorporationAvoiding port collisions in hardware-accelerated network protocolUS7711831May 22, 2001May 4, 2010International Business Machines CorporationMethods, systems and computer program products for source address selectionUS7782784 *Apr 7, 2003Aug 24, 2010Cisco Technology, Inc.Port analyzer adapterUS7801125Jun 14, 2005Sep 21, 2010Cisco Technology, Inc.Forwarding table reduction and multipath network forwardingUS7830793Mar 30, 2005Nov 9, 2010Cisco Technology, Inc.Network device architecture for consolidating input/output and reducing latencyUS7843967 *Nov 30, 2007Nov 30, 2010Telefonaktiebolaget L M Ericsson (Publ)Multiple protocol cross layer customized QoS propagation and mappingUS7899048Jan 15, 2003Mar 1, 2011Cisco Technology, Inc.Method and apparatus for remotely monitoring network traffic through a generic networkUS7957280 *Jun 18, 2007Jun 7, 2011Bittorrent, Inc.Classification and verification of static file transfer protocolsUS7961621Oct 11, 2005Jun 14, 2011Cisco Technology, Inc.Methods and devices for backward congestion notificationUS7969971Mar 18, 2005Jun 28, 2011Cisco Technology, Inc.Ethernet extension for the data centerUS8108454Dec 17, 2008Jan 31, 2012Brocade Communications Systems, Inc.Address assignment in Fibre Channel over Ethernet environmentsUS8121038Aug 21, 2007Feb 21, 2012Cisco Technology, Inc.Backward congestion notificationUS8149710Jul 5, 2007Apr 3, 2012Cisco Technology, Inc.Flexible and hierarchical dynamic buffer allocationUS8160094Jun 16, 2009Apr 17, 2012Cisco Technology, Inc.Fibre channel over ethernetUS8165136Apr 25, 2005Apr 24, 2012Cisco Technology, Inc.Virtual port based SPANUS8170025Nov 26, 2008May 1, 2012Cisco Technology, Inc.Switch port analyzersUS8200871May 13, 2010Jun 12, 2012Brocade Communications Systems, Inc.Systems and methods for scalable distributed storage processingUS8238347Apr 6, 2006Aug 7, 2012Cisco Technology, Inc.Fibre channel over ethernetUS8259720Feb 2, 2007Sep 4, 2012Cisco Technology, Inc.Triple-tier anycast addressingUS8532099Sep 17, 2010Sep 10, 2013Cisco Technology, Inc.Forwarding table reduction and multipath network forwardingUS8565231May 20, 2011Oct 22, 2013Cisco Technology, Inc.Ethernet extension for the data centerUS8583780Nov 17, 2008Nov 12, 2013Brocade Communications Systems, Inc.Discovery of duplicate address in a network by reviewing discovery frames received at a portUS8635353 *Jul 13, 2012Jan 21, 2014Solarflare Communications, Inc.Reception according to a data transfer protocol of data directed to any of a plurality of destination entitiesUS8645558Jun 15, 2006Feb 4, 2014Solarflare Communications, Inc.Reception according to a data transfer protocol of data directed to any of a plurality of destination entities for data extractionUS8700778Sep 2, 2010Apr 15, 2014Cisco Technology, Inc.Provisioning and redundancy for RFID middleware serversUS8743738Aug 13, 2012Jun 3, 2014Cisco Technology, Inc.Triple-tier anycast addressingUS8755283Dec 17, 2010Jun 17, 2014Microsoft CorporationSynchronizing state among load balancer componentsUS8792352May 5, 2011Jul 29, 2014Cisco Technology, Inc.Methods and devices for backward congestion notificationUS8804529Jan 24, 2012Aug 12, 2014Cisco Technology, Inc.Backward congestion notificationUS8805990 *Jul 12, 2012Aug 12, 2014Microsoft CorporationLoad balancing for single-address tenantsUS8811214Apr 9, 2012Aug 19, 2014Cisco Technology, Inc.Virtual port based spanUS8842694Apr 11, 2012Sep 23, 2014Cisco Technology, Inc.Fibre Channel over EthernetUS8843598 *Dec 27, 2007Sep 23, 2014Cisco Technology, Inc.Network based device for providing RFID middleware functionalityUS8848575Feb 23, 2009Sep 30, 2014Brocade Communications Systems, Inc.High availability and multipathing for fibre channel over ethernetUS8938773 *Jan 30, 2008Jan 20, 2015Websense, Inc.System and method for adding context to prevent data leakage over a computer networkUS8959634Mar 22, 2013Feb 17, 2015Websense, Inc.Method and system for protection against information stealing softwareUS8977660 *Feb 22, 2012Mar 10, 2015Emc CorporationMulti-level distributed hash table for data storage in a hierarchically arranged networkUS8982887 *May 18, 2007Mar 17, 2015International Business Machines CorporationSystem, method and program for making routing decisionsUS9015842Mar 19, 2008Apr 21, 2015Websense, Inc.Method and system for protection against information stealing softwareUS9043380Jul 13, 2012May 26, 2015Solarflare Communications, Inc.Reception according to a data transfer protocol of data directed to any of a plurality of destination entitiesUS9092271Aug 5, 2014Jul 28, 2015Microsoft Technology Licensing, LlcLoad balancing for single-address tenantsUS9130972May 24, 2010Sep 8, 2015Websense, Inc.Systems and methods for efficient detection of fingerprinted data and informationUS9130986Mar 19, 2008Sep 8, 2015Websense, Inc.Method and system for protection against information stealing softwareUS9191426 *Apr 1, 2014Nov 17, 2015Inequest Technologies, Inc.System and method for analyzing the performance of multiple transportation streams of streaming media in packet-based networksUS9225681 *Sep 17, 2013Dec 29, 2015Cisco Technology, Inc.Enabling mobile applications to acquire a MAC address for obtaining location informationUS9241259Nov 30, 2012Jan 19, 2016Websense, Inc.Method and apparatus for managing the transfer of sensitive information to mobile devicesUS9246834Sep 15, 2014Jan 26, 2016Cisco Technology, Inc.Fibre channel over ethernetUS9288141May 17, 2013Mar 15, 2016Benu Networks, Inc.Highly scalable modular system with high reliability and low latencyUS9438520Nov 18, 2014Sep 6, 2016Microsoft Technology Licensing, LlcSynchronizing state among load balancer componentsUS9455981Sep 4, 2015Sep 27, 2016Forcepoint, LLCMethod and system for protection against information stealing softwareUS9495539Apr 16, 2015Nov 15, 2016Websense, LlcMethod and system for protection against information stealing softwareUS9509786Oct 8, 2015Nov 29, 2016Cisco Technology, Inc.Enabling mobile applications to acquire a MAC address for obtaining location informationUS9544364Feb 19, 2016Jan 10, 2017A10 Networks, Inc.Forwarding policies on a virtual service networkUS20020124089 *Mar 4, 2002Sep 5, 2002Aiken John AndrewMethods, systems and computer program products for cluster workload distribution without preconfigured port identificationUS20020159446 *Oct 26, 2001Oct 31, 2002Foster Michael S.Method and system for interswitch load balancing in a communications networkUS20020159458 *Oct 26, 2001Oct 31, 2002Foster Michael S.Method and system for reserved addressing in a communications networkUS20020178265 *May 22, 2001Nov 28, 2002Aiken John AndrewMethods systems and computer program products for source address selectionUS20020178268 *May 22, 2001Nov 28, 2002Aiken John AndrewMethods, systems and computer program products for port assignments of multiple application instances using the same source IP addressUS20030074388 *Oct 12, 2001Apr 17, 2003Duc PhamLoad balanced scalable network gateway processor architectureUS20040143638 *Oct 28, 2003Jul 22, 2004Beckmann Curt E.Apparatus and method for storage processing through scalable port processorsUS20040153854 *Apr 7, 2003Aug 5, 2004Andiamo Systems, Inc.Port analyzer adapterUS20040160899 *Jul 28, 2003Aug 19, 2004W-Channel Inc.Device for observing network packetsUS20050053073 *Sep 3, 2003Mar 10, 2005Andiamo Systems, Inc. A Delaware CorporationSwitch port analyzersUS20050141506 *Jan 28, 2005Jun 30, 2005Aiken John A.Jr.Methods, systems and computer program products for cluster workload distributionUS20050220090 *Mar 31, 2004Oct 6, 2005Kevin LoughranRouting architectureUS20060098589 *Jun 14, 2005May 11, 2006Cisco Technology, Inc.Forwarding table reduction and multipath network forwardingUS20060171311 *Feb 3, 2005Aug 3, 2006Cisco Technology, Inc.Method and system for classifying packetsUS20060271698 *May 16, 2006Nov 30, 2006Shrader Anthony GBoa back office integration protocolUS20070147231 *Mar 24, 2006Jun 28, 2007Fujitsu LimitedPath protection method and layer-2 switchUS20070297417 *Jun 18, 2007Dec 27, 2007Bram CohenClassification and Verification of Static File Transfer ProtocolsUS20080104209 *Dec 27, 2007May 1, 2008Cisco Technology, Inc.Network based device for providing rfid middleware functionalityUS20080159277 *Dec 17, 2007Jul 3, 2008Brocade Communications Systems, Inc.Ethernet over fibre channelUS20080181243 *Dec 17, 2007Jul 31, 2008Brocade Communications Systems, Inc.Ethernet forwarding in high performance fabricsUS20080259797 *Apr 18, 2007Oct 23, 2008Aladdin Knowledge Systems Ltd.Load-Balancing Bridge Cluster For Network NodesUS20080285560 *May 18, 2007Nov 20, 2008International Business Machines CorporationSystem, method and program for making routing decisionsUS20080307489 *Jan 30, 2008Dec 11, 2008Websense, Inc.System and method for adding context to prevent data leakage over a computer networkUS20090103518 *Oct 18, 2007Apr 23, 2009Motorola, Inc.Call origination by an application server in an internet protogol multimedia core network subsystemUS20090132701 *Nov 17, 2008May 21, 2009Robert SnivelyDuplicate address discovery and actionUS20090141740 *Nov 30, 2007Jun 4, 2009Pritam BaruahMULTIPLE PROTOCOL CROSS LAYER CUSTOMIZED QoS PROPAGATION AND MAPPINGUS20090292813 *Dec 17, 2008Nov 26, 2009Brocade Communications Systems, Inc.Address Assignment in Fibre Channel Over Ethernet EnvironmentsUS20090296726 *Jun 3, 2009Dec 3, 2009Brocade Communications Systems, Inc.ACCESS CONTROL LIST MANAGEMENT IN AN FCoE ENVIRONMENTUS20100214950 *Feb 23, 2009Aug 26, 2010Brocade Communications Systems, Inc.High availability and multipathing for fibre channel over ethernetUS20100318700 *May 13, 2010Dec 16, 2010Brocade Communications Systems, Inc.Systems and methods for scalable distributed storage processingUS20120296998 *Jul 13, 2012Nov 22, 2012Solarflare Communications, Inc.Reception according to a data transfer protocol of data directed to any of a plurality of destination entitiesUS20120331479 *Sep 4, 2012Dec 27, 2012Fujitsu LimitedLoad balancing device for biometric authentication systemUS20130308439 *May 17, 2013Nov 21, 2013Benu Networks, Inc.Highly scalable modular system with high reliability and low latencyUS20140215026 *Apr 1, 2014Jul 31, 2014Ineoquest Technologies, Inc.System and method for analyzing the performance of multiple transportation streams of streaming media in packet-based networksUS20150078402 *Sep 17, 2013Mar 19, 2015Cisco Technology, Inc.Enabling Mobile Applications to Acquire a MAC Address for Obtaining Location InformationEP1810455A2 *Oct 17, 2005Jul 25, 2007Cisco Technology, Inc.Fibre channel over ethernetEP1810455A4 *Oct 17, 2005Aug 19, 2009Cisco Tech IncFibre channel over ethernetWO2007147170A2 *Jun 18, 2007Dec 21, 2007Bittorrent, Inc.Classification and verification of static file transfer protocolsWO2007147170A3 *Jun 18, 2007Jan 24, 2008Bittorrent IncClassification and verification of static file transfer protocols* Cited by examinerClassifications U.S. Classification370/469International ClassificationH04L12/56, G06F15/173, G06F11/30, H04L12/28, H04L12/50, H04J1/16, G06F15/16, H04J3/16Cooperative ClassificationH04L67/322, H04L67/1002, H04L67/1029, H04L67/1014, H04L67/1031, H04L67/1008, H04L69/22, H04L69/08, H04L63/0236, H04L49/101, H04L49/552, H04L49/357, H04L63/0245European ClassificationH04L29/08N9A9, H04L29/08N9A7, H04L29/08N9A1E, H04L29/08N9A1B, H04L49/55A, H04L49/35H2, H04L29/08N9A, H04L29/06E, H04L29/08N31QLegal EventsDateCodeEventDescriptionOct 26, 2001ASAssignmentOwner name: BOEING COMPANY, THE, WASHINGTONFree format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNORS:FOSTER, MICHAEL S.;DORSETT, MICHAEL A.;REEL/FRAME:012578/0378Effective date: 20011025Nov 9, 2009FPAYFee paymentYear of fee payment: 4Nov 12, 2013FPAYFee paymentYear of fee payment: 8RotateOriginal ImageGoogle Home - Sitemap - USPTO Bulk Downloads - Privacy Policy - Terms of Service - About Google Patents - Send FeedbackData provided by IFI CLAIMS Patent Services