	REQUESTED
SESSION	RESERVED	SESSION PATH
IDENTIFICATION	BANDWIDTH	(PORT-TO-PORT)

“A”	100 Kbps	Input Port 505-Output Port 506
“B”	64 Kbps	Input Port 505-Output Port 506
“C”	132 Kbps	Input Port 505-Output Port 506

As shown in Table 1, the request511 (FIG. 5) for the “A” session203 (i.e., hosts sending and receiving this stream or flow of data) indicates that 100 Kbps of bandwidth is to be reserved, while the “B”session204 has requested 64 Kbps of bandwidth, and the “C”session205 has requested 132 Kbps. In this example, each of these flows or sessions of data communication “A”202, “B”204 and “C”205 are traveling on the same path through thedevice201 configured with thesender state data504 in Table 1. In other words, in the example embodiment shown inFIG. 5, an assumption is made that queue340-1 services a single path within thedata communications device201. For example, queue340-1 may be associated with theoutput port506. Assuming there are many output ports in thedevice201, each output port (e.g.506) in this embodiment thus has its own associated queue structure similar to340-1 provided in order to buffer or store data packets (e.g.,packets203 through206) that are to be transported from that output port onto thenetwork200.

To assist in the explanation of the operation of this example embodiment, it is also assumed that the maximum total bandwidth for theoutput port506 is 400 Kbps. Thus when thedata scheduler320, queue340-1 anddequeuing mechanism350 all operate at peak capacity, a maximum bandwidth or throughput of 400 Kbps is available from theoutput port506.

To configure bandwidth reservations for each flow or session of data communication (e.g., “A”, “B”, “C”) defined in thesender state data504, thebandwidth labeler550 in this embodiment includes aresource allocation calculator552, a resource allocation table553, and alabel calculator554.

Theresource allocation calculator552 creates labeling information that is maintained in the resource allocation table553 based on thesender state data504. To do so, in this embodiment, theresource allocation calculator552 obtains asinput560 the size and speed of rotation of the data storage mechanism340 (e.g. queue340-1). Essentially, theresource allocation calculator553 calculates and stores a percentage of total bandwidth (for the path to theoutput port506 in this example) to allocate or reserve for each session of data communication based on thesender state data504 as defined by the received bandwidth reservation requests511.

FIG. 6A illustrates an example of the contents of the resource allocation table553. In Column1 “FLOW ID”, the resource allocation table553 provides an identification of each flow or session of data communication (e.g., “A”, “B”, “C”), and includes an entry marked “U” representing resource allocation data for all data (e.g. packets206) not specifically associated with any session or reserved bandwidth.Column2 “PERCENT UTILIZATION” indicates a percent utilization of total bandwidth for the queue340-1 to which this resource allocation table553 is associated.Column3 “ENTRY COUNT OF TOTAL QUEUE SIZE” indicates the number ofqueue entries345 that should be labeled in the queue340-1 for each particular flow (i.e., row) represented in the resource allocation table553.

As noted above, theresource allocation calculator552 obtains as input the queue size andspeed data560 from thedata storage mechanism340. Using this information in conjunction with thesender state data504, theresource allocation calculator552 computes PERCENT UTILIZATION and ENTRY COUNT OF TOTAL QUEUE SIZE values for each flow or session of data communication (e.g., “A”203, “B”204, “C”205) in thesender state data504.

Theresource allocation calculator552 computes PERCENT UTILIZATION by converting the requested bandwidth to be reserved for each data flow or session to a percentage of total bandwidth for the queue340-1. In this embodiment, the queue size/speed data560 determines total bandwidth for the path. In this example, the queue340-1 has a queue size equal to twelvequeue entries345. Eachentry345 can store one packet (e.g., onepacket203 through206). A packet size in this embodiment is assumed to constant at 1000 bits. The queue speed in this example is assumed to be 33⅓ rotations per second. Based on these values, the total bandwidth for this queuing structure340-1 can be computed as follows:
QUEUE_BANDWIDTH=TOTAL_NUMBER_OF_ENTRIES*ENTRY_SIZE*ROTATIONS_PER_SECOND.

