|Número de publicación||US20020016856 A1|
|Tipo de publicación||Solicitud|
|Número de solicitud||US 09/861,013|
|Fecha de publicación||7 Feb 2002|
|Fecha de presentación||18 May 2001|
|Fecha de prioridad||24 May 2000|
|También publicado como||CN1278524C, CN1359217A, EP1158724A2, EP1158724A3, EP1158726A2, EP1158726A3, EP1158727A2, EP1158727A3, EP1158728A2, EP1158728A3, EP1158730A2, EP1158730A3, US7075926, US7693149, US20010046229, US20010053150, US20020085560, US20060251069|
|Número de publicación||09861013, 861013, US 2002/0016856 A1, US 2002/016856 A1, US 20020016856 A1, US 20020016856A1, US 2002016856 A1, US 2002016856A1, US-A1-20020016856, US-A1-2002016856, US2002/0016856A1, US2002/016856A1, US20020016856 A1, US20020016856A1, US2002016856 A1, US2002016856A1|
|Inventores||Mathieu Tallegas, David Clear, Timothy Michels, Greg Davis|
|Cesionario original||Mathieu Tallegas, David Clear, Michels Timothy S., Davis Greg W.|
|Exportar cita||BiBTeX, EndNote, RefMan|
|Citas de patentes (4), Citada por (36), Clasificaciones (54), Eventos legales (1)|
|Enlaces externos: USPTO, Cesión de USPTO, Espacenet|
 The present application claims the priority of U.S. Provisional Application No. 60/206,996 entitled “Flow Resolution Logic System and Method” filed May 24, 2000, U.S. Provisional Application No. 60/206,617 entitled “System and Method for Enhanced Line Cards” filed May 24, 2000, and U.S. Provisional Application No. 60/220,335 entitled “Programmable Packet Processor” filed Jul. 24, 2000, the contents of all of which are fully incorporated by reference herein. The present application contains subject matter related to the subject matter disclosed in U.S. patent application Ser. No. 09/751,194 entitled “Programmable Packet Processor with Flow Resolution Logic” filed Dec. 28, 2000, the contents of which are fully incorporated by reference herein.
 The present application is related to packet switching, and particularly to a method and apparatus for providing dynamic application port service provisioning for a packet switch.
 There is an increasing desire to tailor packet switched networks to the individualized needs of customers. Two areas of customization of packet switched networks to meet individualized needs are application-level Quality of Service (QoS) and billing. In order to provide application-level QoS and billing in packet switched networks, packet switching nodes in the network should be able to determine the application to which each packet relates and provide QoS and billing for the packet in accordance with the application.
 Applications are determinable by reference to a TCP/UDP application port number in each packet. When a conversation occurs between a host and a server, packets originating from the host will apply the application port number to a destination port field, whereas packets originating from the server will apply the application port number to a source port field. These application port numbers may either be standardized port numbers that have been statically assigned to applications by the IETF or non-standard port numbers that are dynamically negotiated between the host and the server on a per session basis. Packet switching nodes can be statically configured to provide customized application-level QoS and billing for sessions utilizing standardized application port numbers. However, for sessions utilizing non-standard application port numbers that are dynamically negotiated, the application to which the session relates must be resolved in order to provide application-level QoS and billing for packets within the session.
 The process of dynamically negotiating application port numbers is often complex. Different dynamic application port numbers are assigned each session and assignment is often based on random components. Additionally, each application typically employs a different negotiating technique. For some applications, the negotiation spans multiple packets so that “state” must be monitored in the packet switching node in order to correctly determine the application port number resulting from the negotiation.
 There is therefore a need for a packet switching node that can efficiently and non-intrusively provide application-level QoS and billing for sessions employing dynamically negotiated application port numbers.
 In one embodiment of the present invention, a packet switching node for receiving and transmitting packets is provided. The packet switching node receives and transmits packets for one or more sessions. The packet switching node comprises an inspection engine, and first and second forwarding engines. The inspection engine is used to determine an application port by monitoring a first session in which the application port is negotiated. The first and second forwarding engines are interconnected on a first path dependent on the inspection engine and a second path independent of the inspection engine. The first forwarding engine identifies the first session, and directs the first session to the first path.
 In another embodiment of the present invention, a method of assigning an application port to one or more sessions is provided. A first forwarding engine receives a plurality of packets for the sessions, and identifies a first session in which the application port is to be negotiated. The first session is directed to an inspection engine. The inspection engine determines the application port for a second session by monitoring the application port negotiation.
 These and other aspects of the invention may be understood by reference to the following detailed description, taken in conjunction with the accompanying drawings, which are briefly described below.
