A method and system for controlling the bandwidths of data traffic over virtual private networks are provided. The method includes classifying the data traffic for the virtual private network into different flows, monitoring a current bandwidth usage by at least one of the flows, comparing the current bandwidth usage with a predetermined threshold for the flow, and performing a bandwidth control operation for the flow if the current bandwidth usage exceeds the predetermined threshold for that flow.
|
32. A method for controlling bandwidth of data traffic for a virtual private network, the method comprising:
classifying the data traffic for the virtual private network into different flows;
monitoring a current bandwidth usage by at least one of the flows;
comparing the current bandwidth usage with a predetermined threshold for the at least one of the flows; and
performing a bandwidth control operation for the at least one of the flows based on the results from the comparing step;
wherein the at least one flow comprises encapsulated data packets and wherein the bandwidth control operation comprises dropping certain ones of the encapsulated data packets without regard to whether the encapsulated data packets are tcp data packets or UDP data packets.
34. A system for controlling bandwidth of data traffic for a virtual private network, the system comprising:
a gateway for classifying the data traffic for the virtual private network into different flows, monitoring a current bandwidth usage by at least one of the flows, comparing the current bandwidth usage with a predetermined threshold for the at least one of the flows, and performing a bandwidth control operation for the at least one of the flows based on the comparison results,
wherein the at least one of the flows comprises encapsulated data packets and wherein the gateway performs the bandwidth control operation by dropping certain ones of the encapsulated data packets without regard to whether the encapsulated data packets are tcp data packets or UDP data packets.
36. A computer program embodied on a computer-readable medium, for controlling bandwidth of data traffic for a virtual private network, the computer program comprising computer-executable instructions for:
classifying the data traffic for the virtual private network into different flows, at least one of the flows comprising encapsulated data packets;
monitoring a current bandwidth usage by the at least one of the flows;
comparing the current bandwidth usage with a predetermined threshold for the at least one of the flows; and
performing a bandwidth control operation for the at least one of the flows based on the results from the comparing step by dropping certain ones of the encapsulated data packets without regard to whether the encapsulated data packets are tcp data packets or UDP data packets.
1. A method for controlling bandwidth of data traffic for a virtual private network, the method comprising:
classifying the data traffic for the virtual private network into different flows;
monitoring a current bandwidth usage by at least one of the flows;
comparing the current bandwidth usage with a predetermined threshold for the at least one of the flows; and
performing a bandwidth control operation for the at least one of the flows based on the results from the comparing step,
wherein the bandwidth control operation is performed for the at least one of the flows if the current bandwidth usage exceeds the predetermined threshold for that flow, and wherein the bandwidth control operation includes:
alternating accept and deny times for internet protocol (IP) packets to accept or deny certain encapsulating packets of the data traffic.
11. A system for controlling bandwidth of data traffic for a virtual private network, the system comprising:
a gateway for classifying the data traffic for the virtual private network into different flows, monitoring a current bandwidth usage by at least one of the flows, comparing the current bandwidth usage with a predetermined threshold for the at least one of the flows, and performing a bandwidth control operation for the at least one of the flows based on the comparison results,
wherein the gateway performs the bandwidth control operation for the at least one of the flows if the current bandwidth usage exceeds the predetermined threshold for that flow, and
wherein the bandwidth control operation includes alternating accept and deny times for internet protocol (IP) packets to accept or deny certain encapsulating packets of the data traffic.
22. A computer program embodied on a computer-readable medium, for controlling bandwidth of data traffic for a virtual private network, the computer program comprising computer-executable instructions for:
classifying the data traffic for the virtual private network into different flows;
monitoring a current bandwidth usage by at least one of the flows;
comparing the current bandwidth usage with a predetermined threshold for the at least one of the flows; and
performing a bandwidth control operation for the at least one of the flows based on the results from the comparing step,
wherein the bandwidth control operation is performed for the at least one of the flows if the current bandwidth usage exceeds the predetermined threshold for that flow, and
wherein the computer-executable instructions for performing the bandwidth control operation include computer-executable instructions for:
alternating accept and deny times for internet protocol (IP) packets to accept or deny certain encapsulating packets of the data traffic.
2. The method according to
3. The method according to
triggering a built-in congestion control mechanism to control the bandwidth of the data traffic.
4. The method according to
5. The method according to
(taccept)/(taccept+tdeny)=bdesd/bcurr wherein taccept represents the accept time, tdeny represents the deny time, bcurr represents a currently used bandwidth for the flow, and bdesd represents the predetermined threshold.
6. The method according to
examining at least one of an internet protocol (IP) address, a media access control (MAC) address, a type of service (ToS) field, and a differentiated service (DiffServ) field of each packet of the data traffic; and
dividing the data traffic into flows based on the results from the examining step.
7. The method according to
8. The method according to
computing the current bandwidth usage by the at least one of the flow based on at least one of the following: a packet size for each packet in the flow, a flow type, a total number of packets present in the flow, and a predetermined time window set for the flow.
9. The method according to
10. The method according to
12. The system according to
a gateway controller providing the predetermined threshold and bandwidth control information to the gateway, so as to control the bandwidth control operation of the gateway.
13. The system according to
14. The system according to
15. The system according to
16. The system according to
17. The system according to
(taccept)/(taccept+tdeny)=bdesd/bcurr wherein taccept represents the accept time, tdeny represents the deny time, bcurr represents a currently used bandwidth for the flow, and bdesd represents the predetermined threshold.
18. The system according to
19. The system according to
20. The system according to
21. The system according to
23. The computer program according to
24. The computer program according to
triggering a built-in congestion control mechanism to control the bandwidth of the data traffic.
25. The computer program according to
26. The computer program according to
(taccept)/(taccept+tdeny)=bdesd/bcurr wherein taccept represents the accept time, tdeny represents the deny time, bcurr represents a currently used bandwidth for the flow, and bdesd represents the predetermined threshold.
27. The computer program according to
examining at least one of an internet protocol (IP) address, a media access control (MAC) address, a type of service (ToS) field, and a differentiated service (DiffServ) field of each packet of the data traffic; and
dividing the data traffic into flows based on the examination results.
28. The computer program according to
29. The computer program according to
computing the current bandwidth usage by the at least one of the flow based on at least one of the following: a packet size for each packet in the flow, a flow type, a total number of packets present in the flow, and a predetermined time window set for the flow.
30. The computer program according to
31. The computer program according to
33. The method according to
35. The system according to
37. The computer program according to
|
1. Field of the Invention
The invention relates to a technique of managing the bandwidth of data traffic in an Internet Protocol (IP) Virtual Private Network (VPN) so as to provide Quality of Service (QoS) for the VPN, where VPN traffic is communicated preferably over the VPN.
2. Discussion of the Related Art
IP VPNs (hereinafter “VPNs”) are specially configured networks that allow a group of users to communicate only with each other in a secured manner. Generally, VPNs are implemented over unsecured public networks of the wired nature (e.g., cable, DSL, dial-up, etc.) and/or of the wireless nature (e.g., IEEE 802.11 wireless local area networks (LANs), cellular digital packet data (CDPD) networks, etc.). In a VPN, data packets are encrypted and encapsulated in some other packets to provide a more secured data communication. The packet that encapsulates the original packet is referred to herein as the “encapsulating packet,” whereas the original packet is referred to herein as the “encapsulated packet.”
QoS refers to a technique and ability to control certain network requirements such as bandwidth requirements for packet transmission, latency requirements, maximum packet loss, etc. There are a number of different ways to provide QoS to existing TCP/IP-based networks that do not employ VPNs. For instance, Internet Engineering Task Force (IETF), which is a group of individuals who determine new protocols and application requirements, has proposed a differentiated services (DiffServ) framework or an integrated services framework for providing QoS to non-VPNs. Also, the use of an existing TCP rate control mechanism to provide QoS in a non-VPN has been proposed by Packeteer, Inc., Allot Communications, Ltd., or Sitara Networks, Inc.
Among the known QoS methods, one way of providing QoS in a non-VPN is to provide a special field called the Type of Service (ToS) in the header of an IP packet. Generally, an IP packet consists of a header and a body. The body contains data, whereas the header contains information such as source and destination IP addresses, protocol type used in the data, etc. The ToS field in the header of the packet is 3 bits in length. The value of these 3 bits in an IP packet specifies the level of priority this packet should receive in the network. With the use of 3 bit ToS, a total of 8 priority levels can be specified. Once the priority levels are set in the packet (either by the application or by a router/switch/gateway along the path of this packet), all subsequent devices which this packet traverses treat this packet according to the specified priority. For instance, a router which receives two packets, one with priority 1 and the other with priority 6, will forward the higher priority packet before forwarding the lower priority packet. Ultimately, this results in higher bandwidth, and lower delay, loss and jitter characteristics for the packets with higher priorities, thereby ensuring QoS. The IETF DiffServ proposal specifies the use of 6 bits (called DiffServ) bits in the header of an IP packet for the same purpose.
However, such existing QoS methods for non-VPNs simply do not work for VPNs because the header information of encapsulated packets communicated in VPNs is encrypted and the existing QoS methods for non-VPNs require such header information to be in a non-encrypted form (in clear text).
Recently, a proposal has been made by Radguard, Inc. and Allot Communications, Ltd. to provide QoS for VPNs using ToS or DiffServ bits. With VPNS, it is known that the original IP packet is encrypted and encapsulated in another IP packet. This means that the ToS or DiffServ bits in the original IP header are now hidden from any router/switch which is supposed to treat incoming packets based on priority. The Radguard and Allot proposal deals with IP packets constituting an IP layer (Layer 3), and simply removes this short-coming by exposing the ToS/DiffServ bits in the original IP header to the header of the encapsulating IP packet. This way the priority information is available to all devices that receive the packet.
Another proposal for a QoS method applicable to a VPN has been made by an IEEE 802.11e working group. However, the IEEE proposal addresses the QoS for only the wireless link and is concerned with enhancing QoS for media access control (MAC) protocol. Thus, for a packet traversing multiple devices, the IEEE proposal would only work for the wireless side (i.e., the link between the client and the Access Point (AP) and not for the wired side (e.g., the link between the server and the AP). The IEEE proposal is still in the draft stage and at this time consists of two ways to satisfy the different QoS needs of different frames which constitute a MAC layer (Layer 2).
The first way to provide QoS according to the IEEE proposal is using different priority levels of frames. Similar to IP packets, this allows the use of a priority field in the frame header and based on the value in this field, only the Access Point determines which frames receive preferential treatment. The second way to provide QoS according to the IEEE proposal is using a modification to the current channel access mechanism. This modification essentially allows the Access Point to schedule packet transmissions from each client at pre-specified times based on the QoS requirements of each client.
However, there are problems associated with the existing QoS techniques. First, none of the QoS techniques for VPNs above address effectively the bandwidth gap problem between wired and wireless sides. Generally, the maximum bandwidth for switched Ethernet wired networks is typically 100 Mbps, whereas the effective bandwidth for wireless 802.11b networks is only approximately 7 Mbps. But, the existing QoS techniques do not provide effective bandwidth management needed to conduct data transmission over such a tight bandwidth allotment for the wireless side. Secondly, the QoS techniques for the wired side cannot be combined with the QoS techniques for the wireless side to provide an end-to-end solution, because they operate on different layers. For instance, the IEEE proposal operates on the frames which constitute the MAC layer (Layer 2), whereas the Radguard proposal operates on IP packets constituting the IP layer (Layers 3 and 4).
Therefore, there is a need for an improved technique of managing the bandwidth of data traffic for VPNs to provide QoS, which overcomes the above-described problems and limitations of the related art.
The present invention provides a method and system for providing bandwidth management for packet-based VPNs, which overcome problems and disadvantages of the related art. Particularly, in the present invention, a method for controlling the bandwidth of data traffic for a virtual private network, includes classifying the data traffic for the virtual private network into different flows, monitoring a current bandwidth usage by at least one of the flows, comparing the current bandwidth usage with a predetermined threshold for the flow, and performing a bandwidth control operation for the flow if the current bandwidth usage exceeds the predetermined threshold for that flow.
Advantages of the present invention will become more apparent from the detailed description given hereinafter. However, it should be understood that the detailed description and specific examples, while indicating preferred embodiments of the invention, are given by way of illustration only, since various changes and modifications within the spirit and scope of the invention will become apparent to those skilled in the art from this detailed description.
The present invention will become more fully understood from the detailed description given hereinbelow and the accompanying drawings which are given by way of illustration only, and thus do not limit the present invention.
The gateway (GW) 20, which may be a wireless GW or wired GW depending on the network type, intercepts all traffic from the client device 10 to the server 50 and from the server 50 to the client device 10. The GW 20 controls the bandwidth of the traffic per connection or per flow under control of a gateway controller 30. In one embodiment, the gateway controller 30 may reside on the GW 20 itself.
The GW 20 includes a bandwidth monitoring engine 22 and a packet or bandwidth control engine 24, all operatively coupled. The bandwidth monitoring engine 22 monitors flows of network traffic between the client devices 10 and the server 50, and provides information on the bandwidth utilized by each client on a per flow basis to the gateway controller 30 via a permanent TCP connection or other known connection. In one example, a window of 2 seconds is used to compute this bandwidth information, but other criteria may be used. The packet control engine 24 receives bandwidth control commands or instructions from the gateway controller 30 on when and how to selectively drop or deny packets to be transmitted to the client device 10 or the server 50, and executes these bandwidth control commands appropriately.
In addition, various known software modules are generally present in the GW 20, some may be built-in in the kernels therein, others may be implemented in the user-space as known. In this embodiment, the GW 20 is implemented in JAVA computer programming language since it is platform-independent; however, it can be implemented using any other existing computer programming language.
The gateway controller 30 includes a manager 32 and a storage unit 34, all operatively coupled. The storage unit 34 may reside as part of the gateway controller 30 or may be a separate storage device such as a disc, DVD, CD, etc. The manager 32 receives the bandwidth information and any other information from the bandwidth monitoring engine 22, and generates and sends appropriate bandwidth control commands on when and how to drop or deny packets in each of flows for each of the client devices 10 and/or server 50. The manager 32 generates the bandwidth control commands based on certain control criteria. Such control criteria may include, but are not limited to, predetermined policies on managing bandwidth of various traffic flows such as policies on enforcing predefined bandwidth utilization thresholds for specific users, applications or per-flow; admission control policies on when to deny certain traffic (e.g., “deny any HTTP traffic if there is an ongoing VoIP session and the wireless link is more than 70% utilized); policies on for how long to delay certain packets; etc.
The control criteria may be also based on the type of connection used, and/or the direction of the traffic. Regarding the type of connection used, for instance, for a User Datagram Protocol (UDP) connection, when to accept and deny packets is computed by the gateway controller 30 based on the specific desired bandwidth. For a Transport Control Protocol (TCP) connection, instead of specifying a desired bandwidth, an administrator or the like may input a desired bandwidth manually. Regarding the direction of the traffic, for instance, for a UDP connection, such bandwidth control commands may be sent from a wired device to a wireless device, and not necessarily from a wireless device to a wired device. For a TCP connection, however, the direction of the traffic does not matter. For UDP, bandwidth control is enforced from the gateway to the destination of the traffic whereas for TCP, bandwidth management is performed in both directions at the same time.
Any data such as the bandwidth information from the GW 20 can be stored in the storage unit 34 for record keeping purposes and/or displaying to end-users or administrators if needed. Further, any other information and data being processed in the system 100 can be stored in the storage unit 34. For instance, any packet control activity performed by the packet control engine 24 of the GW 20 can be logged into the storage unit 34.
As shown in
In accordance with one embodiment of the present invention, any combination of the above flow classification processes for the VPNs may be used to provide a more granulated flow classification. For instance, all frames having the same source and destination MAC address and the same ToS or DiffServ bits in the encapsulating IP headers, can be classified into a single flow. In this process, while using the source and destination MAC addresses of Layer 2 frames allows the flow to be classified on a per-station (machine) basis, it may not necessarily distinguish between various application traffics originating from or destined for the same station. On the other hand, the use of ToS/DiffServ bits in the encapsulating IP header may not necessarily distinguish between traffics from different end-stations as long as their ToS/DiffServ bits are the same. Thus, the use of a combination of the MAC address and ToS/DiffServ bits provides a finer-grained flow classification process for the VPN. Furthermore, by using this type of flow classification, for example, a VoIP connection from client A can be distinguished from Web traffic from the same client as well as ERP traffic from client B.
Once the traffic has been classified into different flows, in Step S20 the current bandwidth of each of the defined flows is monitored by the bandwidth monitoring engine 22 of the GW 20. This can be accomplished in many different ways. As one implementation, the bandwidth monitoring engine 22 is configured to take a fixed time window and then to count the number of packets belonging to a particular flow that arrive in that time window. The size of each packet, flow type, number of packets, time window, and any other information can be used to compute the bandwidth usage for each flow, as known in the art. The GW 20 transmits the bandwidth information obtained from the monitoring process to the gateway controller 30 periodically or as needed.
In Step S30, the gateway controller 30 determines whether the current bandwidth of each flow exceeds a desired bandwidth threshold. The desired bandwidth threshold, i.e., the desired bandwidth that should be used by each flow is determined based on the QoS requirements. The QoS requirements would set the desired bandwidth for different types of flows. For instance, a VoIP flow may be permitted to utilize 64 Kbps with acceptable delay, loss and jitter characteristics, whereas a flow with less priority or importance may be permitted to use a less bandwidth. The QoS requirements for each flow are predetermined by an administrator or some other means, and are input as control policies into the gateway controller 30 as discussed above. The gateway controller 30 then computes what the desired bandwidth threshold should be for each flow, and compares the current bandwidth of each flow with the desired bandwidth threshold. If the current bandwidth usage does not exceed the desired bandwidth threshold, then no separate bandwidth control operation is performed and the process ends.
However, at Step S30 if it is determined that the current bandwidth of each flow exceeds the corresponding desired bandwidth threshold, then in Step S40 a bandwidth control operation is performed for the appropriate flows according to the present invention. The bandwidth control operation is triggered by the gateway controller 30 which generates bandwidth control commands on when and how to drop or deny packets (encapsulating packets) and transmits the commands to the packet control engine 24 of the GW 20. The packet control engine 24 then executes these bandwidth control commands by dropping or denying encapsulating (VPN) packets according to the criteria set in the control commands.
Generally, because of the packet encryption and encapsulation, the system may not know what type of data (e.g., TCP or UDP) is contained in the encapsulating packets. Thus, in a preferred embodiment, the system drops any packets which may be data packets or acknowledgement (ACK) packets assuming first that the TCP traffic is involved. In this case, it does not matter whether the dropped packet is a data packet or ACK packet since the same effect of triggering the TCP's congestion control is obtained. If the data contained in the VPN packet is indeed TCP traffic, at the packet source or destination side, the packet-dropping or packet-denying operation is interpreted as a traffic congestion, which triggers TCP's built-in congestion control algorithm. That is, if the server does not receive an acknowledgement/data packet at certain times, then TCP's built-in congestion control algorithm causes the server to interpret this as a presence of a traffic congestion and slows down the rate at which data packets are transmitted to the client, whereby the bandwidth of the packet flow is controlled. This has the same effect of reducing the bandwidth of the flow and would free the medium to allow higher bandwidth usage by other higher-priority flows.
If the data contained in the VPN packet is UDP traffic, then the packet dropping operation would not trigger the TCP's built-in congestion control algorithm, and a bandwidth control operation for UDP traffic is performed which is discussed later in detail. Generally, one skilled in the art would readily understand that the system 100 performs simultaneously multiple bandwidth control operations for multiple flows at a given time. Once the bandwidth control has been accomplished for each flow, the process ends.
As shown in
Regarding
Now, having described the bandwidth control for a TCP traffic for a VPN, a bandwidth control for a UDP traffic over a VPN is described according to an embodiment of the present invention. As known, UDP is a connectionless packet transmission protocol and thus, no ACK packet is involved in UDP transmissions. Thus, if it is known that an incoming traffic mainly consists of UDP traffic, the present invention drops incoming data packets (encapsulating packets) in the GW 20 that exceed a predetermined bandwidth threshold. These packets are not ACK packets. A predetermined bandwidth threshold can be input by an administrator or can be determined automatically by the system. In one embodiment, instead of dropping the incoming packets to satisfy the desired bandwidth, a pulse function of alternating ‘accept’ and ‘deny’ times for packets can be used to drop packets on and off, more periodically throughout the flow. This would disperse the impact of dropping packets throughout the flow.
For UDP traffic from the wired to wireless side, the accept and deny times according to one embodiment are computed by taking into account the currently used bandwidth bcurr, the desired bandwidth bdesd, and the average interpacket arrival time tavg for that connection. This can be accomplished by choosing the deny time tdeny and the accept time taccept such that the following relationship is established:
(taccept)/(taccept+tdeny)=bdesd/bcurr.
Furthermore, the average interpacket arrival time tavg can be set as follows:
min{taccept, tdeny}=tavg.
That is, the lesser of taccept and tdeny is selected as tavg. This ensures that only the minimal number of consecutive packets are dropped in the process of obtaining the desired bandwidth. For feasibility purposes, in one example, the interpacket arrival time may not be below 50 ms. Experiments indicate that the bandwidth observed for such connections can be controlled accurately by this approach.
In one embodiment, the system can be configured such that the flow classification can occur using one of most appropriate classification processes. That is, the system can be configured to select automatically one of available classification processes that would provide an optimal flow classification. In one embodiment, if the type of traffic is unknown (e.g., whether it is TCP traffic or UDP traffic), then the system can be configured to perform first a TCP bandwidth control operation as discussed above, and then to perform a UDP bandwidth control operation if the TCP bandwidth control operation produces no result. This is based on the assumption that more TCP traffic than UDP traffic is used. However, if more UDP traffic is used in the system, then the UDP bandwidth control operation may be performed first before the TCP bandwidth control operation is performed.
In still another embodiment, the bandwidth information provided by the bandwidth monitoring engine 22 for monitoring the bandwidth usage of flows can be used as another means of a flow classification. For instance, assume that there are two flows F1 and F2. F1 originates from station A and constitutes VoIP traffic. F2 originates from station B but constitutes non-real time traffic. The ToS/DiffServ bits are not set, so that it is only possible to use the MAC or IP address-based flow classification technique. In this case, the GW 20 can only determine that the flows F1 and F2 originate from different stations. But, since the GW 20 monitors the bandwidth usage, it will determine that the bandwidth usage for the flow F1 is approximately 64 Kbps (assuming the use of G.711 codec and reasonable network performance), which indicates that it is a VoIP traffic.
In yet another embodiment, although the maximum bandwidth a client can achieve is fixed, e.g., 11 Mbps, the actual bandwidth the client receives can depend heavily on the strength of the radio signal with the base-station it is connected to. The transmission speed of the client is varied in discrete steps (e.g., 1 Mbps, 2 Mbps, 5.5 Mbps, and 11 Mbps) depending on various thresholds for signal-strength. As such, the gateway controller 30 can be configured to obtain signal strength information from SNMP (Simple Network Management Protocol) queries to the base-station as known, and to use this information in determining bandwidth management policies used, at least in part, to control the bandwidth usage of each flow. In still another embodiment, instead of slowing down the packet transmission rate, it is possible to speed up the packet transmission rate using the present invention to control the bandwidth use, if that is desired.
Accordingly, the present invention provides an effective technique for controlling the bandwidth of data traffic for VPNs using flow classification techniques and packet-dropping or packet-denying techniques, so as to provide QoS for the VPNs. The present invention can be implemented using any known hardware and/or software. Any known computer programming language can be used to implement the present invention.
The invention being thus described, it will be obvious that the same may be varied in many ways. Such variations are not to be regarded as a departure from the spirit and scope of the invention, and all such modifications as would be obvious to one skilled in the art are intended to be included within the scope of the following claims.
Mani, Mahalingam, Kappes, Martin, Garg, Sachin
Patent | Priority | Assignee | Title |
7653047, | Sep 02 2004 | Samsung Electronics Co., Ltd. | Guaranteeing quality of service (QoS) using bandwidth reservation in switch |
7751858, | May 05 2006 | Intel Coproration | Sleep-mode statistics apparatus, systems, and methods |
7912081, | Apr 22 2005 | SAMSUNG ELECTRONICS CO , LTD | Defragmentation of communication channel allocations |
7983621, | May 05 2006 | Intel Corporation | Sleep-mode statistics apparatus, systems, and methods |
8005009, | Jun 25 2004 | InMon Corp. | Methods and computer programs for generating data traffic matrices |
8085696, | Jul 14 2006 | ERICSSON EVDO INC | Dynamic modification of route update protocols |
8094630, | Dec 16 2005 | ERICSSON EVDO INC | Radio frequency dragging prevention |
8099504, | Jun 24 2005 | ERICSSON EVDO INC | Preserving sessions in a wireless network |
8125897, | Aug 22 2006 | CenturyLink Intellectual Property LLC | System and method for monitoring and optimizing network performance with user datagram protocol network performance information packets |
8145221, | Dec 16 2005 | ERICSSON EVDO INC | Radio network communication |
8160020, | Jun 25 2001 | ERICSSON EVDO INC | Radio network control |
8195187, | Jun 25 2001 | ERICSSON EVDO INC | Radio network control |
8615238, | Jun 25 2001 | ERICSSON EVDO INC | Radio network control |
8619702, | Dec 16 2005 | ERICSSON EVDO INC | Radio network control |
8621090, | May 07 2009 | TINDER LLC; MATCH GROUP AMERICAS, LLC | System and method for providing sequenced anonymous communication sessions over a network |
8848522, | Jun 23 2008 | Hitachi, Ltd. | Telecommunications system and server apparatus |
8885012, | May 07 2009 | TINDER LLC; MATCH GROUP AMERICAS, LLC | System and method for providing anonymity in a video/multimedia communications session over a network |
8996618, | May 07 2009 | TINDER LLC; MATCH GROUP AMERICAS, LLC | System and method for providing sequenced anonymous communication sessions over a network |
9019935, | Jun 25 2001 | ERICSSON EVDO INC | Radio network control |
9148333, | Mar 31 2009 | TINDER LLC; MATCH GROUP AMERICAS, LLC | System and method for providing anonymity in a session initiated protocol network |
9185184, | Mar 31 2009 | TINDER LLC; MATCH GROUP AMERICAS, LLC | System and method for providing calendar and speed dating features for matching users in a network environment |
9413845, | Mar 31 2009 | TINDER LLC; MATCH GROUP AMERICAS, LLC | System and method for providing calendar and speed dating features for matching users in a network environment |
9485144, | Nov 13 2009 | INMON CORP | Network traffic optimization |
9712443, | Jun 30 2008 | InMon Corp.; INMON CORP | Distributed traffic quota measurement and enforcement |
Patent | Priority | Assignee | Title |
5995488, | Oct 08 1996 | Advanced Micro Devices, Inc. | Method and apparatus for regulating data flow in networks |
6092113, | Aug 29 1996 | KDDI Corporation | Method for constructing a VPN having an assured bandwidth |
6222856, | Jul 02 1996 | Microsoft Technology Licensing, LLC | Adaptive bandwidth throttling for individual virtual services supported on a network server |
6331986, | Apr 24 1998 | Lucent Technologies Inc.; Lucent Technologies Inc | Method for resource allocation and routing in multi-service virtual private networks |
6680933, | Sep 23 1999 | RPX CLEARINGHOUSE LLC | Telecommunications switches and methods for their operation |
6901052, | May 04 2001 | RPX Corporation | System and method for policing multiple data flows and multi-protocol data flows |
6904057, | May 04 2001 | RPX Corporation | Method and apparatus for providing multi-protocol, multi-stage, real-time frame classification |
6912232, | Oct 19 1998 | AT&T Corp.; AT&T Corp | Virtual private network |
6944168, | May 04 2001 | RPX Corporation | System and method for providing transformation of multi-protocol packets in a data stream |
7042848, | May 04 2001 | RPX Corporation | System and method for hierarchical policing of flows and subflows of a data stream |
Executed on | Assignor | Assignee | Conveyance | Frame | Reel | Doc |
Jun 20 2002 | MANI, MAHALINGAM | Avaya Technology Corp | ASSIGNMENT OF ASSIGNORS INTEREST SEE DOCUMENT FOR DETAILS | 013057 | /0901 | |
Jun 21 2002 | KAPPES, MARTIN | Avaya Technology Corp | ASSIGNMENT OF ASSIGNORS INTEREST SEE DOCUMENT FOR DETAILS | 013057 | /0901 | |
Jun 21 2002 | GARG, SACHIN | Avaya Technology Corp | ASSIGNMENT OF ASSIGNORS INTEREST SEE DOCUMENT FOR DETAILS | 013057 | /0901 | |
Jun 25 2002 | Avaya, Inc. | (assignment on the face of the patent) | / | |||
Sep 30 2005 | Avaya Technology Corp | Avaya Technology LLC | CONVERSION FROM CORP TO LLC | 022677 | /0550 | |
Oct 26 2007 | OCTEL COMMUNICATIONS LLC | CITIBANK, N A , AS ADMINISTRATIVE AGENT | SECURITY AGREEMENT | 020156 | /0149 | |
Oct 26 2007 | OCTEL COMMUNICATIONS LLC | CITICORP USA, INC , AS ADMINISTRATIVE AGENT | SECURITY AGREEMENT | 020166 | /0705 | |
Oct 26 2007 | Avaya Technology LLC | CITICORP USA, INC , AS ADMINISTRATIVE AGENT | SECURITY AGREEMENT | 020166 | /0705 | |
Oct 26 2007 | Avaya, Inc | CITICORP USA, INC , AS ADMINISTRATIVE AGENT | SECURITY AGREEMENT | 020166 | /0705 | |
Oct 26 2007 | VPNET TECHNOLOGIES, INC | CITIBANK, N A , AS ADMINISTRATIVE AGENT | SECURITY AGREEMENT | 020156 | /0149 | |
Oct 26 2007 | VPNET TECHNOLOGIES, INC | CITICORP USA, INC , AS ADMINISTRATIVE AGENT | SECURITY AGREEMENT | 020166 | /0705 | |
Oct 26 2007 | Avaya, Inc | CITIBANK, N A , AS ADMINISTRATIVE AGENT | SECURITY AGREEMENT | 020156 | /0149 | |
Oct 26 2007 | Avaya Technology LLC | CITIBANK, N A , AS ADMINISTRATIVE AGENT | SECURITY AGREEMENT | 020156 | /0149 | |
Jun 26 2008 | AVAYA LICENSING LLC | AVAYA Inc | REASSIGNMENT | 021156 | /0082 | |
Jun 26 2008 | Avaya Technology LLC | AVAYA Inc | REASSIGNMENT | 021156 | /0082 | |
Feb 11 2011 | AVAYA INC , A DELAWARE CORPORATION | BANK OF NEW YORK MELLON TRUST, NA, AS NOTES COLLATERAL AGENT, THE | SECURITY AGREEMENT | 025863 | /0535 | |
Mar 07 2013 | Avaya, Inc | BANK OF NEW YORK MELLON TRUST COMPANY, N A , THE | SECURITY AGREEMENT | 030083 | /0639 | |
Jan 24 2017 | VPNET TECHNOLOGIES, INC | CITIBANK, N A , AS ADMINISTRATIVE AGENT | SECURITY INTEREST SEE DOCUMENT FOR DETAILS | 041576 | /0001 | |
Jan 24 2017 | Octel Communications Corporation | CITIBANK, N A , AS ADMINISTRATIVE AGENT | SECURITY INTEREST SEE DOCUMENT FOR DETAILS | 041576 | /0001 | |
Jan 24 2017 | AVAYA Inc | CITIBANK, N A , AS ADMINISTRATIVE AGENT | SECURITY INTEREST SEE DOCUMENT FOR DETAILS | 041576 | /0001 | |
Jan 24 2017 | AVAYA INTEGRATED CABINET SOLUTIONS INC | CITIBANK, N A , AS ADMINISTRATIVE AGENT | SECURITY INTEREST SEE DOCUMENT FOR DETAILS | 041576 | /0001 | |
Nov 28 2017 | THE BANK OF NEW YORK MELLON TRUST COMPANY, N A | AVAYA Inc | BANKRUPTCY COURT ORDER RELEASING ALL LIENS INCLUDING THE SECURITY INTEREST RECORDED AT REEL FRAME 030083 0639 | 045012 | /0666 | |
Nov 28 2017 | THE BANK OF NEW YORK MELLON TRUST, NA | AVAYA Inc | BANKRUPTCY COURT ORDER RELEASING ALL LIENS INCLUDING THE SECURITY INTEREST RECORDED AT REEL FRAME 025863 0535 | 044892 | /0001 | |
Nov 28 2017 | CITIBANK, N A , AS ADMINISTRATIVE AGENT | Avaya, Inc | BANKRUPTCY COURT ORDER RELEASING THE SECURITY INTEREST RECORDED AT REEL FRAME 020156 0149 | 060953 | /0412 | |
Nov 28 2017 | CITIBANK, N A , AS ADMINISTRATIVE AGENT | Avaya Technology LLC | BANKRUPTCY COURT ORDER RELEASING THE SECURITY INTEREST RECORDED AT REEL FRAME 020156 0149 | 060953 | /0412 | |
Nov 28 2017 | CITIBANK, N A , AS ADMINISTRATIVE AGENT | OCTEL COMMUNICATIONS LLC | BANKRUPTCY COURT ORDER RELEASING THE SECURITY INTEREST RECORDED AT REEL FRAME 020156 0149 | 060953 | /0412 | |
Nov 28 2017 | CITIBANK, N A , AS ADMINISTRATIVE AGENT | VPNET TECHNOLOGIES | BANKRUPTCY COURT ORDER RELEASING THE SECURITY INTEREST RECORDED AT REEL FRAME 020156 0149 | 060953 | /0412 | |
Nov 28 2017 | CITIBANK, N A | VPNET TECHNOLOGIES, INC | BANKRUPTCY COURT ORDER RELEASING ALL LIENS INCLUDING THE SECURITY INTEREST RECORDED AT REEL FRAME 041576 0001 | 044893 | /0531 | |
Nov 28 2017 | CITIBANK, N A | OCTEL COMMUNICATIONS LLC FORMERLY KNOWN AS OCTEL COMMUNICATIONS CORPORATION | BANKRUPTCY COURT ORDER RELEASING ALL LIENS INCLUDING THE SECURITY INTEREST RECORDED AT REEL FRAME 041576 0001 | 044893 | /0531 | |
Nov 28 2017 | CITIBANK, N A | AVAYA INTEGRATED CABINET SOLUTIONS INC | BANKRUPTCY COURT ORDER RELEASING ALL LIENS INCLUDING THE SECURITY INTEREST RECORDED AT REEL FRAME 041576 0001 | 044893 | /0531 | |
Nov 28 2017 | CITIBANK, N A | AVAYA Inc | BANKRUPTCY COURT ORDER RELEASING ALL LIENS INCLUDING THE SECURITY INTEREST RECORDED AT REEL FRAME 041576 0001 | 044893 | /0531 | |
Dec 15 2017 | CITICORP USA, INC | SIERRA HOLDINGS CORP | RELEASE BY SECURED PARTY SEE DOCUMENT FOR DETAILS | 045032 | /0213 | |
Dec 15 2017 | OCTEL COMMUNICATIONS LLC | CITIBANK, N A , AS COLLATERAL AGENT | SECURITY INTEREST SEE DOCUMENT FOR DETAILS | 045124 | /0026 | |
Dec 15 2017 | VPNET TECHNOLOGIES, INC | CITIBANK, N A , AS COLLATERAL AGENT | SECURITY INTEREST SEE DOCUMENT FOR DETAILS | 045124 | /0026 | |
Dec 15 2017 | CITICORP USA, INC | Avaya, Inc | RELEASE BY SECURED PARTY SEE DOCUMENT FOR DETAILS | 045032 | /0213 | |
Dec 15 2017 | CITICORP USA, INC | Avaya Technology, LLC | RELEASE BY SECURED PARTY SEE DOCUMENT FOR DETAILS | 045032 | /0213 | |
Dec 15 2017 | CITICORP USA, INC | OCTEL COMMUNICATIONS LLC | RELEASE BY SECURED PARTY SEE DOCUMENT FOR DETAILS | 045032 | /0213 | |
Dec 15 2017 | AVAYA INTEGRATED CABINET SOLUTIONS LLC | CITIBANK, N A , AS COLLATERAL AGENT | SECURITY INTEREST SEE DOCUMENT FOR DETAILS | 045124 | /0026 | |
Dec 15 2017 | AVAYA Inc | CITIBANK, N A , AS COLLATERAL AGENT | SECURITY INTEREST SEE DOCUMENT FOR DETAILS | 045124 | /0026 | |
Dec 15 2017 | ZANG, INC | GOLDMAN SACHS BANK USA, AS COLLATERAL AGENT | SECURITY INTEREST SEE DOCUMENT FOR DETAILS | 045034 | /0001 | |
Dec 15 2017 | VPNET TECHNOLOGIES, INC | GOLDMAN SACHS BANK USA, AS COLLATERAL AGENT | SECURITY INTEREST SEE DOCUMENT FOR DETAILS | 045034 | /0001 | |
Dec 15 2017 | OCTEL COMMUNICATIONS LLC | GOLDMAN SACHS BANK USA, AS COLLATERAL AGENT | SECURITY INTEREST SEE DOCUMENT FOR DETAILS | 045034 | /0001 | |
Dec 15 2017 | AVAYA INTEGRATED CABINET SOLUTIONS LLC | GOLDMAN SACHS BANK USA, AS COLLATERAL AGENT | SECURITY INTEREST SEE DOCUMENT FOR DETAILS | 045034 | /0001 | |
Dec 15 2017 | AVAYA Inc | GOLDMAN SACHS BANK USA, AS COLLATERAL AGENT | SECURITY INTEREST SEE DOCUMENT FOR DETAILS | 045034 | /0001 | |
Dec 15 2017 | CITICORP USA, INC | VPNET TECHNOLOGIES, INC | RELEASE BY SECURED PARTY SEE DOCUMENT FOR DETAILS | 045032 | /0213 | |
Dec 15 2017 | ZANG, INC | CITIBANK, N A , AS COLLATERAL AGENT | SECURITY INTEREST SEE DOCUMENT FOR DETAILS | 045124 | /0026 | |
Sep 25 2020 | AVAYA Inc | WILMINGTON TRUST, NATIONAL ASSOCIATION | SECURITY INTEREST SEE DOCUMENT FOR DETAILS | 053955 | /0436 | |
Sep 25 2020 | AVAYA MANAGEMENT L P | WILMINGTON TRUST, NATIONAL ASSOCIATION | SECURITY INTEREST SEE DOCUMENT FOR DETAILS | 053955 | /0436 | |
Sep 25 2020 | INTELLISIST, INC | WILMINGTON TRUST, NATIONAL ASSOCIATION | SECURITY INTEREST SEE DOCUMENT FOR DETAILS | 053955 | /0436 | |
Sep 25 2020 | AVAYA INTEGRATED CABINET SOLUTIONS LLC | WILMINGTON TRUST, NATIONAL ASSOCIATION | SECURITY INTEREST SEE DOCUMENT FOR DETAILS | 053955 | /0436 | |
Jul 12 2022 | AVAYA Inc | WILMINGTON TRUST, NATIONAL ASSOCIATION, AS COLLATERAL AGENT | INTELLECTUAL PROPERTY SECURITY AGREEMENT | 061087 | /0386 | |
Jul 12 2022 | INTELLISIST, INC | WILMINGTON TRUST, NATIONAL ASSOCIATION, AS COLLATERAL AGENT | INTELLECTUAL PROPERTY SECURITY AGREEMENT | 061087 | /0386 | |
Jul 12 2022 | AVAYA MANAGEMENT L P | WILMINGTON TRUST, NATIONAL ASSOCIATION, AS COLLATERAL AGENT | INTELLECTUAL PROPERTY SECURITY AGREEMENT | 061087 | /0386 | |
Jul 12 2022 | AVAYA CABINET SOLUTIONS LLC | WILMINGTON TRUST, NATIONAL ASSOCIATION, AS COLLATERAL AGENT | INTELLECTUAL PROPERTY SECURITY AGREEMENT | 061087 | /0386 | |
Apr 03 2023 | CITIBANK, N A , AS COLLATERAL AGENT | AVAYA HOLDINGS CORP | RELEASE OF SECURITY INTEREST IN PATENTS AT REEL 45124 FRAME 0026 | 063457 | /0001 | |
Apr 03 2023 | CITIBANK, N A , AS COLLATERAL AGENT | AVAYA Inc | RELEASE OF SECURITY INTEREST IN PATENTS AT REEL 45124 FRAME 0026 | 063457 | /0001 | |
Apr 03 2023 | CITIBANK, N A , AS COLLATERAL AGENT | AVAYA MANAGEMENT L P | RELEASE OF SECURITY INTEREST IN PATENTS AT REEL 45124 FRAME 0026 | 063457 | /0001 | |
Apr 03 2023 | CITIBANK, N A , AS COLLATERAL AGENT | AVAYA INTEGRATED CABINET SOLUTIONS LLC | RELEASE OF SECURITY INTEREST IN PATENTS AT REEL 45124 FRAME 0026 | 063457 | /0001 | |
May 01 2023 | WILMINGTON TRUST, NATIONAL ASSOCIATION, AS NOTES COLLATERAL AGENT | AVAYA Inc | RELEASE OF SECURITY INTEREST IN PATENTS REEL FRAME 53955 0436 | 063705 | /0023 | |
May 01 2023 | WILMINGTON TRUST, NATIONAL ASSOCIATION, AS NOTES COLLATERAL AGENT | INTELLISIST, INC | RELEASE OF SECURITY INTEREST IN PATENTS REEL FRAME 53955 0436 | 063705 | /0023 | |
May 01 2023 | WILMINGTON TRUST, NATIONAL ASSOCIATION, AS NOTES COLLATERAL AGENT | AVAYA INTEGRATED CABINET SOLUTIONS LLC | RELEASE OF SECURITY INTEREST IN PATENTS REEL FRAME 53955 0436 | 063705 | /0023 | |
May 01 2023 | WILMINGTON TRUST, NATIONAL ASSOCIATION, AS NOTES COLLATERAL AGENT | AVAYA MANAGEMENT L P | RELEASE OF SECURITY INTEREST IN PATENTS REEL FRAME 53955 0436 | 063705 | /0023 | |
May 01 2023 | AVAYA Inc | AVAYA LLC | SECURITY INTEREST GRANTOR S NAME CHANGE | 065019 | /0231 | |
May 01 2023 | GOLDMAN SACHS BANK USA , AS COLLATERAL AGENT | AVAYA MANAGEMENT L P | RELEASE OF SECURITY INTEREST IN PATENTS REEL FRAME 045034 0001 | 063779 | /0622 | |
May 01 2023 | AVAYA MANAGEMENT L P | CITIBANK, N A , AS COLLATERAL AGENT | INTELLECTUAL PROPERTY SECURITY AGREEMENT | 063542 | /0662 | |
May 01 2023 | AVAYA Inc | CITIBANK, N A , AS COLLATERAL AGENT | INTELLECTUAL PROPERTY SECURITY AGREEMENT | 063542 | /0662 | |
May 01 2023 | WILMINGTON TRUST, NATIONAL ASSOCIATION, AS NOTES COLLATERAL AGENT | AVAYA INTEGRATED CABINET SOLUTIONS LLC | RELEASE OF SECURITY INTEREST IN PATENTS REEL FRAME 61087 0386 | 063690 | /0359 | |
May 01 2023 | WILMINGTON TRUST, NATIONAL ASSOCIATION, AS NOTES COLLATERAL AGENT | INTELLISIST, INC | RELEASE OF SECURITY INTEREST IN PATENTS REEL FRAME 61087 0386 | 063690 | /0359 | |
May 01 2023 | WILMINGTON TRUST, NATIONAL ASSOCIATION, AS NOTES COLLATERAL AGENT | AVAYA MANAGEMENT L P | RELEASE OF SECURITY INTEREST IN PATENTS REEL FRAME 61087 0386 | 063690 | /0359 | |
May 01 2023 | KNOAHSOFT INC | WILMINGTON SAVINGS FUND SOCIETY, FSB [COLLATERAL AGENT] | INTELLECTUAL PROPERTY SECURITY AGREEMENT | 063742 | /0001 | |
May 01 2023 | INTELLISIST, INC | WILMINGTON SAVINGS FUND SOCIETY, FSB [COLLATERAL AGENT] | INTELLECTUAL PROPERTY SECURITY AGREEMENT | 063742 | /0001 | |
May 01 2023 | AVAYA Inc | WILMINGTON SAVINGS FUND SOCIETY, FSB [COLLATERAL AGENT] | INTELLECTUAL PROPERTY SECURITY AGREEMENT | 063742 | /0001 | |
May 01 2023 | INTELLISIST, INC | CITIBANK, N A , AS COLLATERAL AGENT | INTELLECTUAL PROPERTY SECURITY AGREEMENT | 063542 | /0662 | |
May 01 2023 | WILMINGTON TRUST, NATIONAL ASSOCIATION, AS NOTES COLLATERAL AGENT | AVAYA Inc | RELEASE OF SECURITY INTEREST IN PATENTS REEL FRAME 61087 0386 | 063690 | /0359 | |
May 01 2023 | GOLDMAN SACHS BANK USA , AS COLLATERAL AGENT | AVAYA Inc | RELEASE OF SECURITY INTEREST IN PATENTS REEL FRAME 045034 0001 | 063779 | /0622 | |
May 01 2023 | GOLDMAN SACHS BANK USA , AS COLLATERAL AGENT | CAAS TECHNOLOGIES, LLC | RELEASE OF SECURITY INTEREST IN PATENTS REEL FRAME 045034 0001 | 063779 | /0622 | |
May 01 2023 | GOLDMAN SACHS BANK USA , AS COLLATERAL AGENT | HYPERQUALITY II, LLC | RELEASE OF SECURITY INTEREST IN PATENTS REEL FRAME 045034 0001 | 063779 | /0622 | |
May 01 2023 | GOLDMAN SACHS BANK USA , AS COLLATERAL AGENT | HYPERQUALITY, INC | RELEASE OF SECURITY INTEREST IN PATENTS REEL FRAME 045034 0001 | 063779 | /0622 | |
May 01 2023 | GOLDMAN SACHS BANK USA , AS COLLATERAL AGENT | ZANG, INC FORMER NAME OF AVAYA CLOUD INC | RELEASE OF SECURITY INTEREST IN PATENTS REEL FRAME 045034 0001 | 063779 | /0622 | |
May 01 2023 | GOLDMAN SACHS BANK USA , AS COLLATERAL AGENT | VPNET TECHNOLOGIES, INC | RELEASE OF SECURITY INTEREST IN PATENTS REEL FRAME 045034 0001 | 063779 | /0622 | |
May 01 2023 | GOLDMAN SACHS BANK USA , AS COLLATERAL AGENT | OCTEL COMMUNICATIONS LLC | RELEASE OF SECURITY INTEREST IN PATENTS REEL FRAME 045034 0001 | 063779 | /0622 | |
May 01 2023 | GOLDMAN SACHS BANK USA , AS COLLATERAL AGENT | AVAYA INTEGRATED CABINET SOLUTIONS LLC | RELEASE OF SECURITY INTEREST IN PATENTS REEL FRAME 045034 0001 | 063779 | /0622 | |
May 01 2023 | GOLDMAN SACHS BANK USA , AS COLLATERAL AGENT | INTELLISIST, INC | RELEASE OF SECURITY INTEREST IN PATENTS REEL FRAME 045034 0001 | 063779 | /0622 | |
May 01 2023 | AVAYA MANAGEMENT L P | WILMINGTON SAVINGS FUND SOCIETY, FSB [COLLATERAL AGENT] | INTELLECTUAL PROPERTY SECURITY AGREEMENT | 063742 | /0001 |
Date | Maintenance Fee Events |
Feb 09 2009 | ASPN: Payor Number Assigned. |
Jul 05 2012 | M1551: Payment of Maintenance Fee, 4th Year, Large Entity. |
Jul 26 2016 | M1552: Payment of Maintenance Fee, 8th Year, Large Entity. |
Jul 27 2020 | M1553: Payment of Maintenance Fee, 12th Year, Large Entity. |
Date | Maintenance Schedule |
Feb 03 2012 | 4 years fee payment window open |
Aug 03 2012 | 6 months grace period start (w surcharge) |
Feb 03 2013 | patent expiry (for year 4) |
Feb 03 2015 | 2 years to revive unintentionally abandoned end. (for year 4) |
Feb 03 2016 | 8 years fee payment window open |
Aug 03 2016 | 6 months grace period start (w surcharge) |
Feb 03 2017 | patent expiry (for year 8) |
Feb 03 2019 | 2 years to revive unintentionally abandoned end. (for year 8) |
Feb 03 2020 | 12 years fee payment window open |
Aug 03 2020 | 6 months grace period start (w surcharge) |
Feb 03 2021 | patent expiry (for year 12) |
Feb 03 2023 | 2 years to revive unintentionally abandoned end. (for year 12) |