Or for this particular embodiment, overall total queue bandwidth equals:
400Kbps=(12 Queue entries)*(1000 bit entry size)*(33⅓ Rotations per second).

Once the total queue bandwidth is calculated, PERCENT UTILIZATION may be calculated as follows:
PERCENT UTILIZATION=REQUESTED_BANDWIDTH_PER_FLOW/QUEUE_BANDWIDTH.

In the example embodiment, since the overall queue bandwidth is 400 Kbps using the requested reserved bandwidth values from Table 1 (sender state data504), the PERCENT UTILIZATION for each FLOW ID for flows “A”, “B” and “C” (203 through205) is computed as follows:



	FLOW ID A	.25 = 100 Kbps/400 Kbps
	FLOW ID B	.16 = 64 Kbps/400 Kbps
	FLOW ID C	.33 = 132 Kbps/400 Kbps
	Total Reserved:	.74 * 100 = 74 Percent.

Any remaining bandwidth, expressed as a percentage (i.e., 100 percent−Total Reserved percentage), is allocated to all unreserved data packets206 (e.g. all data with FLOW ID=“U”). In this example, data associated with FLOW ID “U” gets 26 percent of the total bandwidth, since that is the remaining amount of bandwidth not reserved to the sessions ofdata communication203 through205.

Theresource allocation calculator552 computes ENTRY COUNT OF TOTAL QUEUE SIZE (Column3) values in the resource allocation table553 based on the percent utilization of each FLOW ID in proportion to the number oftotal queue entries345 in the queue340-1. The final result may be rounded or the allocation can be adjusted over each rotation of the data storage mechanism340-1 so the average transmission rate converges to the correct percentage. Specifically, in this example embodiment:
ENTRY COUNT OF TOTAL QUEUE SIZE=PERCENT UTILIZATION*TOTAL_NUMBER_OF_ENTRIES.

In the example embodiment, since there are twelvequeue entries345 in the queue340-1, the ENTRY COUNT OF TOTAL QUEUE SIZE values are computed as follows:



	FLOW ID A	3 = .25 * 12
	FLOW ID B	2 = .16 * 12
	FLOW ID C	4 = .33 * 12
	FLOW ID U	3 = .25 * 12
	TOTAL LABELED	12

Once theresource allocation calculator552 computes the data in the resource allocation table553, thelabel calculator554 can use the resource allocation table553 to properly produce labels (e.g.,555) for thequeue entries345 in the queue340-1. As indicated inFIG. 5, thelabel calculator554 accesses the resource allocation table553 to determine howmany entries345 are to be labeled with each particular session identification label or FLOW ID which identifies the session (FIG. 6A). As indicated in the example resource allocation table553 inFIG. 6A, thelabel calculator552 labels threequeue entries345 with “A”, twoqueue entries345 with “B”, fourqueue entries345 with “C”, and threequeue entries345 with “U”, for a total of twelve labeled queue entries that make up the total queue340-1.

FIG. 6B illustrates in more detail an example structure of thequeue entries345 that make up the queue340-1. Each entry345-1,345-2 and345-3 is essentially a data storage location346-1,346-2,346-3 that includes an associated label portion555-1,555-2 and555-3, respectively. The data scheduler321 deposits the data (i.e. packets310) into the datastorage location portion346 of theentry345 in this figure. As indicated in this sample segment of thequeue340, the data storage location346-1 for queue entry345-1 currently stores an A-PACKET310-1 that is associated with the “A” session of data communication203 (FIG. 5), while the data storage location346-2 for queue entry345-2 stores a B-PACKET310-2 that is associated with the “B” session of data communication204 (FIG. 5), and the data storage location346-3 for queue entry345-3 stores a C PACKET310-3 that is associated with the “C” session ofdata communication205. These packets310-1,310-2 and310-3 are stored in these respective locations346-1,346-2 and346-3 because the labels for these locations555-1,555-2 and555-3 created by thelabel calculator554 in thebandwidth labeler550 match the session or flow identification information contained in theheader180 of each packet310-1,310-2 and310-3. That is, thedata scheduler320 places the A-packet310-1 into the location346-1 because the label555-1 indicates that the location346-1 is reserved for “A”data203.