FIG. 1 illustrates a network environment including a packet switching node in which one embodiment of the present invention may be used;
FIG. 2 is a block diagram of a switching interface in an embodiment according to the present invention;
FIG. 3 is a block diagram of a programmable packet switching controller in an embodiment according to the present invention;
FIG. 4 is a block diagram of a packet switching node in an embodiment according to the present invention coupled to a host and a server; and
FIG. 5 is a flow diagram of dynamic application port service provisioning in an embodiment according to the present invention.
 I. Overview
 In FIG. 1, network environment including a packet switching node 10 is illustrated. The packet switching node may also be referred to as a switch, a data communication node or a data communication switch. The packet switching node 10 includes switching interfaces 14, 16 and 18 interconnected to respective groups of LANs 30, 32, 34, and interconnected to one another over data paths 20, 22, 24 via switching backplane 12. The switching backplane 12 preferably includes switching fabric. The switching interfaces may also be coupled to one another over control paths 26 and 28.
 The switching interfaces 14, 16, 18 preferably forward packets to and from their respective groups of LANs 30, 32, 34 in accordance with one or more operative communication protocols, such as, for example, media access control (MAC) bridging and Internet Protocol (IP) routing. The switching node 10 is shown for illustrative purposes only. In practice, packet switching nodes may include more or less than three switching interfaces. Further, the packet switching nodes may also interface with computer networks other than LANs, such as, for example, WANs (Wide Area Networks) and MANs (Metropolitan Area Networks).
FIG. 2 is a block diagram of a switching interface 50 in an embodiment according to the present invention. The switching interface 50 may be similar, for example, to the switching interfaces 14, 16, 18 of FIG. 1. The switching interface 50 includes an access controller 54 coupled between LANs and a packet switching controller 52. The access controller 54, which may, for example, include a media access controller (MAC), preferably receives inbound packets off LANs, performs flow-independent physical and MAC layer operations on the inbound packets and transmits the inbound packets to the packet switching controller 52 for flow-dependent processing. The access controller 54 preferably also receives outbound packets from the packet switching controller 52 and transmits the packets on LANs. The access controller 54 may also perform physical and MAC layer operations on the outbound packets prior to transmitting them on LANs.
 The packet switching controller 52 preferably is programmable for handling packets having wide variety of communications protocols. The packet switching controller 52 preferably receives inbound packets, classifies the packets, modifies the packets in accordance with flow information and transmits the modified packets on switching backplane, such as the switching backplane 12 of FIG. 1. The packet switching controller 52 preferably also receives packets modified by other packet switching controllers via the switching backplane and transmits them to the access controller 54 for forwarding on LANs. The packet switching controller 52 may also subject selected ones of the packets to egress processing prior to transmitting them to the access controller 54 for forwarding on LANs.
