Multiplex communications – Channel assignment techniques – Combining or distributing information via time channels...
Reexamination Certificate
1998-12-28
2002-03-05
Zimmerman, Brian A. (Department: 2735)
Multiplex communications
Channel assignment techniques
Combining or distributing information via time channels...
C370S389000, C370S395200, C370S412000, C709S241000, C709S241000, C709S226000
Reexamination Certificate
active
06353616
ABSTRACT:
BACKGROUND OF THE INVENTION
1. Field of the Invention
The present invention relates to packet networks, and, more particularly, to scheduling of control protocol message processing by a router.
2. Description of the Related Art
Packet networks, such Internet Protocol (IP) based networks, are increasingly providing differentiated services. One approach for providing differentiated services employs type-of-service (TOS) bits defined in the packet header. Routers within the packet network interpret the TOS bits in a predetermined manner so as to provide the differentiated services. Another approach, which is a reservation-based approach, employs control messages to reserve network resources for the duration of a connection defined by a packet flow, or packet flow aggregates (“flows”). For this reservation-based approach, a protocol that may be employed to signal reservation of network resources is the Reservation Setup Protocol (RSVP). RSVP, as an example, may be used in conjunction with service models, such as guaranteed rate and controlled load service models, to request a desired quality of service (QOS) for certain packet flows.
RSVP is a receiver-oriented resource reservation protocol: reservations are initiated when a source (sender) requests a resource reservation, such as a reservation for a certain amount of bandwidth of a transmission line or logical link during connection set-up or during an established connection. This RSVP request is signaled through the network using a PATH message. The PATH message is routed along the network to its destination (or set of destinations) through a series of routers in a similar manner to that of other IP packets. However, before propagating a PATH message, each router checks if sufficient requested resources are available. If the requested resources are available, the router first establishes a flow-state for the packet flow (or aggregated flows) indicated by this request and then propagates the PATH message. The packet flow in progress is maintained by periodic UPDATE messages generated by the source. Also, each intermediate router, and the destination, starts a counter, or refresh timer, that is employed to generate a processor interrupt causing termination of the packet flow if no RESV or UPDATE messages are received for the packet flow before timer expires.
When the PATH message reaches the desired destination (recipient), the destination sends back a RESV message through the network to the source. The RESV message may be, for example, a bandwidth request that may be different from the bandwidth requested in the PATH message. When an intermediate router of the network receives a RESV message for which there is an established packet flow for a connection, the intermediate router commits the requested bandwidth to the packet flow. From the point-of-view of this intermediate router, the packet flow is now in progress. Each PATH and RESV message received by the intermediate router, and destination, resets the refresh timer. Periodic UPDATE messages are generated by the source and received by each router. Each router, upon processing of UPDATE messages, resets its refresh timer and propagates the UPDATE message. A packet flow is terminated, the connection torn-down, and the reserved resources released by an intermediate router (or the destination) when either an explicit TEAR-DOWN message generated by the source or destination is received, or when a refresh timer expires.
RSVP facilitates exchange of resource reservation information among routers in the packet network and is a soft-state protocol which relies upon periodic refresh message requests (UPDATE messages) to maintain router state information. Refresh messages that are not sent or processed within the period cause the established packet flow to be terminated. The periodic refresh messages, and consequent soft state information in the routers, permit the RSVP protocol to operate robustly in the presence of packet flow route changes and lost signaling messages, without requiring explicit messages to terminate the packet flow. Soft state protocols, such as RSVP, allow packet networks to provide services comparable to those in virtual circuit networks with explicit connection establishment and termination.
However, the processing section of each router must process the periodic refresh messages. Router processing load increases with the number of established RSVP packet flows passing through the router, even if these RSVP packet flows are not actively sending packets. The RSVP message load offered to the processing section comprises i) message requests due to RSVP reservation connection establishment and termination and ii) message requests due to refresh messages generated by established RSVP packet flows. Even though refresh messages consume a relatively small capacity of the processing section, the offered processor load due to refresh messages increases as the number of in-progress RSVP packet flows increases through the router. Even if an “adequate” control processor with capacity determined by traffic engineering rules is employed in the processing section, temporary overloading of the control processor may occur. Such temporary overloading may result from a “mass call-in” that generates a relatively large number of new reservation message requests for connection establishment or termination within a relatively short period of time. In addition, the control processor does not necessarily process RSVP message requests alone, but may also handle other routing tasks. With a burst of routing instabilities, and recalculations of network routes, for example, these routing tasks may require considerable portion of available processing capacity, causing a bottleneck in processing of RSVP message requests. Consequently, reservation blocking is possible even though link capacity may be available.
Appropriate scheduling of message processing by the processing section may be used to maximally utilize the link capacity within the constraints of the available processing resources. For example, consider the case when the link-utilization is relatively high. Processing PATH or RESV messages before processing TEAR-DOWN messages is not advantageous since available bandwidth is unlikely to satisfy these new requests. Therefore, for the high-link utilization case, processing TEAR-DOWN messages in the router's queue before processing PATH messages is beneficial. However, routers of the prior art employ scheduling that is not link sate dependant, such as First In First Out (FIFO) processing. Similarly, for the case when link-utilization is relatively low, processing of TEAR-DOWN messages may be deferred, allowing scarce processing resources to process new PATH and RESV messages. However, this deference is similarly not adopted by FIFO scheduling. Furthermore, giving priority to UPDATE message processing is desirable since deferment of UPDATE message processing may result in expiration of the refresh timer, and so terminate the packet flow, in the router or in downstream routers.
SUMMARY OF THE INVENTION
The present invention relates to allocation of processing capacity to processing control messages of a router in a packet network. A link utilization value of a link coupled to the router is monitored, and a message request size and a corresponding weight for at least one class of control messages are calculated. Each weight is calculated based on the link utilization value and the message request size of each class. A portion of the processing capacity of the router is allocated for each class of control messages based on the corresponding weight of the class.
REFERENCES:
patent: 5774668 (1998-06-01), Choquier
patent: 5915095 (1999-06-01), Miskowiec
patent: 6167049 (2000-12-01), Pei
patent: 6262976 (2001-07-01), McNamara
patent: 2001/0018701 (2001-08-01), LiVecchi
Elwalid Anwar I.
Lakshman T. V.
May Martin
Hughes Ian M.
Lucent Technologies - Inc.
Mendelsohn Steve
Zimmerman Brian A.
LandOfFree
Adaptive processor schedulor and method for reservation... does not yet have a rating. At this time, there are no reviews or comments for this patent.
If you have personal experience with Adaptive processor schedulor and method for reservation..., we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Adaptive processor schedulor and method for reservation... will most certainly appreciate the feedback.
Profile ID: LFUS-PAI-O-2816325