Accordingly, by labeling thedata storage locations345 that form the queue340-1 with theappropriate labels555 for each flow identification (FLOW ID, Column1) specified in the resource allocation table553, thebandwidth labeler550 can constantly maintain the appropriate amount of reserved bandwidth for each session of

data communication

203,204,205. Thedata scheduler320 uses theentries345 that are either unlabeled by thebandwidth labeler550 or that are labeled with a “U” (signifying unreserved or unlabeled), as indicated bylabel556 inFIG. 5, to deposit any data (e.g. data packets206) that does not contain a flow or session identification.

In this embodiment, thebandwidth labeler550 can continuously monitor thesender state data504 for changes in bandwidth requests (i.e., bandwidth reservations or changes that have been granted by the bandwidth daemon501) for any session of data communication (e.g.203,204,205). Once a change is detected in thesender state data504, theresource allocation calculator552 recalculates the values in the resource allocation table553. Thelabel calculator554 detects this change and then correspondingly alters the labeling of thequeue entries345 to effectuate the requested bandwidth change.

In this manner, the system of the invention allows bandwidth to be dynamically adjusted without affecting thedata scheduler320. That is, since thebandwidth reservation processor500 adjusts a proportionate number of

labels

555,556, etc. for sessions of data communication within thequeue entries345, the maximum allowable bandwidth for the sessions (e.g.203,204 or205 in this example) is inherently governed, since thedata scheduler320 can only place as many packets of session data (i.e.310) into labeledqueue entries345 as there are matchinglabels555 associated with theentries345.

By isolating the operation of thedata scheduler320 from thebandwidth reservation processor500 as shown in the previous embodiments, it has been illustrated how bandwidth may be reserved and adjusted dynamically at any time before, during, or after one or more sessions of data communication (e.g.203 through205) are in operation. Once thedata scheduler320 queues a data packet310 for a session of data communication in the queue340-1, the data310 remains in thedata storage location346 until it is dequeued by dequeuingmechanism350. Thelabel calculator554 in this embodiment only labels555 or changes labels ofqueue entries345 that do not already contain data310. In this manner, thedata scheduler320 and queue340-1 operate in continuously the same manner. This allows any session data in the “pipeline” comprising theinput port505,data scheduler320, queue340-1,dequeuing mechanism350, andoutput port506 to remain undisturbed during a change in bandwidth.

Recall that prior art implementations of bandwidth reservation require a session of data communication to be broken or halted for a period of time while classification, scheduling, queuing, and dequeuing mechanism are all reconfigured to handle the new bandwidth requirements. Once reconfigured, the session can then be reinstated. The system of the invention avoids much of this effort and allows the session to be continually transmitted before, during and after bandwidth allocations or adjustments. The adjustments take effect dynamically as the new label configurations for thedata storage locations345 in queue340-1 are used. Thus thebandwidth labeler550 can dynamically re-labelqueue entries345 and the new labels are used by thedata scheduler320 to deposit session data.

An example highlights the particular importance of this aspect of the invention. Suppose that thedevice201 is currently transporting the “B”session204 of data communication at a maximum bandwidth of 64 Kbps, as illustrated inFIG. 5 and in the resource allocation table in553 inFIG. 6A. Next assume that the “B”stream204 requires more bandwidth. The new bandwidth required might be, for example, 100 Kbps. This may be sensed by one of the receiving hosts205-A2,205-A3 (FIG. 3), for example, that determines that the current allocation of 64 Kbps is insufficient and that an additional 36 Kbps would correct the situation. Using RSVP or another bandwidth reservation protocol, thebandwidth request handler520 receives the request for additional bandwidth511 (either a request for an additional 36 Kbps, or a request for a change from 64 Kbps to 100 Kbps, or a new reservation request for 100 Kbps for the “B” stream).