FIG. 3 is a block diagram of a programmable packet switching controller 60 in an embodiment according to the present invention. The programmable packet switching controller 60, for example, may be similar to the packet switching controller 52 of FIG. 2. The programmable packet switching controller 60 preferably has flow resolution logic for classifying and routing incoming flows of packets. Due to its programmable nature, the programmable packet switching controller preferably provides flexibility in handling many different protocols and/or field upgradeability. The programmable packet switching controller may also be referred to as a packet switching controller, a switching controller, a programmable packet processor, a network processor, a communications processor or as another designation commonly used by those skilled in the art.
 The programmable packet switching controller 60 includes a packet buffer 62, a packet classification engine 64, an application engine 66 and a policing engine 80. Packet switching controllers in other embodiments may include more or less components. For example, a packet switching controller in another embodiment may include a pattern match module for comparing packet portions against a predetermined pattern to look for a match. The packet switching controller in yet another embodiment may include an edit module for editing inbound packets to generate outbound packets. The packet switching controller in still other embodiments may contain more than one of one or more of the packet buffer, the packet classification engine, the application engine, the policing engine, and/or other components for array switching, in which packets are processed in multiple processing paths.
 The programmable packet switching controller 60 preferably receives inbound packets 68. The packets may include, but are not limited to, Ethernet frames, ATM cells, TCP/IP and/or UDP/IP packets, and may also include other Layer 2 (Data Link/MAC Layer), Layer 3 (Network Layer) or Layer 4 (Transport Layer) data units. For example, the packet buffer 62 may receive inbound packets from one or more Media Access Control (MAC) Layer interfaces over the Ethernet.
 The received packets preferably are stored in the packet buffer 62. The packet buffer 62 may include a packet FIFO for receiving and temporarily storing the packets. The packet buffer 62 preferably provides the stored packets or portions thereof to the packet classification engine 64 and the application engine 66 for processing.
 The packet buffer 62 may also include an edit module for editing the packets prior to forwarding them out of the switching controller as outbound packets 78. The edit module may include an edit program construction engine for creating edit programs real-time and/or an edit engine for modifying the packets. The application engine 66 preferably provides application data 76, which may include a disposition decision for the packet, to the packet buffer 62, and the edit program construction engine preferably uses the application data to create the edit programs. The outbound packets 78 may be transmitted over a switching fabric interface, such as, for example, the switching backplane 12 of FIG. 1, to communication networks, such as, for example, the Ethernet.
 The packet buffer 62 may also include either or both a header data extractor and a header data cache. The header data extractor preferably is used to extract one or more fields from the packets, and to store the extracted fields in the header data cache as extracted header data. The extracted header data may include, but are not limited to, some or all of the packet header. In an Ethernet system, for example, the header data cache may also store first N bytes of each frame.
 The extracted header data preferably is provided in an output signal 70 to the packet classification engine 64 for processing. The application engine may also request and receive the extracted header data over an interface 74. The extracted header data may include, but are not limited to, one or more of Layer 2 MAC addresses, 802.1P/Q tag status, Layer 2 encapsulation type, Layer 3 protocol type, Layer 3 addresses, ToS (type of service) values and Layer 4 port numbers. In other embodiments, the output signal 70 may include the whole inbound packet, instead of or in addition to the extracted header data. In still other embodiments, the packet classification engine 64 may be used to edit the extracted header data to be placed in a format suitable for use by the application engine, and/or to load data into the header data cache.
 The packet classification engine 64 preferably includes a programmable microcode-driven embedded processing engine. The packet classification engine 64 preferably is coupled to an instruction RAM (IRAM) (not shown). The packet classification engine preferably reads and executes instructions stored in the IRAM. In one embodiment, many of the instructions executed by the packet classification engine are conditional jumps. In this embodiment, the classification logic includes a decision tree with leaves at the end points that preferably indicate different types of packet classifications. Further, branches of the decision tree preferably are selected based on comparisons between the conditions of the instructions and the header fields stored in the header data cache. In other embodiments, the classification logic may not be based on a decision tree.
 In an embodiment according to the present invention, the application engine 66 preferably has a pipelined architecture wherein multiple programmable sub-engines are pipelined in series. Each programmable sub-engine preferably performs an action on the packet, and preferably forwards the packet to the next programmable sub-engine in a “bucket brigade” fashion. The packet classification engine preferably starts the pipelined packet processing by starting the first programmable sub-engine in the application engine using a start signal 72. The start signal 72 may include identification of one or more programs to be executed in the application engine 66. The start signal 72 may also include packet classification information. The programmable sub-engines in the application engine preferably have direct access to the header data and the extracted fields stored in the header data cache over the interface 74.
 The application engine may include other processing stages not performed by the programmable sub-engines, however, the decision-making stages preferably are performed by the programmable sub-engines to increase flexibility. In other embodiments, the application engine may include other processing architectures.
 The disposition decision included in the application data 76 preferably is also provided to the policing engine 80. The policing engine 80 preferably also receives one or more policing IDs 84. The policing engine 80 preferably uses the disposition decision and the policing IDs to generate one or more policing recommendations 82. The policing recommendations may be a type of disposition recommendation, and may also be referred to as policing results. The policing recommendations preferably are provided to the application engine 66 to be used together with other disposition recommendations to generate application data, which may include the disposition decision.
 II. Dynamic Application Port Service Provisioning
