A method and apparatus for providing differentiated services using a multi-level queuing mechanism includes checking whether a packet of data is to receive a preferred level of service, and if the packet is not to receive the preferred level of service, then placing the packet in a first forwarding queue. However, if the packet of data is to receive the preferred level of service then checking whether it is permissible to forward the packet to a device in the network at the current time. If it is permissible to forward the packet to the device at the current time, then placing the packet in a second forwarding queue, otherwise temporarily placing the packet in a holding queue before placing the packet in the second forwarding queue.
|
1. A method of providing differentiated services in a network, the method comprising:
(1) checking whether a packet of data is to receive a preferred level of service; and
(2) placing the packet in a first forwarding queue if the packet is not to receive the preferred level of service, otherwise
(a) checking whether it is permissible to send the packet to the network at the current time, and
(b) either (i) placing the packet in a second forwarding queue if it is permissible to forward the packet at the current time or (ii) temporarily placing the packet in a holding queue before placing the packet in the second forwarding queue.
15. A machine-readable medium having stored thereon a plurality of instructions, designed to be executed by a processor, for providing differentiated services in a network by implementing a function to:
(1) check whether a packet of data is to receive a preferred level of service; and
(2) place the packet in a first forwarding queue if the packet is not to receive the preferred level of service, otherwise
(a) check whether it is permissible to send the packet to the network at the current time, and
(b) either (i) place the packet in a second forwarding queue if it is permissible to forward the packet at the current time or (ii) temporarily place the packet in a holding queue before placing the packet in the second forwarding queue.
6. An apparatus for providing differentiated services in a network, the apparatus comprising:
a first queue;
a second queue;
a holding queue to store packets of data prior to being placed in the second queue; and
a policy meter in communication with the first queue, the second queue and the holding queue, the policy meter to coordinate placement of a packet of data within (i) the first queue if the packet of data is not to receive a preferred level of service, (ii) the second queue if the packet is to receive the preferred level of service and it is permissible to forward the packet of data to the network at a current time, (iii) the holding queue if the packet of data is to receive the preferred level of service, it is permissible to forward the packet of data to the network at the current time and the holding queue is able to store the packet of data.
13. An apparatus for providing differentiated services in a network, the apparatus comprising:
first means for forwarding packets of data to the network;
second means for forwarding packets of data to the network;
means for temporarily storing packets of data prior to being provided to the second means for forwarding packets; and
metering means for (i) checking whether a packet of data is to receive a preferred level of service, and, if the packet is not to receive the preferred level of service, then for providing the packet to the first means for forwarding packets, otherwise (ii) checking whether it is permissible to forward the packet over the current time, and if it is permissible to forward the packet to the device at the current time, then providing the packet to the second means for forwarding packets, otherwise providing the packet to the means for temporarily storing packets.
2. The method of
forwarding the packet of data to the network from the first forwarding queue and the second forwarding queue, giving priority to packets of data in the second forwarding queue.
3. The method of
4. The method of
5. The method of
indexing into the holding queue based on the time at which the indexing occurs; and
placing a packet at the indexed location of the holding queue into the second forwarding queue.
7. The apparatus of
8. The apparatus of
a forwarding engine in communication with the first queue and the second queue, the forwarding queue to forward packets of data to the network from the first queue and the second queue, giving priority to packets of data in the second queue.
9. The apparatus of
10. The apparatus of
updating an indicator of when it is permissible to send a next packet of data; and
using upon receipt of the next packet of data, the indicator to determine whether it is permissible to forward the next packet of data at the current time.
11. The apparatus
12. The apparatus of
14. The apparatus of
means for forwarding packets of data to the network from the first and second means, and giving priority to packets of data from the second means.
16. The machine-readable medium of
17. The machine-readable medium of
check, prior to placing the packet in the holding queue, whether there is sufficient space in the holding queue for the packet; and
place the packet in the holding queue if there is sufficient space in the holding queue, and otherwise drop the packet.
18. The machine-readable medium of
index into the holding queue based on the time at which the indexing occurs; and
place a packet at the indexed location of the holding queue into the second forwarding queue.
19. The machine-readable medium of
update an indicator of when it is permissible to send a next packet of data; and
use, upon receipt of the next packet of data, the indicator to determined whether it is permissible to forward the next packet at the current time.
20. The machine-readable medium of
|
This is a continuation and claims the benefit of priority of U.S. patent application Ser. No. 09/195,573 filed Nov. 18, 1998, now U.S. Pat. No. 6,608,816.
1. Field of the Invention
The present invention pertains to routing data in a network. More particularly, this invention relates to providing differentiated services using a multi-level queuing mechanism.
2. Background
Computer systems are increasingly becoming commonplace in homes and businesses throughout the world, and are increasingly becoming interconnected via networks. As the number of interconnected computer systems in use increases, so too does the amount of data being transferred by the networks (also referred to as the network “traffic”). Typically, the speed at which data can be transferred over the network decreases as the amount of network traffic increases because more and more data is trying to be transferred over the same amount of network hardware. For some types of data (e.g., phone calls or video conferencing), it is important that the data not be delayed very much during transfer over the network, regardless of the amount of network traffic.
One solution to this network traffic problem that has been presented is the use of “differentiated services” schemes. Generally, the idea of differentiated services is that certain types of data receive preferential treatment over the network, causing it to be transferred over the network faster than other types of data. This preferential treatment can be obtained in a variety of manners, such as by paying a premium price. However, given the amount of data that is typically being transferred over devices in the network, any mechanism to implement differentiated services should operate relatively quickly so as not to impede the transfer of data. Furthermore, care should be taken to ensure that the data that is receiving preferential treatment does not exceed a preconfigured amount or rate (e.g., the amount or rate that has been paid for). Currently, there are no differentiated services implementations that provide quick and efficient handling of differentiated services data.
Thus, a need exists for an improved way to implement differentiated services.
A method and apparatus for providing differentiated services using a multi-level queuing mechanism is described herein. According to one aspect of the present invention, a method for providing differentiated services in a network includes checking whether a packet of data is to receive a preferred level of service, and if the packet is not to receive the preferred level of service, then placing the packet in a first forwarding queue. However, if the packet of data is to receive the preferred level of service then checking whether it is permissible to forward the packet to a device in the network at the current time. If it is permissible to forward the packet to the device at the current time, then placing the packet in a second forwarding queue, otherwise temporarily placing the packet in a holding queue before placing the packet in the second forwarding queue.
According to another aspect of the present invention, an apparatus for providing differentiated services in a network includes first and second forwarding queues for forwarding packets of data to another device in the network, and also includes a holding queue to temporarily store packets of data prior to being placed in the second forwarding queue. The apparatus further includes a policy meter to check whether a packet of data is to receive a preferred level of service, and, if the packet is not to receive the preferred level of service, then to place the packet in the first forwarding queue. However, if the packet of data is to receive the preferred level of service, then the policy meter checks whether it is permissible to forward the packet to the device at the current time. If it is permissible to forward the packet to the device at the current time, then the policy meter places the packet in the second forwarding queue, and otherwise places the packet in the holding queue.
The present invention is illustrated by way of example and not limitation in the figures of the accompanying drawings, in which like references indicate similar elements and in which:
In the following detailed description numerous specific details are set forth in order to provide a thorough understanding of the present invention. However, it will be understood by those skilled in the art that the present invention may be practiced without these specific details. In other instances well known methods, procedures, components, and circuits have not been described in detail so as not to obscure the present invention.
In alternative embodiments, the present invention may be applicable to implementations of the invention in integrated circuits or chip sets, wireless implementations, switching systems products and transmission systems products. For purposes of this application, the terms switching systems products shall be taken to mean private branch exchanges (PBXs), central office switching systems that interconnect subscribers, toll/tandem switching systems for interconnecting trunks between switching centers, and broadband core switches found at the center of a service provider's network that may be fed by broadband edge switches or access multiplexors, and associated signaling, and support systems and services. The term transmission systems products shall be taken to mean products used by service providers to provide interconnection between their subscribers and their networks such as loop systems, and which provide multiplexing, aggregation and transport between a service provider's switching systems across the wide area, and associated signaling and support systems and services.
Some portions of the detailed descriptions which follow are presented in terms of algorithms and symbolic representations of operations on data bits within a computer memory. These algorithmic descriptions and representations are the means used by those skilled in the data processing arts to most effectively convey the substance of their work to others skilled in the art. An algorithm is here, and generally, conceived to be a self-consistent sequence of steps leading to a desired result. The steps are those requiring physical manipulations of physical quantities. Usually, though not necessarily, these quantities take the form of electrical or magnetic signals capable of being stored, transferred, combined, compared, and otherwise manipulated. It has proven convenient at times, principally for reasons of common usage, to refer to these signals as bits, values, elements, symbols, characters, terms, numbers, or the like. It should be borne in mind, however, that all of these and similar terms are to be associated with the appropriate physical quantities and are merely convenient labels applied to these quantities. Unless specifically stated otherwise as apparent from the following discussions, it is appreciated that throughout the present invention, discussions utilizing terms such as “processing” or “computing” or “calculating” or “determining” or “displaying” or the like, refer to the action and processes of a computer system, or similar electronic computing device, that manipulates and transforms data represented as physical (electronic) quantities within the computer system's registers and memories into other data similarly represented as physical quantities within the computer system memories or registers or other such information storage, transmission or display devices.
The present invention makes use of a multi-level queuing structure to provide differentiated services. Packets are forwarded into a network supporting differentiated services by using the multi-level queue structure. A first queue level is a set of forwarding queues into which packets are placed prior to being forwarded into the network. The amount of time a packet remains in the first queue level is dependent on the total number of packets in the first level as well as the rate at which the forwarding device is able to provide packets to the network. Additionally, packets that are to receive a premium service level may also be temporarily placed into a second level queue, referred to as a hold queue, prior to being placed in the first queue level. The present invention ensures that packets are transferred from the hold queue into a first level queue at not higher than a preconfigured rate, and thus that the rate of transfer of premium service level packets to the network does not exceed the preconfigured rate.
Network 110 is configured to provide differentiated services to data packets. According to one embodiment of the present invention, the differentiated services include three different levels of service: best effort service, assured service, and premium service. Best effort service is the lowest level, guaranteeing only that the network will do its best to try and deliver packets of data to their destinations. Currently, many networks (such as the Internet) provide best effort service. Assured service is a higher level of service, ensuring that packets of data are unlikely to be dropped from the network so long as the amount of such data stays within a particular profile (e.g., not larger than a particular size or greater than a particular rate). Premium service is the highest level of service. Packets of data at the premium service level are given preferential treatment through the network, and are almost certain not to be dropped from the network so long as the amount of such data stays within a particular profile (e.g., premium packets are not sent at greater than a particular rate).
It is to be appreciated that network 110 includes multiple components, including any combination of routers, switches, bridges, gateways, workstations, servers, etc. to transfer packets of data. In order to support differentiated services, each of the components within network 110 needs to be able to identify and properly treat packets of different service levels. This can include, for example, the components giving priority to higher service level packets by forwarding them prior to any lower service level packets, or using dedicated paths or channels for higher priority packets. According to one embodiment of the present invention, each of the packets of data being transferred through the network includes a packet header that identifies the service level for the packet. Alternate embodiments can identify service levels in other manners, such as by separate signaling or use of dedicated input and output ports.
According to one embodiment of the present invention, packets of data to be sent using premium and assured service levels are required to conform to particular profiles. For the assured service level, the particular profile identifies a particular “expected capacity” (e.g., not greater than a particular rate, such as 100 k bits per second, or a particular burst rate, such as four packets back-to-back). For the premium service level, the particular profile identifies a particular packet rate that will not be exceeded (e.g., not greater than twenty packets per minute).
Edge devices, such as shaping/metering device 130, operate to ensure that such profiles are not violated. By doing so at the edge devices at which data is being input to network 110, each component within network 110 is not required to verify that packets of data conform to the requirements for their identified level of service.
Thus, in the illustrated embodiment of
It should be noted that devices 121-124 may also provide metering and shaping functionality for packets of data received by the devices from other sources (not shown) to be provided to network 110, as well as for packets of data being forwarded to other destinations by the devices.
As illustrated in
The identifier output from classifier 205 identifies a particular shaper/policy meter to which the packet is forwarded, as well as ultimately a set of forwarding queues and a forwarding engine. For ease of explanation, only a single shaper/policy meter 210 and forwarding engine 230 are illustrated in FIG. 2. It is to be appreciated, however, that a different shaper/policy meter and forwarding engine (as well as holding queue and forwarding queues) can be included for each of the different flows supported by device 130. Although, it is also to be appreciated that in embodiments where shaper/policy meter 210 are implemented in software, various procedures and sections of software code can be shared by different flows.
The packet is then provided to policy meter and shaper 210. Shaper/meter 210 accesses the service type information in the packet header (typically provided by the original source) to determine whether the packet is to receive a preferred level of service. Based on the level of service the packet is to receive, as well as when previous packets of data have been forwarded by device 130, shaper/meter 210 either forwards the packet to shaper 214 for temporary storage in hold queue 218 or to forwarding engine 230.
Shaper/meter 210 is responsible for ensuring that the configured policies for different levels of service are maintained. By way of example, if the owner of a particular source has contracted with the owner of device 130 that the source will not attempt to send greater than x number of premium level packets per minute to device 130 for forwarding to network 110, shaper/meter 210 ensures that this “contracted for” rate is not exceeded. In fact, according to one embodiment of the present invention if the contracted for rate is exceeded then some of the premium level packets may be dropped.
Eventually, packets that are not dropped are forwarded to one of the output queues 232 or 234. The packets are then forwarded on to network 110 from queues 232 and 234 by forwarding engine 230. Packets of data at the premium service level are placed in premium output queue 234, while the packets at the assured or best effort service levels are placed in secondary output queue 232. Forwarding engine 230 controls the forwarding of packets to network 110, with priority being given to packets in premium output queue 234.
According to one embodiment of the present invention, forwarding a packet of data to one of the output queues 232 or 234 is accomplished by sending the packet to forwarding engine 230. The placement of the packet into the proper one of queues 232 and 234, as well as the proper location within that queue, is performed by forwarding engine 230. Forwarding engine 230 may determine the proper one of queues 232 and 234 based on service level information contained in the header of the data packet, or alternatively from parameters received from shaper/meter 210 when the packet is transferred to forwarding engine 230. According to one embodiment of the present invention, each of queues 232 and 234 is a conventional first-in first-out (FIFO) queue.
Forwarding engine 230 can use any of a wide variety of conventional arbitration algorithms for selecting packets from queues 232 and 234 for output to network 110. Examples of such algorithms include giving any packet in premium output queue 234 priority over any packet in secondary output queue 232, and a weighted round robin scheme that favors output queue 234. In the illustrated embodiment, forwarding engine discussed above, the packet header identifies the type of service the packet is to receive, so policy meter 212 can make this determination based on the packet header information.
If the packet is to receive premium service, then policy meter 212 checks whether it is permissible to send the packet at the present time, step 306. In the illustrated embodiment, policy meter 212 maintains a record of when it is permissible to send the next packet, referred to as the “okay to send” value or time. The okay to send time is updated each time policy meter 212 forwards a newly received premium service packet to either premium output queue 234 or holding queue 218. In step 306, policy meter 212 compares the current time to the okay to send time and determines that it is permissible to send the packet at the current time if the current time is greater than or equal to the okay to send time.
If it is permissible to send the packet at the current time, then policy meter 212 marks the packet as “premium service”, step 308. This marking is, according to one embodiment of the present invention, a predetermined bit pattern in the packet header that is expected by the components of network 110 to identify premium service packets. Alternatively, the type of service information in the header that was originally provided to device 130 from the source 135 could be used by the components of network 110, and the marking step not performed.
Policy meter 212 then updates the okay to send time, step 310. The okay to send time is updated to be the current time plus the amount of time necessary to send the packet from the premium output queue 234 to network 110. It should be noted that this amount of time necessary to send the packet is the amount of time necessary to send the packet to network 110 at the “contracted for” rate, which may be longer than the actual time necessary to send the packet to network 110. By way of example, the connection to network 110 may be fast enough to support 50 packets per second, although the contracted for rate is 10 packets per second. Thus, the amount of time necessary to send the packet would be 0.1 seconds (1÷10) rather than 0.02 seconds (1÷50).
In the illustrated embodiment, the amount of time necessary to send the packet from the premium output queue 234 to network 110 is determined based on the actual size of the packet of data (e.g., number of bytes), including any header and/or tail information. According to one embodiment of the present invention, a lookup table is used that includes both the packet size and a corresponding amount of time. This lookup table can be pre-computed, based on the known clock rate being used by policy meter 212 as well as the output transfer rate of device 130 and the contracted for rate. In one implementation, the lookup table includes a different entry for each possible packet size. According to an alternate implementation, ranges of packet sizes are used (e.g., less than 100 bytes, between 100 and 200 bytes, between 200 and 400 bytes, etc.).
After updating the okay to send value, policy meter 212 places the packet into the premium output queue 234, step 312. At this point, forwarding engine 230 is responsible for forwarding the packet to network 110.
Returning to step 306, if it is not permissible to send the packet at the current time, policy meter 212 checks whether there is sufficient space in hold queue 218 to store an additional packet of data, step 314. According to one implementation, the determination of whether there is sufficient space in hold queue 218 is made based on a maximum amount of time into the future that a packet will be held by shaper/meter 210 for placing into the forwarding queue. Policy meter 212 compares the current okay to send time minus the current time to the maximum amount of time into the future that a packet will be held for placing into the forwarding queue. If the current okay to send value minus the current time exceeds the maximum amount of time, then there is insufficient space in hold queue 218. Otherwise, there is sufficient space in hold queue 218.
If policy meter 212 determines that there is insufficient space in hold queue 218, then policy meter 212 drops the data packet, step 316. In other words, the data packet is ignored by device 130 and is not forwarded to network 110. According to an alternate embodiment, rather than dropping the packet, policy meter 212 re-marks the packet (e.g., as best effort, step 334 discussed below), and forwards the packet to network 110 with the new marking.
However, if policy meter 212 determines that there is sufficient space in hold queue 218, then policy meter 212 marks the packet as “premium service”, step 318, analogous to step 308 discussed above. Policy meter 212 then updates the okay to send time, step 320. The okay to send time is updated to be the current okay to send time plus the amount of time necessary to send the packet from the premium output queue 234 to network 110. It should be noted that, analogous to the discussion above, this amount of time necessary to send the packet is the amount of time necessary to send the packet to network 110 at the “contracted for” rate, not necessarily the actual time necessary to send the packet to network 110.
The packet is then placed in the hold queue, step 322. Policy meter 212 forwards the packet as well as the current okay to send time to shaper 214, which in turn places the packet into the hold queue.
Returning to
Upon finding the first available location within the queue, shaper 214 places the packet into that queue location, step 408.
According to one alternate embodiment of the present invention, shaper 214 does not perform step 402. In this alternate embodiment, shaper 214 always places packets into holding queue 218 without regard for the difference between the okay to send time and the current time. According to another alternate embodiment of the present invention, different processes are used to find an available location in holding queue 218. By way of example, different starting locations can be used for starting the search for the first available queue location, or different incrementation values can be used.
Returning to
Returning to step 304 of
If the packet is within the permitted burst size, then policy meter 212 marks the packet as “assured service”, step 330. Analogous to the premium service marking discussed above with reference to step 308, the assured service marking is a predetermined bit pattern in the packet header that is expected by the components of network 110 to identify assured service packets. Policy meter 212 then places the packet into the secondary output queue 232, step 332. At this point, forwarding engine 230 is responsible for forwarding the packet to network 110.
Returning to steps 326 and 328, if policy meter 212 determines that the packet is not to receive assured service (step 326), or that the packet is not within the permitted burst size (step 328), then policy meter 212 marks the packet as “best effort service”, step 334. Analogous to the premium service marking discussed above with reference to step 308, the best effort service marking is a predetermined bit pattern in the packet header that is expected by the components of network 110 to identify best effort service packets. Policy meter 212 then places the packet into the secondary output queue 232, step 332. At this point, forwarding engine 230 is responsible for forwarding the packet to network 110.
In the discussions above, reference is made to various specific units of measurement (e.g., numbers of bytes). Alternate embodiments of the present invention can be based on different units either smaller or larger than the specific units discussed above (e.g., bits or multiple-byte words).
Also in the discussions above, reference is made to three levels of service (premium, assured, and best effort). It is to be appreciated that the present invention is not limited to the use of only three levels of service, and that greater or fewer levels could be implemented. By way of example, the assured level of service need not be included, or additional levels of “preferential” service may be added. It is also to be appreciated that additional holding queues and/or forwarding queues can be added to accommodate such additional levels of service.
Also in the discussions above, reference is made to device 130 of
Also in the discussions above, reference is made to multiple forwarding queues 232 and 234. Alternatively, a single queue could be used with additional control logic in forwarding engine 230 to distinguish between premium and non-premium packets within the single queue. Similarly, rather than having individual forwarding queues 232 and 234 for each flow, a single queue structure could be used with multiple flows, with additional control logic in forwarding engine 230 to distinguish between the different flows.
Also in the discussions above, reference is made to packets being dropped under certain circumstances. For example, if a packet is to receive premium service and the holding queue is full (as discussed with reference to FIG. 3). According to alternate embodiments, such packets may be re-classified (e.g., to best effort service) rather than being dropped. Similarly, reference is made to packets being re-classified in certain under certain circumstances (e.g., a packet to receive assured service is not within a permitted burst size). According to alternate embodiments, such packets may be dropped rather than re-classified.
Therefore, a method and apparatus for providing differentiated services using a multi-level queuing mechanism has been described. Packets of data that are to receive a premium level of service can be temporarily stored in a holding queue prior to being placed in a forwarding queue and subsequently transferred over the network. The temporary storage of the packets allows the device to ensure that a particular transfer rate of premium packets is not exceeded. Furthermore, the placement of premium level packets into the holding queue, and thus the determination of when it is okay to send the packets, is done in a quick manner employing simple addition.
Thus, a method and apparatus for providing differentiated services using a multilevel queuing mechanism has been described. Whereas many alterations and modifications of the present invention will be comprehended by a person skilled in the art after having read the foregoing description, it is to be understood that the particular embodiments shown and described by way of illustration are in no way intended to be considered limiting. References to details of particular embodiments are not intended to limit the scope of the claims.
Patent | Priority | Assignee | Title |
10038567, | Sep 24 2004 | Fortinet, Inc. | Scalable IP-services enabled multicast forwarding with efficient resource utilization |
10169948, | Jan 31 2014 | International Business Machines Corporation | Prioritizing storage operation requests utilizing data attributes |
10200275, | Nov 18 2002 | Fortinet, Inc. | Hardware-accelerated packet multicasting |
7161904, | Jun 04 2002 | GOOGLE LLC | System and method for hierarchical metering in a virtual router based network switch |
7203192, | Jun 04 2002 | Cisco Technology, Inc | Network packet steering |
7266120, | Nov 18 2002 | Fortinet, INC | System and method for hardware accelerated packet multicast in a virtual routing system |
7278055, | Aug 29 2002 | GOOGLE LLC | System and method for virtual router failover in a network routing system |
7283536, | Jun 11 2002 | Nokia Corporation | Multimode queuing system for DiffServ routers |
7286482, | Nov 29 2002 | WSOU Investments, LLC | Decentralized SLS monitoring in a differentiated service environment |
7340535, | Jun 04 2002 | Fortinet, INC | System and method for controlling routing in a virtual router system |
7376125, | Jun 04 2002 | Fortinet, INC | Service processing switch |
7522604, | Jun 04 2002 | GOOGLE LLC | Routing traffic through a virtual router-based network switch |
7539744, | Sep 13 2000 | Cisco Technology, Inc | Network operating system for maintaining redundant master control blade management information |
7580373, | Jun 28 2001 | Fortinet, Inc. | Identifying nodes in a ring network |
7668087, | Jun 04 2002 | GOOGLE LLC | Hierarchical metering in a virtual router-based network switch |
7707271, | Apr 19 2001 | British Telecommunications | Delivering personalized content data via local network |
7720053, | Jun 04 2002 | Fortinet, Inc. | Service processing switch |
7761743, | Aug 29 2002 | GOOGLE LLC | Fault tolerant routing in a non-hot-standby configuration of a network routing system |
7818236, | Sep 13 2004 | NYSE GROUP, INC | System for aggregating executions in a communication network for securities transactions and the like |
7843813, | Nov 18 2004 | Fortinet, INC | Managing hierarchically organized subscriber profiles |
7869361, | Nov 18 2004 | Fortinet, INC | Managing hierarchically organized subscriber profiles |
7876683, | Nov 18 2004 | Fortinet, INC | Managing hierarchically organized subscriber profiles |
7881244, | Sep 24 2004 | Fortinet, Inc. | Scalable IP-services enabled multicast forwarding with efficient resource utilization |
7885207, | Sep 13 2000 | Fortinet, Inc. | Managing and provisioning virtual routers |
7890663, | Jun 28 2001 | Fortinet, Inc. | Identifying nodes in a ring network |
7912936, | Sep 13 2000 | Managing interworking communications protocols | |
7961615, | Nov 18 2004 | Fortinet, INC | Managing hierarchically organized subscriber profiles |
8064354, | Jul 21 2010 | INTELEPEER CLOUD COMMUNICATIONS LLC | Optimized path call routing with device identifier |
8064462, | Jun 04 2002 | Fortinet, Inc. | Service processing switch |
8068503, | Jun 04 2002 | Cisco Technology, Inc | Network packet steering via configurable association of processing resources and netmods or line interface ports |
8069233, | Sep 13 2000 | Cisco Technology, Inc | Switch management system and method |
8111690, | Jun 04 2002 | GOOGLE LLC | Routing traffic through a virtual router-based network switch |
8208409, | Jun 28 2001 | Fortinet, Inc. | Identifying nodes in a ring network |
8213347, | Sep 24 2004 | Fortinet, Inc. | Scalable IP-services enabled multicast forwarding with efficient resource utilization |
8250357, | Sep 13 2000 | Fortinet, INC | Tunnel interface for securing traffic over a network |
8255510, | Sep 13 2000 | Cisco Technology, Inc | Switch management system and method |
8260918, | Sep 13 2000 | Fortinet, Inc. | Packet routing system and method |
8260959, | Jan 31 2002 | British Telecommunications public limited company | Network service selection |
8306040, | Jun 04 2002 | Cisco Technology, Inc | Network packet steering via configurable association of processing resources and network interfaces |
8320279, | Sep 13 2000 | Fortinet, Inc. | Managing and provisioning virtual routers |
8369258, | Sep 24 2004 | Fortinet, Inc. | Scalable IP-services enabled multicast forwarding with efficient resource utilization |
8412982, | Aug 29 2002 | GOOGLE LLC | Fault tolerant routing in a non-hot-standby configuration of a network routing system |
8503463, | Aug 27 2003 | Fortinet, Inc. | Heterogeneous media packet bridging |
8542595, | Jun 04 2002 | Fortinet, Inc. | Service processing switch |
8638802, | Jun 04 2002 | Cisco Technology, Inc | Network packet steering via configurable association of packet processing resources and network interfaces |
8644311, | Nov 18 2002 | Fortinet, Inc. | Hardware-accelerated packet multicasting in a virtual routing system |
8819486, | Aug 29 2002 | GOOGLE LLC | Fault tolerant routing in a non-hot-standby configuration of a network routing system |
8848718, | Jun 04 2002 | GOOGLE LLC | Hierarchical metering in a virtual router-based network switch |
9065741, | Sep 25 2003 | Cisco Technology, Inc. | Methods and apparatuses for identifying and alleviating internal bottlenecks prior to processing packets in internal feature modules |
9124555, | Sep 13 2000 | Fortinet, Inc. | Tunnel interface for securing traffic over a network |
9143351, | Jun 28 2001 | Fortinet, Inc. | Identifying nodes in a ring network |
9160716, | Sep 13 2000 | Fortinet, Inc. | Tunnel interface for securing traffic over a network |
9166805, | Sep 24 2004 | Fortinet, Inc. | Scalable IP-services enabled multicast forwarding with efficient resource utilization |
9167016, | Sep 24 2004 | Fortinet, Inc. | Scalable IP-services enabled multicast forwarding with efficient resource utilization |
9215178, | Jun 04 2002 | Cisco Technology, Inc. | Network packet steering via configurable association of packet processing resources and network interfaces |
9258280, | Sep 13 2000 | Fortinet, Inc. | Tunnel interface for securing traffic over a network |
9319303, | Sep 24 2004 | Fortinet, Inc. | Scalable IP-services enabled multicast forwarding with efficient resource utilization |
9391964, | Sep 13 2000 | Fortinet, Inc. | Tunnel interface for securing traffic over a network |
9407449, | Nov 18 2002 | Fortinet, Inc. | Hardware-accelerated packet multicasting |
9509638, | Aug 27 2003 | Fortinet, Inc. | Heterogeneous media packet bridging |
9602303, | Jun 28 2001 | Fortinet, Inc. | Identifying nodes in a ring network |
9667604, | Sep 13 2000 | Fortinet, Inc. | Tunnel interface for securing traffic over a network |
9853917, | Aug 27 2003 | Fortinet, Inc. | Heterogeneous media packet bridging |
9853948, | Sep 13 2000 | Fortinet, Inc. | Tunnel interface for securing traffic over a network |
9967200, | Jun 04 2002 | Fortinet, Inc. | Service processing switch |
9998337, | Jun 28 2001 | Fortinet, Inc. | Identifying nodes in a ring network |
Patent | Priority | Assignee | Title |
5754529, | Sep 28 1994 | Siemens Aktiengesellschaft | Method and circuit arrangement for forwarding message unit cells supplied from an ATM communication equipment |
5996019, | Jul 19 1995 | FUJITSU LIMITED, A JAPANESE CORPORATION | Network link access scheduling using a plurality of prioritized lists containing queue identifiers |
6137807, | Dec 05 1997 | Whittaker Corporation | Dual bank queue memory and queue control system |
6205150, | May 28 1998 | Hewlett Packard Enterprise Development LP | Method of scheduling higher and lower priority data packets |
20010009552, | |||
20010010692, | |||
EP810809, |
Executed on | Assignor | Assignee | Conveyance | Frame | Reel | Doc |
Sep 10 2002 | Nortel Networks Limited | (assignment on the face of the patent) | / | |||
Jul 29 2011 | Nortel Networks Limited | Rockstar Bidco, LP | ASSIGNMENT OF ASSIGNORS INTEREST SEE DOCUMENT FOR DETAILS | 027164 | /0356 | |
May 09 2012 | Rockstar Bidco, LP | Rockstar Consortium US LP | ASSIGNMENT OF ASSIGNORS INTEREST SEE DOCUMENT FOR DETAILS | 032170 | /0591 | |
Nov 13 2013 | Rockstar Consortium US LP | Bockstar Technologies LLC | ASSIGNMENT OF ASSIGNORS INTEREST SEE DOCUMENT FOR DETAILS | 032399 | /0116 | |
Jan 28 2015 | Constellation Technologies LLC | RPX CLEARINGHOUSE LLC | ASSIGNMENT OF ASSIGNORS INTEREST SEE DOCUMENT FOR DETAILS | 034924 | /0779 | |
Jan 28 2015 | NETSTAR TECHNOLOGIES LLC | RPX CLEARINGHOUSE LLC | ASSIGNMENT OF ASSIGNORS INTEREST SEE DOCUMENT FOR DETAILS | 034924 | /0779 | |
Jan 28 2015 | MOBILESTAR TECHNOLOGIES LLC | RPX CLEARINGHOUSE LLC | ASSIGNMENT OF ASSIGNORS INTEREST SEE DOCUMENT FOR DETAILS | 034924 | /0779 | |
Jan 28 2015 | Bockstar Technologies LLC | RPX CLEARINGHOUSE LLC | ASSIGNMENT OF ASSIGNORS INTEREST SEE DOCUMENT FOR DETAILS | 034924 | /0779 | |
Jan 28 2015 | ROCKSTAR CONSORTIUM LLC | RPX CLEARINGHOUSE LLC | ASSIGNMENT OF ASSIGNORS INTEREST SEE DOCUMENT FOR DETAILS | 034924 | /0779 | |
Jan 28 2015 | Rockstar Consortium US LP | RPX CLEARINGHOUSE LLC | ASSIGNMENT OF ASSIGNORS INTEREST SEE DOCUMENT FOR DETAILS | 034924 | /0779 | |
Feb 26 2016 | RPX CLEARINGHOUSE LLC | JPMORGAN CHASE BANK, N A , AS COLLATERAL AGENT | SECURITY AGREEMENT | 038041 | /0001 | |
Feb 26 2016 | RPX Corporation | JPMORGAN CHASE BANK, N A , AS COLLATERAL AGENT | SECURITY AGREEMENT | 038041 | /0001 | |
Dec 22 2017 | JPMORGAN CHASE BANK, N A | RPX Corporation | RELEASE REEL 038041 FRAME 0001 | 044970 | /0030 | |
Dec 22 2017 | JPMORGAN CHASE BANK, N A | RPX CLEARINGHOUSE LLC | RELEASE REEL 038041 FRAME 0001 | 044970 | /0030 |
Date | Maintenance Fee Events |
Aug 24 2005 | ASPN: Payor Number Assigned. |
Sep 30 2008 | M1551: Payment of Maintenance Fee, 4th Year, Large Entity. |
Feb 25 2013 | M1552: Payment of Maintenance Fee, 8th Year, Large Entity. |
Apr 21 2017 | REM: Maintenance Fee Reminder Mailed. |
Oct 09 2017 | EXP: Patent Expired for Failure to Pay Maintenance Fees. |
Date | Maintenance Schedule |
Sep 13 2008 | 4 years fee payment window open |
Mar 13 2009 | 6 months grace period start (w surcharge) |
Sep 13 2009 | patent expiry (for year 4) |
Sep 13 2011 | 2 years to revive unintentionally abandoned end. (for year 4) |
Sep 13 2012 | 8 years fee payment window open |
Mar 13 2013 | 6 months grace period start (w surcharge) |
Sep 13 2013 | patent expiry (for year 8) |
Sep 13 2015 | 2 years to revive unintentionally abandoned end. (for year 8) |
Sep 13 2016 | 12 years fee payment window open |
Mar 13 2017 | 6 months grace period start (w surcharge) |
Sep 13 2017 | patent expiry (for year 12) |
Sep 13 2019 | 2 years to revive unintentionally abandoned end. (for year 12) |