Assuming thebandwidth daemon501 grants therequest511, thesender state data504 for the SESSION IDENTIFICATION “B” indicates a REQUESTED RESERVED BANDWDITH value of 100 Kbps. Theresource allocation calculator552 detects the change in thesender state data504 and updates the resource allocation table553 as explained above so that FLOW ID “B,” (which was set at 16 percent with 2 queue entries labeled with “B”), now contains a PERCENT UTILIZATION value of 0.25 (or 25 percent of the total 400 Kbps bandwidth for this path) and an ENTRY COUNT OF TOTAL QUEUE SIZE value of 3. When the resource allocation table553 is updated in this manner, thelabel calculator554 detects the change and begins to re-label thequeue entries345 according to the new information in the resource allocation table553. Once thelabel calculator554 re-labels allentries345 in the queue340-1, threeentries345 are labeled with a “B” instead of two as in the previous configuration. Note that thelabel calculator554 preferably operates to re-labelqueue entries345 just after thedequeuing mechanism350 removes the data (310 inFIG. 6B) from eachentry345. The “X” in thedata storage location346 inFIG. 5 indicates that thequeue entry346 is now void of any data packet310 and can be re-labeled if required.

Alternative embodiments of the invention provide that thelabel calculator554 always operates to continuously labelentries345 according to the resource allocation table553. In this manner, if the number of labels required for all sessions having reserved data exceeds the total number ofqueue entries345 in the overall queue340-1, eachentry345 is provided with a different label upon being emptied by thedequeuing mechanism350. In other words, if therotation speed560 of a short queue340-1 (i.e. a queue340-1 having sofew entries345 that allentries345 combined cannot hold the total amount of reserved bandwidth) is fast enough, thelabel calculator554 can simply provide labels for everyentry345 after that entry passes thedequeuing mechanism350. In this manner, a short queue changes its labeling configuration with each rotation, and the label calculator controls the bandwidth allocation for each session via the labels for theentries345.

All data packets (e.g., packets forsessions203 through205 and unreserved data packets206) that currently exist in the queue340-1 during the labeling process remain queued and eventually propagate their way to thedequeuing mechanism350. Preferably, relabeling takes place as soon as eachentry345 in the queue340-1 is emptied or dequeued of its data packet310 by thedequeuing mechanism350. As the relabeledqueue entries345 make their way clockwise around to thedata scheduler320 to obtain more data packets310, the new labeling configuration (i.e., the queue340-1 now containing three “B” labeled entries345) will dictate what data can be placed into whichentries345. In this manner, the bandwidth can be changed for the session ofdata communication204 without disrupting the transport of data for the session.

FIG. 7 illustrates the processing steps performed by thebandwidth request handler520 configured according to this invention. Instep600, thebandwidth allocation request511 is obtained from thenetwork200. Instep601, thebandwidth daemon501 determines the requested resource availability via admission control. If the requested resource is not available, thebandwidth daemon501 processing denies the request and returns to step600. If thebandwidth daemon501 instep601 does not deny the request, thebandwidth daemon501 instep602 authenticates access to the requested resource via policy control. If instep602 thebandwidth daemon501 determines that the access should not be granted to the requested resource, thebandwidth daemon501 denies the request and processing returns to step600. If

steps

601 and602 pass,step602 directs processing depending upon the type of request (511) received. If therequest511 is a new request to reserve bandwidth for a session that does not yet have bandwidth reserved, the processing proceeds to step603 and thebandwidth daemon501 produces the newsender state data504 for a session identification associated with the newly requested resource. If however step602 determines that therequest511 is requesting alteration of a resource already reserved to a particular session or sessions of data communication, then processing follows as explained instep604.

Instep604, thebandwidth daemon501 updates thesender state data504 that already exists for the requested resource, without disturbing any session or sessions of data communication that may be using that resource (i.e., without notifying the data scheduler320). Instep605, thebandwidth daemon501 makes thesender state data504 available to thebandwidth labeler550 so that thebandwidth labeler550 can label (e.g.,555) the data storage locations (e.g., entries345) accordingly in thedata storage mechanism340, which is preferably the rotating queue structure340-1 discussed above. By making thesender state data504 available to thebandwidth labeler550, thebandwidth request handler520 can focus its operation primarily on bandwidth request processing and does not need to make thesender state data504 available to other components of the system, such as thedata scheduler320 or thedequeuing mechanism350.