FIG. 4 is a block diagram of a packet switching node 102 in an embodiment according to the present invention, coupled to a host 100 and a server 104. The packet switching node 102 may be a part of one or more LANs, WANs, MANs, and may be coupled to other LANs, WANs, MANs, hosts, servers, and the like, over a computer network, such as, for example, the Internet or an Intranet. The host 100 and the server 104 may be a part of the same LAN or they may be a part of different LANs. Further, there may be one or more other packet switching nodes, in addition to the packet switching node 102, between the host 100 and the server 104.
 The packet switching node 102 includes a forwarding engine 106, an inspection engine 108 and a forwarding engine 110. The packet switching node 102 may also include other components (not shown), such as, for example, one or more of, without being limited to, a switching fabric, media access controllers (MACs), CPUs, memories (e.g., databases), and the like, to facilitate conversations between the host 100 and the server 104 as well as other hosts and servers, which may be coupled to the packet switching node 102.
 The inspection engine 108 may be implemented in a CPU subsystem in an embodiment according to the present invention. Inspection engines in other embodiments may be implemented in hardware (e.g., ASIC) or may be implemented as a combination of hardware and software.
 The forwarding engines 106 and 110 may be similar to the packet switching controller 52 of FIG. 2 and/or the packet switching controller 60 of FIG. 3. Accordingly, the forwarding engines 106 and 110 may include other components (not shown), such as, for example, one or more of, without being limited to, a classification engine, a policing engine, an editing engine, databases, and the like, for classifying and routing packets with appropriate editing and policing. Further, the packet switching node 102 may include additional forwarding engines. For example, packet switching nodes in other embodiments may include 4, 8, 12, 16, 32, 64 or different number of forwarding engines.
 Both the host 100 and the server 104 preferably send and receive packets directed to one another. The packets may include, but are not limited to, Ethernet frames, ATM cells, TCP/IP and/or UDP/IP packets, and may also include other Layer 2 (Data Link/MAC Layer), Layer 3 (Network Layer) or Layer 4 (Transport Layer) data units. Therefore, for example, both the host 100 and the server 104 may include a media access controller (MAC) for receiving and transmitting Ethernet frames.
 For instance, the host 100 may request a Web page from the server 104 by sending one or more packets requesting the Web page using TCP/IP protocol. The server 104 may then send the Web page to the host 100 as one or more packets. The host 100 may then send one or more packets back to the server 104 to acknowledge the receipt of the Web page. These transmission and receiving of packetized information are performed via the packet switching node 102. A series of one or more transmission and receiving of packets between the host 100 and the server 104 may be referred to as a session.
 The forwarding engines 106, 110 and the inspection engine 108 may be viewed as forming two paths for packets between the host 100 and the server 104, in which the packets may enter from either the host 100 or the server 104. For example, a path from the forwarding engine 106 via the inspection engine 108 to the forwarding engine 110 may be viewed as a first path, and a path from the forwarding engine 106 directly to the forwarding engine 110 may be viewed as a second path.
 In both the first and second paths, a conversation (transmission and receiving of packets) between the host 100 and the server 104 preferably are bi-directional. During the conversation between the host 100 and the server 104, the host 100 preferably applies the application port number to a destination port field, whereas the server 104 preferably applies the application port number to a source port field. In other embodiments, there may be more than two paths between the host 100 and the server 104.
 During communications between the host 100 and the server 104, the forwarding engine 106 or the forwarding engine 110 receives one or more packets from the host 100 or the server 104, respectively. If the packet belongs to an application in which the application port number has been statically assigned, the receiving forwarding engine preferably determines the static application port number, and preferably transmits the packet directly to the other forwarding engine over the second path, and the session is directed to the second path. For example, Hypertext Transfer Protocol (HTTP) is a type of application where the application port number is typically statically assigned, and only one session (over the second path) is used to transfer data bi-directionally between the host 100 and the server 104.
 On the other hand, however, if the packet belongs to an application in which the application port number is to be assigned dynamically, the receiving forwarding engine preferably sends the packet to the inspection engine 108 on the first path, and the session preferably is directed to the first path. In an exemplary session, the forwarding engine 106 preferably receives a packet from the host 100. The forwarding engine 106 preferably detects a start of a control session for an application that is going to negotiate the application port dynamically. Similarly, when the server 104 initiates the dynamic negotiation of application port, the forwarding engine 110 preferably detects the start of a control session.
 For dynamic application port negotiation, multiple sessions, e.g., two sessions, are typically established, including the control session and a data session. The control session, as described above, is a session between the host 100 and the server 104 that negotiates the dynamic port for the data session. The control session typically uses a well-known port, which may also be referred to as a static port. Then, the data session uses the dynamic port that has been negotiated between the host 100 and the server 104. Typically, most of the data transfer between the host 100 and the server 104 takes place during the data session.
 The applications that use dynamic application port negotiation may include one or more of, but are not limited to, File Transfer Protocol (FTP) and Voice over IP (VoIP). Different QoS, statistics group, policing, bandwidth, provisioning, and the like may be provided to these and other different applications. These different treatments may also be based on the customer using the service, in addition to, or instead of the type of application being used. The statistics group typically comprises, but is not limited to, amount of traffic, size of file transfer, time of day, customer identification, and/or number of bytes. The statistics group may be used for one or more of billing, auditing, network management, traffic profiling, and the like.
 The control session for each of these applications preferably takes place using an associated well-known (or static) port. For example, file transfer protocol (FTP) has a well-known port defined by IETF (Internet Engineering Task Force), e.g., in Request for Comments (RFC) 1700 entitled “Assigned Numbers,” which is well known to those skilled in the art. Thus, when the FTP is the application, the associated well-known port is used for the control session.
 When a node (host 100 or server 104) wants to request a file from the other node using FTP, it preferably initiates a control session using the well-known port. The node-side forwarding engine looks for the start of the control session directed at the well-known control port for the FTP that indicates start of the dynamic application port negotiation. The start of the control session may be detected by looking for setting of a SYN (synchronization) flag in the TCP header in an embodiment according to the present invention. The initiating node (the host or server) preferably sends an initial packet with the SYN bit set, and the responder (the host or server) preferably sends an acknowledging packet with a SYN ACK (synchronization acknowledgement) bit set.
 During the control session, the host 100 and the server 104 use the semantics as defined by FTP to dynamically negotiate an application port, which may be different for different sessions. Once the dynamic port negotiation has been completed, the control session preferably is discontinued, and both the host 100 and the server 104 preferably switch over to a data session, during which the FTP file transfer takes place, using the application port number that was negotiated during the control session. In the transition between the control session and the data session, the traffic between the host 100 and the server 104 is redirected from the first path to the second path.
 For another example, similar scheme may be used for Voice over IP (VOIP) application. In VOIP applications, a control session may be used to negotiate an application port that will carry voice data and once the application port has been negotiated, then the negotiated application port may be used to actually carry the voice data.
 Once the traffic is diverted to the first path (via the inspection engine), all of the frames (packets) for the control session going both directions between the host 100 and the server 104 go through the inspection engine 108. The inspection engine 108 preferably captures those frames, inspects them and forwards them unedited, except for single hop routing edits if required. The inspection engine does not affect the dynamic negotiation; rather, it monitors the dynamic negotiation between the host and the server. This technique of monitoring application control session used in an embodiment according to the present invention may be referred to as “Stateful Inspection”.
 Through monitoring the dynamic negotiation, the inspection engine 108 preferably discovers the result of the negotiation. For example, the inspection engine 108 preferably determines the application port (or data port), which is the dynamic port that will become the port of the data session. Once the inspection engine 108 observes the dynamic negotiation and discovers what the new port number is going to be, then the inspection engine preferably advises the forwarding engines 106 and 110 of the new application port to use for the data session. The forwarding engines 106 and 110 then place the application port number in their respective database so that appropriate policies, for example, may be applied to the data being transferred during the data session.
 A policing engine, which may be similar to, for example, the policing engine 80 of FIG. 3, may be used to apply the policies (services levels) to the data. The policies may include one or more of, but are not limited to, Quality of Service (QoS) level, statistics group, the policing, and the like, whatever is programmed in the policy matrix of the respective forwarding engine. When the control session terminates and the host and the server switch over to the data session, the packet switching node preferably has pre-configured itself to treat the incoming traffic (of the data session) appropriately.
 The service level for the session preferably is configured upon a database in each forwarding engine used during the data session. The database preferably contains the policy matrix, which contains policy parameters, such as, for example, QoS, statistics group, policing, bandwidth and/or provisioning. For example, the policy matrix may allow for keeping track of accounting number for billing purposes and/or keeping track of a data rate for, e.g., policing purposes. Accordingly, in the forwarding engines, the dynamically negotiated application port number (and therefore the session using the port number) preferably is associated with the parameters in the policy matrix.
 The packet switching nodes in this or other embodiments may include additional inspection engines to support additional forwarding engines since a single inspection engine may be overwhelmed by multiple dynamic negotiations of applications port numbers it needs to monitor.