FIG. 8A shows the general processing steps performed by theresource allocation calculator552 in thebandwidth labeler550 according to one embodiment of the invention. Instep700, theresource allocation calculator552 queries thesender state database504. Alternatively, step700 may be performed by having any changes in thesender state data504 be signaled (i.e., viastep605 inFIG. 7) to theresource allocation calculator552. Instep701, current statistics of thedata storage mechanism340 such as queue size (e.g., total number of entries345) and speed (e.g., how many entries are dequeued over a period of time, rotation, etc.) are queried to determine the overall current bandwidth characteristics for the requested path. Step702 then calculates and/or updates the resource allocation table553 values (Columns1,2 or3) with the current session attributes, as explained above. In this manner, the processing ofFIG. 8A converts thesender state data504 into meaningful data usable by thelabel calculator554 to label (555 inFIG. 6B) the data storage location346 (i.e., queue entries345) in the data storage mechanism340 (e.g., queue340-1).

FIG. 8B shows the general processing steps associated with thelabel calculator554. Instep750, thelabel calculator554 queries the resource allocation table553 for flow label identification (i.e., Columns1 and3). This step could be triggered by a change in the resource allocation table553, or may be performed periodically or continuously. Step751 then determinesqueue entry345 label allocations.

In one embodiment,step751 consults the entry label counts for each session of data communication as indicated inColumn3 of the resource allocation table553. Step752 then labels555 theentries345 according to the entry label calculations. The labeling ofqueue entries345 may proceed serially by labelingentries345 with all of the “A” labels (e.g., 3 “A” labels555), and then when there are no more “A” labels remaining,labeling entries345 with “B” labels (2 in the example) until none remain, and so forth. With respect to the example resource allocation table553 inFIG. 6A, the twelve labeled entries in the example queue340-1 inFIG. 5 would have a labeling order as follows:

- “A” “A” “A”“B” “B” “C” “C” “C” “C” “U” “U” “U”

However, as will be explained next with respect toFIGS. 9A and 9B, thelabel calculator554 may label theentries345 in thequeue340 instep752 in a variety of other patterns so as to evenly distribute labeledentries345 for each session or FLOW ID, depending upon the selected embodiment.

FIG. 9A illustrates an example of a labeling pattern. InFIG. 9A, thebandwidth labeler550 sequentially “uses up” the labels for each session having a reserved resource in a serial manner, and when none are left, moves on to the next set of labels. As indicated in the figure, which corresponds to the bandwidth reservations established in the resource allocation table553 inFIG. 6A, the “A” session ofdata communication203 has twenty-five percent of the bandwidth reserved via “A” labels in thequeue entries345. Thus thedata scheduler320 inFIG. 5 is able to queue “A”data packets203 into one quarter of the entire queue space on each rotation. The “C” data stream has thirty-three percent of the queue reserved, and the “B” stream has sixteen percent reserved. This leaves a remaining twenty-five percent of thequeue entries345 labeled with “U”, or not labeled at all. The “U” labeledentries345 are used for alldata206 that does not belong to a session having a bandwidth reservation in thisdevice201.

It may be apparent to those skilled in the art that a situation might arise where thedata scheduler320 detects an RSVP header that indicates a session identification (i.e., a labeled packet) for which there are currently no corresponding labeledqueue entries345. The invention addresses this situation in a number of ways. First, thedata scheduler320 can simply buffer the data until anentry345 having acorresponding label555 appears. After a certain time period, which preferably corresponds to a certain number of rotations of thequeue340, if no labeledentry345 appears (to the data scheduler320) that matches the packet data (with a session identification) that is buffered with the unknown session identification, thedata scheduler320 can either discard the unknown session data or can simply deposit the data into one of the data storage locations that is indicated as being unreserved (i.e. labeled “U”). The later mechanism (queuing into an unreserved entry345) is preferred over the packet discard mechanism, since data will not be lost and will not require re-transmission from the sender if the unknown data stream has such error detection/correction capabilities enabled.

In this manner, if session data is transported to adevice201 which is unaware of the existence of the session, the invention still allows the data to be transported as if it were unlabeled data not associated with any particular session. In prior art systems in which a classifier and scheduler are made aware of all active sessions, the unknown session data might confuse the classifier and/or scheduler and may require either, at a minimum, to pause operation to consult with the RSVP daemon (e.g.,101 inFIG. 1) to determine how to handle the unknown session data. The invention avoids such cumbersome approaches and keeps the data transport mechanism separated from the bandwidth allocation and administration aspects of thedevice201.

FIG. 9B illustrates another labeling pattern which can be used by thelabel calculator554 to labelqueue entries345 with session labels. The approach taught inFIG. 9B is cycling label approach. In this approach, thelabel calculator554 repetitively cycles through each FLOW ID in the resource allocation table553 and labels onequeue entry345 for each session or flow id per cycle. During the repetitive cycling, thelabel calculator554 decrements the number of labels remaining for each FLOW ID. When a FLOW ID has no labels remaining (i.e., its ENTRY COUNT OF TOTAL QUEUE SIZE value is zero), no more labels are created for that session or flow identification. In this manner, a more balanced approach is provided for the queue entry labeling process of the invention, since each flow is provided with a labeledentry345 that is separated from another similarly labeledentry345 by other entries labeled for other flows that still have more bandwidth to be reserved (i.e., more entries that are to be labeled). As illustrated inFIG. 9B, from left to right, the labels onqueue entries345 appear in this example as follows:

- “A” “B” “C” “U” “A” “B” “C” “U” “A” “C” “U” “C”

In total, there are three “A” entries, two “B” entries, four “C” entries, and three “U” entries, and that the entries are somewhat staggered from each other. The sequence A-B-C-U begins at the left and repeats itself twice, after which there are no more “B” labels to be produced, and so the remaining “A” and “U” labels are produced. In this manner, thebandwidth labeler550 presents a more even distribution of labeled (i.e., reserved)bandwidth entries345 so that thedata scheduler320 does not have to wait for significant periods of time while buffering data and awaiting for an entry with the correct label to appear.

In yet another embodiment of thebandwidth labeler550 and thelabel calculator554, thelabel calculator554 only labels thequeue entries345 each time the resource allocation table553 changes. As such, the labels (e.g.555 inFIGS. 5 and 6B) remain allocated or associated with eachentry345 as theentry345 continually circulates around and around thequeue340. In this manner, the bandwidth reservations for each session are static until they need to be changed. That is, the only time thequeue entries345 are relabeled is if a change is detected to the bandwidth reservations as communicated by the change in data values in the resource allocation table553. This embodiment conserves processing resources used by thebandwidth labeler550, which can enter an idle state until thesender state data504 changes. The change causes theresource allocation calculator552 to “wake up” and update the resource allocation table553, which in turn causes thelabel calculator554 to re-labelentries345 as required.

It is to be understood by those skilled in the art that the labeling patterns inFIGS. 9A and 9B are illustrative as examples only, and are not limiting of the present invention. Rather, other fair, weighted, or even distribution schemes known to those skilled can be used to label the sequence ofqueue entries345 so as to best distribute the reserved bandwidth for each session of data communication across the entire queue340-1. For example, in an alternative embodiment, eachqueue entry345 may be larger than the size of a single packet. In such cases, anentry345 may hold many packets, cells, frames, or other unit of data from the session of data communication. In another alternative embodiment, each entry may have more than one label. That is, is two or more sessions of data communication are somehow related, or have equivalent bandwidth reservations (e.g., same percentage for both sessions), the bandwidth reservation processor might label a single entry with more than one session identification. In this manner, thedata scheduler320 can deposit any one or a number of different packets into themulti-labeled entry345.

It is also to be understood that the invention is not limited to applications providing bandwidth reservation and allocation using the RSVP protocol. Rather, the invention is intended to operate in conjunction with other bandwidth reservation, allocation, or adjustment protocols that currently exist or that may be developed in the future. For example, future versions of RSVP may provide specific message formats to enable bandwidth adjustments. The invention provides implementations of data communications devices as explained herein that can take advantage of such messages to dynamically adjust bandwidth as required for sessions of data communication.