FIG. 5 is a flow diagram of dynamic application port negotiation in an embodiment according to the present invention. A packet switching node, such as, for example, the packet switching node 102, receives packets from a host or a server, such as, for example, the host 100 or server 104 of FIG. 1. In the packet switching node, a forwarding engine, such as, for example, the forwarding engine 106 or the forwarding engine 110 receives and forwards the packets.
 One or more of the received packets may belong to a control session in which the application port number is to be assigned dynamically (i.e., a dynamic port session). As shown in step 200 of FIG. 5, the forwarding engine preferably identifies an initial packet (e.g., the first packet) that has a well-known port number indicative of the initiation of a dynamic application port number negotiation. Once the initial packet is determined, as shown in step 202 of FIG. 2, the forwarding engine preferably directs packets for the control session to an inspection engine, such as, for example, the inspection engine 108 of FIG. 1, on an inspection engine path (a first path).
 In step 204, the inspection engine preferably monitors dynamic port negotiation. In step 206, the inspection engine preferably determines an application port number for a data session through monitoring.
 In step 208, the forwarding engines preferably are configured with a service level for the session. The service level configuration may include, for example, but is not limited to, associating the dynamic application port number on the forwarding engines with one or more of a QoS, policing, statistics group, and the like, and/or a customer.
 In step 210, the packets belonging to the dynamic port session preferably are directed to the forwarding engines on an inspection engine-independent path (a second path). The forwarding engines preferably forward the packets on the second path, and updates customer statistics per configured associations. For example, the customer statistics may include length of a phone call, local or long distance, and may include billing treatment and provisioning used for accounting purposes. When a customer purchases a service, which allows him to send a predetermined amount of data, the amount of data being sent by the customer should be tracked so that the customer does not send more data than he is allowed to. If and when the customer goes over his service limit, a corrective action, such as, for example, limiting his bandwidth, may be needed to be taken.
 It will be appreciated by those of ordinary skill in the art that the invention can be embodied in other specific forms without departing from the spirit or essential character hereof. The present description is therefore considered in all respects to be illustrative and not restrictive. The scope of the invention is indicated by the appended claims, and all changes that come within the meaning and range of equivalents thereof are intended to be embraced therein.