For more details on the operation of bandwidth reservation protocols such as RSVP and its derivatives, the reader is directed to Request For Comments 2205 and 1633 and RSVP93 (RFC-2205, RFC-1633, RSVP93), published by the Network Working Group of the Internet Engineering Task Force (IEFT), and available on the Internet at ftp://ftp.isi.edu/in-notes/rfc2205.txt, each of which protocol references is hereby incorporated by reference in their entirety.

The invention applies to all types of data transmitted to or from any type of device through any type of network and/or network communications medium. While the illustrated examples discuss packet data which is primarily applicable to Transmission Control Protocol/Internet Protocol (TCP/IP) networks such as the Internet, the invention is equally applicable to networks that use such units of data as tokens, cells, frames, blocks, and so forth. Other network architectures such as Asynchronous Transfer Mode (ATM) networks can use the concepts of the invention as well to reserve bandwidth for cell transfer. Also, networking architectures such as packet-wireless, Fiber Distributed Data Interface (FDDI), Systems Network Architecture (SNA), Digital Subscriber Link (DSL), Advanced Peer-to-Peer Networking (APPN) and others may benefit from use of the invention.

Another alternative scenario that could illustrate the features of the invention would be to have several networked computers each running different types of applications having different data communications requirements. The data produced from each application may need to be transferred between the computers at different reserved rates. The invention could be used to provide this capability. It is also understood that adata communications device201 configured according to the invention may have one ormore data schedulers320 and one ormore data queues340. An arrangement such as a single data scheduler per input port that can deposit data into many different queues340-1,340-2, etc., where there is onequeue340 per output port is contemplated as a device configured according to the invention. Other arrangements are possible as well which are contemplated by the invention. Such alternative arrangements and alternative designs of data communications devices can apply the concepts of the invention as disclosed herein to provide dynamic bandwidth reallocation without interrupting streams of data, since the operation of the bandwidth allocation mechanisms are generally separated from the data transport mechanisms, as explained herein.

While this invention has been particularly shown and described with references to preferred embodiments thereof, it will be understood by those skilled in the art that various changes in form and details may be made therein without departing from the spirit and scope of the invention as defined by the appended claims.

Claims

1. A method for dynamically adjusting reserved bandwidth in a data communications device while transporting a session of data communication within the device, the method comprising the steps of:

receiving a first RSVP bandwidth reservation request associated with application data of a session of data communication;

reserving a first amount of data storage locations in the data communications device for the session of data communication, the first amount of data storage locations reserved based upon an amount of bandwidth requested in the first RSVP bandwidth reservation request; and

dynamically adjusting the first amount of data storage locations in the data communications device for the session of data communication to produce a second amount of data storage locations in the data communications device for the session of data communication request while continually maintaining the session of data communication, the dynamic adjusting based upon bandwidth allocation adjustment information within a second RSVP bandwidth reservation request.

2. The method ofclaim 1 wherein reserving comprises:

labeling, with an identity of the session of data communication, a first percentage of available data storage locations used to store application data transported through the data communications device to establish a first bandwidth reservation, the first percentage of available data storage locations labeled based upon the amount of bandwidth requested in the first RSVP bandwidth reservation request.

3. The method ofclaim 2 wherein dynamically adjusting comprises:

labeling, with an identity of the session of data communication, a second percentage of available data storage locations used to store application data transported through the data communications device to establish a second bandwidth reservation while continually maintaining the session of data communication, the second percentage of available storage locations labeled based upon an amount of bandwidth requested in a second bandwidth reservation request, the second percentage of storage locations labeled being different than the first percentage of storage locations labeled.

4. The method ofclaim 1 wherein receiving comprises:

receiving a first RSVP bandwidth reservation request associated with application data of a session of data communication, the first RSVP bandwidth reservation request distinct from the application data.

5. The method ofclaim 1 wherein dynamically adjusting comprises:

dynamically adjusting the first amount of data storage locations in the data communications device for the session of data communication to produce a second amount of data storage locations in the data communications device for the session of data communication request while continually maintaining the session of data communication, the dynamic adjusting based upon bandwidth allocation adjustment information within a second RSVP bandwidth reservation request, the second RSVP bandwidth reservation request distinct from the application data.

6. A data communications device comprising:

at least one communications interface;

controller; and

an interconnection mechanism coupling the at least one communications interface, the memory, and the processor;

wherein data communications device is configured to:

receive a first RSVP bandwidth reservation request associated with application data of a session of data communication via the at least one communications interface;

reserve, via the controller, a first amount of data storage locations in the data communications device for the session of data communication, the first amount of data storage locations reserved based upon an amount of bandwidth requested in the first RSVP bandwidth reservation request; and

dynamically adjust the first amount of data storage locations in the data communications device for the session of data communication to produce a second amount of data storage locations in the data communications device for the session of data communication request while continually maintaining the session of data communication, the dynamic adjusting based upon bandwidth allocation adjustment information within a second RSVP bandwidth reservation request received via the at least one communications interface.

7. The data communications device ofclaim 6 wherein, when reserving, the data communications device is configured to:

label, with an identity of the session of data communication, a first percentage of available data storage locations used to store application data transported through the data communications device to establish a first bandwidth reservation, the first percentage of available data storage locations labeled based upon the amount of bandwidth requested in the first RSVP bandwidth reservation request.

8. The data communications device ofclaim 7 wherein, when dynamically adjusting, the data communications device is configured to:

label, with an identity of the session of data communication, a second percentage of available data storage locations used to store application data transported through the data communications device to establish a second bandwidth reservation while continually maintaining the session of data communication, the second percentage of available storage locations labeled based upon an amount of bandwidth requested in a second bandwidth reservation request, the second percentage of storage locations labeled being different than the first percentage of storage locations labeled.

9. The data communications device ofclaim 6 wherein, when receiving, the data communications device is configured to:

receive a first RSVP bandwidth reservation request associated with application data of a session of data communication, the first RSVP bandwidth reservation request distinct from the application data.

10. The data communications device ofclaim 6 wherein, when dynamically adjusting, the data communications device is configured to:

11. A computer program product having a computer-readable medium including computer program logic encoded thereon for allocating bandwidth in a data communications device, such that the computer program logic, when executed on at least one processing unit with the data communications device, causes the at least one processing unit to perform the steps of:

12. A data communications device comprising:

at least one communications interface;

a controller; and

an interconnection mechanism coupling the at least one communications interface and the controller;

wherein the data communications device is configured to produce a means dynamically adjusting reserved bandwidth in a data communications device while transporting a session of data communication within the device, such means including:

means for receiving a first RSVP bandwidth reservation request associated with application data of a session of data communication;

means for reserving a first amount of data storage locations in the data communications device for the session of data communication, the first amount of data storage locations reserved based upon an amount of bandwidth requested in the first RSVP bandwidth reservation request; and

means for dynamically adjusting the first amount of data storage locations in the data communications device for the session of data communication to produce a second amount of data storage locations in the data communications device for the session of data communication request while continually maintaining the session of data communication, the dynamic adjusting based upon bandwidth allocation adjustment information within a second RSVP bandwidth reservation request.

13. The data communications device ofclaim 12 wherein the means for reserving comprises:

means for labeling, with an identity of the session of data communication, a first percentage of available data storage locations used to store application data transported through the data communications device to establish a first bandwidth reservation, the first percentage of available data storage locations labeled based upon the amount of bandwidth requested in the first RSVP bandwidth reservation request.

14. The method ofclaim 13 wherein the means for dynamically adjusting comprises:

means for labeling, with an identity of the session of data communication, a second percentage of available data storage locations used to store application data transported through the data communications device to establish a second bandwidth reservation while continually maintaining the session of data communication, the second percentage of available storage locations labeled based upon an amount of bandwidth requested in a second bandwidth reservation request, the second percentage of storage locations labeled being different than the first percentage of storage locations labeled.