|Patente citada||Fecha de presentación||Fecha de publicación||Solicitante||Título|
|US6678268 *||18 Sep 1998||13 Ene 2004||The United States Of America As Represented By The Secretary Of The Navy||Multi-interface point-to-point switching system (MIPPSS) with rapid fault recovery capability|
|US6728243 *||28 Oct 1999||27 Abr 2004||Intel Corporation||Method for specifying TCP/IP packet classification parameters|
|US6778546 *||14 Feb 2000||17 Ago 2004||Cisco Technology, Inc.||High-speed hardware implementation of MDRR algorithm over a large number of queues|
|US6781994 *||25 Dic 1998||24 Ago 2004||Kabushiki Kaisha Toshiba||Distributing ATM cells to output ports based upon destination information using ATM switch core and IP forwarding|
|Patente citante||Fecha de presentación||Fecha de publicación||Solicitante||Título|
|US6950873 *||2 Ago 2001||27 Sep 2005||International Business Machines Corporation||Apparatus and method for port sharing a plurality of server processes|
|US7286532 *||22 Feb 2001||23 Oct 2007||Cisco Technology, Inc.||High performance interface logic architecture of an intermediate network node|
|US7298746||22 Abr 2002||20 Nov 2007||Extreme Networks||Method and system for reassembling and parsing packets in a network environment|
|US7321926||11 Feb 2002||22 Ene 2008||Extreme Networks||Method of and system for allocating resources to resource requests|
|US7436830||30 Sep 2004||14 Oct 2008||P-Cube Ltd.||Method and apparatus for wire-speed application layer classification of upstream and downstream data packets|
|US7447777 *||11 Feb 2002||4 Nov 2008||Extreme Networks||Switching system|
|US7584262||12 Feb 2002||1 Sep 2009||Extreme Networks||Method of and system for allocating resources to resource requests based on application of persistence policies|
|US7814204||1 Abr 2002||12 Oct 2010||Extreme Networks, Inc.||Method of and system for analyzing the content of resource requests|
|US7817546||6 Jul 2007||19 Oct 2010||Cisco Technology, Inc.||Quasi RTP metrics for non-RTP media flows|
|US7835406||18 Jun 2007||16 Nov 2010||Cisco Technology, Inc.||Surrogate stream for monitoring realtime media|
|US7844688||3 Ene 2006||30 Nov 2010||P-Cube Ltd.||Apparatus, method, and software for analyzing network traffic in a service aware network|
|US7936695||12 Jun 2007||3 May 2011||Cisco Technology, Inc.||Tunneling reports for real-time internet protocol media streams|
|US7953885 *||18 Abr 2003||31 May 2011||Cisco Technology, Inc.||Method and apparatus to apply aggregate access control list/quality of service features using a redirect cause|
|US7996520||19 Sep 2007||9 Ago 2011||Cisco Technology, Inc.||Behavioral classification of communication sessions using active session initiation|
|US8023419||14 May 2007||20 Sep 2011||Cisco Technology, Inc.||Remote monitoring of real-time internet protocol media streams|
|US8149705 *||8 Ago 2006||3 Abr 2012||Alaxala Networks Corporation||Packet communications unit|
|US8301789||18 Jun 2007||30 Oct 2012||Emc Corporation||Techniques for port hopping|
|US8301982||18 Nov 2009||30 Oct 2012||Cisco Technology, Inc.||RTP-based loss recovery and quality monitoring for non-IP and raw-IP MPEG transport flows|
|US8412838||26 Oct 2007||2 Abr 2013||Extreme Networks||Method of and system for analyzing the content of resource requests|
|US8560693||25 Oct 2007||15 Oct 2013||Extreme Networks, Inc.||Method of and system for allocating resources to resource requests based on application of persistence policies|
|US8661295 *||31 Mar 2011||25 Feb 2014||Amazon Technologies, Inc.||Monitoring and detecting causes of failures of network paths|
|US8819714||19 May 2010||26 Ago 2014||Cisco Technology, Inc.||Ratings and quality measurements for digital broadcast viewers|
|US8867385||5 Abr 2011||21 Oct 2014||Cisco Technology, Inc.||Tunneling reports for real-time Internet Protocol media streams|
|US8923292||6 Abr 2005||30 Dic 2014||Rockstar Consortium Us Lp||Differential forwarding in address-based carrier networks|
|US8937870||11 Sep 2012||20 Ene 2015||Amazon Technologies, Inc.||Network link monitoring and testing|
|US8966551||1 Nov 2007||24 Feb 2015||Cisco Technology, Inc.||Locating points of interest using references to media frames within a packet flow|
|US8976793||21 Nov 2012||10 Mar 2015||Rockstar Consortium Us Lp||Differential forwarding in address-based carrier networks|
|US9001667||31 Mar 2011||7 Abr 2015||Amazon Technologies, Inc.||Monitoring and detecting causes of failures of network paths|
|US9038035||5 Abr 2010||19 May 2015||Cisco Systems Israel, Inc.||Apparatus, method, and software for analyzing network traffic in a service aware network|
|US9104543||6 Abr 2012||11 Ago 2015||Amazon Technologies, Inc.||Determining locations of network failures|
|US20050190694 *||30 Sep 2004||1 Sep 2005||P-Cube||Method and apparatus for wire-speed application layer classification of upstream and downstream data packets|
|US20050199292 *||10 Mar 2005||15 Sep 2005||Stedman David W.||Fluid device actuator with manual override|
|US20130182722 *||1 Nov 2010||18 Jul 2013||Deepak Mysore Vishveswaraiah||Managing mac moves with secure port groups|
|US20130198411 *||14 Sep 2012||1 Ago 2013||Electronics And Telecommunications Research Institute||Packet processing apparatus and method for load balancing of multi-layered protocols|
|WO2002065717A1 *||14 Feb 2002||22 Ago 2002||Simon Assouad||Dynamic packet processor architecture|
|WO2006054032A1 *||21 Nov 2005||26 May 2006||France Telecom||Method and system for measuring use of an application|
|Clasificación de EE.UU.||709/238, 709/230|
|Clasificación internacional||G06F13/00, H04L12/24, H04L29/06, H04L12/56|
|Clasificación cooperativa||H04L69/22, H04L41/5045, H04L49/354, H04L45/50, H04L41/5003, H04L49/503, H04L41/5096, H04L49/103, H04L49/254, H04L49/602, H04L47/20, H04L49/205, H04L49/3027, H04L47/2458, H04L47/215, H04L45/00, H04L47/2408, H04L47/31, H04L49/9042, H04L49/351, H04L47/32, H04L47/10, H04L49/3018, H04L45/54, H04L49/90, H04L41/5054, H04L45/44, H04L47/2441|
|Clasificación europea||H04L47/24F, H04L49/90K, H04L47/10, H04L47/24A, H04L47/32, H04L47/24D, H04L45/44, H04L47/31, H04L47/21A, H04L49/90, H04L49/30C, H04L49/25E1, H04L49/10E, H04L49/35A, H04L47/20, H04L49/60A, H04L45/50, H04L29/06N, H04L45/00, H04L45/54|
|10 Sep 2001||AS||Assignment|
Owner name: ALCATEL INTERNETWORKING (PE), INC., WASHINGTON
Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNORS:TALLEGAS, MATHIEU;CLEAR, DAVID;MICHELS, TIMOTHY S.;AND OTHERS;REEL/FRAME:012154/0948;SIGNING DATES FROM 20010802 TO 20010824