Method and system for providing a mobile IP network with non-path dependent intra domain quality of service

[0001] The U.S. Government has a paid-up license in this invention and the right in limited circumstances to require the patent owner to license others on reasonable terms as provided for by the terms of the contract number DMB07-01-C-L522 awarded by the United States Army.

[0002] The present invention generally relates to computer networks, and more particularly relates to internet protocol (IP) networks, and even more particularly relates to methods and systems for providing quality of service capabilities on a mobile IP network.

[0003] In recent years, there has been an explosion of data being communicated over computer networks. At any given instant, the throughput capabilities of any IP network are fixed. If demand for access to the network exceeds the capacity of the network, then network congestion occurs. With network congestion comes delayed data delivery or, worse yet, loss of data. This can be particularly problematic if the data being sent is time sensitive and/or highly important data.

[0004] In the past, two basic technologies have been proposed to provide quality of service (QoS) over IP networks. These are Integrated Services (IntServ) and Differentiated Services (DiffServ).

[0005] One way to provide consistent QoS in a congested network is to differentiate between packets and forward some preferentially according to different priorities. If the network is fully utilized, the resources must be taken away from some packets and given to others. Even with priority forwarding, there is a limit to the amount of traffic that can be handled at each priority level without introducing delay. Admission control is the process of limiting the amount of traffic admitted at each QoS to that for which the specified parameters can be met. IntServ and DiffServ differ in how these two variables, priority and admission control, are used to provide QoS.

[0006] IntServ is based on reserving resources per flow at each router along a specific path. Usually the Resource Reservation Protocol (RSVP) is used to set up these reservations. Each router is typically responsible for managing admission to its own resources. Typically, each router must then inspect every received packet to determine which reserved flow, if any, it is a part of. Each packet is given a priority, valid only within that router, based on the reservation state of that flow in that router.

[0007] While this approach has advantages in that as long as the reserved path remains unchanged, the specified QoS can be met with a high degree of precision, it also has some serious disadvantages. It is dependent on the data packets following a specific fixed path. If the data packets venture outside of this fixed path, QoS is lost until resources are reserved along the new path. There are also serious scalability problems inherent in requiring each router in the network to maintain a detailed table of all QoS flows that pass through it. This is both an issue of the size of this flow table and the execution time to search the table to identify to which flow each incoming packet belongs. IntServ thus offers a precise control of QoS in a network that is static or very slowly changing.

[0008] By contrast, DiffServ controls admission at the network boundaries. Once admitted, packets are marked with a DS codepoint that specifies a network wide per hop behavior (PHB) to be used by each router in forwarding the packet. Thus, admission control occurs once at the network boundary, and there is no distinction between flows internally.

[0009] While DiffServ is completely independent of path within the network and is clearly advantageous in dynamic networks, it has some drawbacks. The downside is that admission control becomes more complicated; since traffic may enter the network from many different points, some kind of centralized coordination between possible entry points is required. If the admission controller were to be cognizant of detailed network topology and traffic loading, then the admission control function would be path dependent, and little would be gained relative to IntServ. Conversely, if a more approximate scheme were adopted which did not attempt to track network topology and traffic patterns, then the level of precision of QoS would be reduced. Also, DiffServ does have the advantage that QoS is not interrupted, but it may be evenly degraded for many flows in a region of the network that exhibits a bottleneck topology or a concentrated traffic load.

[0010] Consequently, there exists a need for improved methods and systems for providing QoS on mobile IP networks in an efficient manner.

[0011] It is an object of the present invention to provide a system and method for providing QoS on a mobile IP network in an efficient manner.

[0012] It is a feature of the present invention to utilize a dynamic differentiated services domain.

[0013] It is an advantage of the present invention to provide for enhanced abilities to deal with network topologies and unbalanced traffic loads.

[0014] It is another feature of the present invention to include a distribution of multiple QoS managers (QM) about differentiated service domains in the mobile network.

[0015] It is another advantage of the present invention to achieve improved efficiency in dynamically changing differentiated service domains.

[0016] It is yet another feature of the present invention to use congestion feedback to estimate a total domain bandwidth which is used to admit into a domain only the amount of data traffic that the domain can support.

[0017] The present invention is an apparatus and method for providing QoS to mobile IP networks which are designed to satisfy the aforementioned needs, provide the previously stated objects, include the above-listed features, and achieve the already articulated advantages. The present invention is carried out in an intra-domain “path dependent-less” manner in a sense that the need to determine a precise path of data through a domain as a prerequisite to QoS has been eliminated or greatly reduced in certain applications.

[0018] Accordingly, the present invention is a system and method including a mobile IP network with: dynamic Differentiated Services domains; multiple QoS managers per domain; and/or, domain congestion feedback affected estimated total domain bandwidth access parameters.

[0061] Now referring to the Figures where like numerals refer to like matter throughout, the present invention formulates a mechanism, intermediate between IntServ and DiffServ, which attempts to provide predictable QoS while avoiding path dependence and minimizing overhead. It is tailored to dynamic, ad hoc networks. It deliberately sacrifices the precision of micro management of network resources in return for minimizing overhead. At the same time, the concept of a DiffServ domain, introduced in the literature to cover an administrative entity, is generalized into a dynamic entity, which is formed spontaneously and evolves with the network as a mechanism to deal with network topology and unbalanced traffic loads. This mechanism is hereinafter referred to as Differentiated Services with Distributed Quality of Service Managers, or DS/DQM. The system of the present invention may be best understood by referring first to FIGS. 8 and 9, which show a simplified view of portions of the network of the present invention. The text below related to FIGS. 8 and 9 helps to show the structural framework for the present invention.

1.1 DS/DQM Overview

[0062] In the DS/DQM mechanism, the network is organized into a set of domains. There are two kinds of domains: those that provide QoS by means of a Quality of Service Manager (QM) and a Request-Grant Protocol (RGP) as described in this paper, and those that do not. Those that do will be referred to as participating domains (see 102, 104, and 106 in FIG. 8). All other domains are non-participating domains (e.g. See 122 in FIG. 9). Each participating domain is a DiffServ domain in which all of the routers provide the same domain-wide set of PHBs. Traffic with QoS that enters a participating domain must have requested, and subsequently been granted, admission by an admission control entity for that domain, which in this mechanism is the QoS Manager. Any non-participating domain is able to send best effort traffic through the participating domains with no alterations. However, if this traffic is to be sent with priority, the router that is used by the traffic to enter the participating domain traps the packets and starts the request-grant protocol for that traffic. In this way, the DS/DQM mechanism is compatible with other QoS mechanisms.

[0063] It is assumed that within each participating domain, the links are roughly homogeneous, and the traffic is randomly distributed. This assumption allows the domain resources to be reasonably and accurately estimated, and then allocated by means of a single generalized domain-wide bandwidth quantity, which will be called the Total Domain Bandwidth (TDB). This number is an approximation that is initially estimated, then maintained by means of a feedback control mechanism. This mechanism adjusts the TDB in response to domain conditions to maintain QoS performance.

[0064] The main functions of the QoS Manager are to maintain the TDB and allocate bandwidth. Logically, the QoS Manager is a single function that spans the participating domain and provides admission control services. In a dynamic network, it is necessary for most domains, if not all, that this single logical function be distributed over two or more physical network entities to provide redundancy and minimize the likelihood of service interruptions.

[0065] As a flow moves through the network, it passes through a series of domains. This is referred to as the domain path. Reservations for each flow are made domain-by-domain along the domain path, in a similar fashion to the way IntServ makes reservations router-by-router.

1.2 Total Domain Bandwidth Overview

[0066] The total capacity of the domain to accept traffic, while maintaining the required Quality of Service, is estimated by the Total Domain Bandwidth. The real capacity of the domain depends upon both the domain topology and traffic profile and will be continuously varying. The TDB is intended to be a reasonable approximation to this value, and is found by making an initial estimate and then continuously adjusting it based on feedback from within the domain. For a homogeneous domain (containing either identical links or an even distribution of heterogeneous links) with randomly distributed traffic, this should result in a very good approximation. For an extremely unbalanced topology or message traffic, it would be an underestimate. We are intentionally using an approximation to avoid the complexity and high message and computational overhead of trying to micromanage a dynamic network.

[0067] The initial value of the TDB could be determined in various ways. It could be taken as an arbitrary number, such as the bandwidth of a single link, which may be a good estimate for a bus or broadcast type network medium. It could be taken as some multiple of the bandwidth of a single link or as an arbitrary starting value without reference to the actual domain. There is a tradeoff between accuracy and the overhead required for the calculation. The method of making the initial estimate is not critical, since the actual value is determined by the feedback mechanism. The initial estimate affects only the time required for the TDB to converge to a stable value.

[0068] Each router in the system monitors the usage of its output links. When a router detects congestion, for example, packets at the highest QoS are being queued, or packets at lower QoS are being discarded, it sends a congestion report to its QoS Manager. The QoS Managers maintain a table of congested links by QoS level. Since DiffServ is non-deterministic and TDB is an approximation, occasional congestion is to be expected. If persistent and non-local congestion is detected, as indicated by a large number of congestion table entries for a time period exceeding a threshold, domain wide congestion would be recognized and the TDB adjusted.

[0069] If the total reserved bandwidth is at or near the TDB value and the domain is not congested, the TDB value would be increased. Note that if the total reserved bandwidth is well within the TDB, no congestion would be expected, and no action is taken. Domain congestion when the total reserved bandwidth is less than the TDB indicates the TDB is an overestimate, and the TDB is decreased. These changes are summarized in Table 1.

[0070]

TABLE 1
TDB Feedback Utilization
	Congestion	Under-	Fully	Over-
	Reports	Reserved	Reserved	Reserved
	Not Received	Nothing	Increase	Increase
			TDB	TDB
	Received	Decrease	Decrease	Nothing
		TDB	TDB

[0071] It is possible that after decreasing the TDB due to congestion, the domain could be over reserved. As reservations time out or release, the reserved bandwidth will decrease. No new reservations will be granted until the total reserved bandwidth has adjusted to the new TDB figure. There will definitely be a time lag between adjustment of the TDB and the response of the domain. To prevent excessive decreasing of the TDB during this lag time, the TDB should not be decreased while the domain is over reserved.

[0072] When the domain is over-reserved, the QoS Managers have no unreserved allocation and cannot make any grants until sufficient reserved bandwidth has been released to bring the total reserved bandwidth back into alignment with the decreased TDB. The possible additional actions are:

• • [0073] Active termination—Enough flows are forcibly terminated to bring reserved bandwidth within the TDB.
  • [0074] Passive termination—No flows are forcibly terminated, but renewals are denied until reserved bandwidth is within TDB.

[0075] In both cases, it is necessary to provide a scheme for selecting which flows are to be terminated or have their renewals denied. In the case of forcible termination, it is also necessary to notify the source that its grant has been revoked, and to notify other QoS Managers along the domain path that the flow has been terminated, and all grants associated with this flow should be released.

[0076] The exact behavior when bandwidth is over reserved is a policy issue. More aggressive action reduces the response time between adjustment of the TDB and response of the total reserved bandwidth. This is achieved at the expense of those flows that are terminated, while minimizing disruption to those which are not. Less aggressive action results in a longer response time with more uniform transient degradation of all flows. The choice might be a function of QoS level; e.g., forcibly terminate flows at lower QoS to preserve flows at a higher, congested, QoS. It might also be a configurable option.

[0077] For reasons of stability, the overall rate of adjustment of the TDB should be limited. When a major change to the network topology is detected, e.g., a new QoS Manager is created, or an existing QoS Manager leaves the network, this introduces additional delay while the TDB converges to a new stable value. It is always an option to re-estimate the TDB in this case by the same method used to estimate TDB originally. As always, there is a tradeoff between accuracy and overhead.

2 Quality of Service Manager

[0078] The QoS Manager is the logical entity that controls the amount of data traffic allowed to enter the domain. A request-grant protocol is used to establish bandwidth reservations within the domains, and another protocol is used for communicating the RGP between domains. A certain amount of information is also kept by the QMs within each domain to facilitate the efficiency of these protocols.

2.1 Protocol Request-Grant

[0079] Any data that is sent into the network that desires better than best effort service must request QoS from the QoS Manager. This request becomes the first message of the RGP, which includes five different messages that are used between the source and QM to negotiate QoS. These messages are the Request, Grant, Denial, Release, and ACK messages. What follows is a simple example to introduce the Request-Grant Protocol and show how the five messages are used to complete the QoS transaction. This example is illustrated in FIG. 1.

[0080] To initiate a QoS reservation, the source must send a Request message that includes the requested QoS level and bandwidth to its QM, as demonstrated by the message sequence labeled “A”. The QM then decides if the QoS requested can be given, and, if so, formats a new Request message and sends it to the destination. In this example, the destination is in the same domain as the QM, and destinations accept all Requests. Therefore, the destination immediately formats a Grant message and sends it to the source of the Request, which in this case was the QM. Upon receiving a Grant, the QM again checks to ensure the QoS can still be met, makes the reservation for that request, and then formats and sends a Grant to the data source, which was the source of the Request the QM received. This Grant is valid for a configurable amount of time, which is specified in the Grant message. For this example, this amount will be referred to as “x”.

[0081] Once the source receives the Grant, a timer is set, and data packets can be sent at the granted level of QoS. When the timer is at x/2 and the source has not completed the transmission, it has the option of renewing the reservation for another x. This is done by the same procedure as the initial reservation (shown in message sequence “B”), and can be denied or accepted. If the renewal Request is denied, the source may still be able to send, using the initial Request reservation until the timer ends.

[0082] When the source completes the transmission, it should Release the reservation, as shown in message sequence “C”. To complete a release, the source must send a Release to the QM the reservation was made with, which immediately replies with an ACK. The QM, in turn, sends a Release on to the destination, which also replies with an ACK. If the Release is not completed for any reason, the reservation times out and is automatically released.

[0083] Once the reservation is released, the source may no longer send packets with QoS greater than best effort unless another Request has been made and Granted.

[0084] If the source and destination are not in the same domain, the Request needs to be passed through a QM in each domain that the data will travel through to ensure that there is bandwidth reserved at each point. An example where the source and destination reside in neighboring domains is shown in FIG. 2.

[0085] When the QM sends a Request out, it is addressed to the destination noted in the Request. If the Request enters another domain before reaching the destination, the entrance router to that domain traps the message and forwards it to its own QM. This QM will evaluate the Request and repeat the process, sending a new Request to the destination. When a Request reaches the destination, it responds to the Request Source with a Grant in the same way as before. When the QM receives the Grant, it again checks for availability of bandwidth, reserves the bandwidth for that Request, and then sends a Grant on to its Request Source. This continues until the Grant reaches the original Source, at which time the source is able to start sending data packets at a higher level of service.

[0086] Until now, it has been assumed that each QM is able to fulfill the request for a reservation of bandwidth at the QoS desired. However, it is likely that there will be requests that cannot be filled, and, therefore, are denied, as shown in FIG. 3. In the first sequence, it is assumed that each QM (just one QM is illustrated) is able to accept the Request as it is made, and the destination automatically Grants the Request. However, the QM, upon receiving the Grant, finds that it is no longer able to support that Request and so sends a Denial message to the source of the Request, and a Release back to the source of the Grant. The Denial contains a suggestion of what QoS would be available if the source made another Request. The suggested QoS could include a QoS level, an amount of available bandwidth, or both. If the source desires, it can then send a new Request with the suggested QoS parameters.

[0087] In FIG. 4, QM-A is not able to accept the Request when it is received. In this case, it sends a Trial-Request message toward the destination, and the Trial-Request is redirected to QM-B. The Trial-Request message contains the same information as the Request message, and is handled in a similar manner, except that if the QM is not able to accept the suggested bandwidth, the QM can adjust it to an acceptable level. When the Trial-Request is received by the destination, a Trial-Denial is sent as the response. The QMs handle the Trial-Denial in the same way as a Denial message, with no bandwidth reservations being made. The source responds to the Trial-Denial in the same way as the Denial. The use of a Trial-Request and Trial-Denial allows the suggested QoS to be the best suggestion, and that all the domains along the domain path would be able to support that suggestion when it was made.

[0088] Now that the QoS has been negotiated and reserved, it is important to consider what occurs when the Request-Grant Protocol is used in a dynamic network. If the source sends a renewing Request to the QM, and does not receive any reply, the source assumes that the QM has moved or is no longer able to communicate. The source then identifies another QM to use, via the Domain Organization protocol described in Section 3, and sends the Request to that QM, which will proceed just as described above. During this process, the source is still able to send traffic with QoS per the previous reservation until the reservation times out. If a Grant is received from the new QM prior to the old reservation expiring, the source sends a Release to the old QM. This sequence is shown in FIG. 5.

[0089] If the QM does not respond to a Release message sent by the source, as shown in FIG. 6, the source locates another QM in the domain to send the Release to. This new QM replies to the Release with an ACK, and then sends a Release toward the destination. The new QM then sends a Release to the old QM. If the old QM still does not respond, it is assumed that the old QM has discontinued communications, and after a set amount of time (x, the amount of time reservations are good for), the bandwidth previously allocated to that QM is reallocated among the remaining QMs.

[0090] If the Request message times out before a response is received, it is assumed that the message has been lost. At this point, the QM sends an RGP Time-Out message to the predecessor QM on the domain path, as shown in FIG. 7. The Time-Out message includes the Reservation Identification (RID) and Request Identification (QID) numbers of the expired Request if they are known. If a QM receives an RGP Time-Out message, and the RID or QID matches that of an entry in the Reservation or Pending Request Tables, as shown in Section 2.3, the pending Request is cancelled, and a Time-Out message sent to the predecessor QM. If there is not a matching entry found, the Time-Out message is ignored.

2.2 Communication Between Domains

[0091] The network is organized into a collection of domains connected to one another by external links. Domains may be either participating or non-participating. A participating domain is defined as one for which admission is controlled by a QoS Manager by means of the Request-Grant Protocol defined in Section 2.1. All other domains are by definition non-participating domains.

[0092] The QM in a participating domain monitors domain resources and controls admission. The mechanism by which the QM implements this function may be the TDB/feedback mechanism described in Section 1.2, or any other mechanism. For the purposes of this section, it does not matter, nor must all the QMs use the same mechanism.

[0093] Each router in a participating domain must be aware of the domain to which it belongs, its QoS Manager, and whether the routers at the other ends of directly connected links lie in the same domain or some other domain, i.e., are external links. In some cases, this information might be determined by the technology. For example, in a cluster of terminals, which communicate with a base station and are incapable of communication with one another in the absence of a base station, obviously the cluster is a domain and the QoS Manager would be the base station. In other cases, the organization must be determined ad hoc and will be dynamic. For example, a flat network with no imposed hierarchy in which all routers are created equal and may talk freely to one another. In this case, the network might be organized into domains as described in Section 3. The details of how the network is organized into domains are not directly relevant to how they communicate.

[0094] The purpose of this section is to illustrate how domains interact. This includes discussion on flows spanning multiple participating domains, traffic entering a participating domain from a non-participating domain, traffic that is delivered from a participating domain into a non-participating domain, and communications that travel through multiple non-participating domains.

2.2.1 Communication Between Participating Domains

[0095] To describe the basic mechanism used to communicate between multiple participating domains, a simple example will be used. This example, shown in FIG. 8, includes a series of three participating domains 102, 104, and 106, that the data must flow through from the source 108 (labeled as network element “S”) to the destination 110 (labeled network element “D”). For simplicity, a single QM is shown for each domain, although this logical function is actually distributed over multiple physical elements within the domain. Similarly, separate control paths are shown, although the control packets will actually be communicated in the same way as the data packets. This difference is to emphasize that the control packets may not be assumed to traverse the same path, or even visit the same network elements, as the data packets. Note that the data packets are not required to pass through the element that contains the QM of the domain. The control mechanism is completely independent of the path in a participating domain.

[0096] In this example, the three participating domains, A 102, B 104, and C 106, each have a QoS Manager 112, 114, and 116 respectively, and source S 108 in domain A 102 wishes to send a flow to destination D 110, in domain C 106, with some enhanced quality of service. Router S 108 initiates the process by sending a request to its QM, QM-A 112. If QM-A 112 can support the request, it generates a new request addressed to destination router D 110. However, D 110 is not in the same domain as QM-A 112, and so the Request from QM-A 112 is propagated by the routers until it enters a new domain. The first router in the new domain, domain B 104, recognizes the request as being received on an external link, which is a link on which the element on the opposite end belongs to a different domain. Because the request came in on an external link, the message is trapped, and forwarded on to that router's QM, QM-B. QM-B then handles the request in the same way it was handled by QM-A 112. This process repeats itself until a request message reaches the destination router 110.

[0097] When the destination router 110 receives a request, it determines whether it can accept the flow, and sends the response directly back to the source of the Request, which in this example is QM-C 116. QM-C 116 then sends a response to the Request it received. As described in Section 2.1, the response returns to the source 108 through each QM the Request passed through. Note that if the response is a Denial, each QM checks the suggested QoS and bandwidth and then suggests the same or lower levels according to its own ability to support the source's data flow. If the response is an Accept, each QM checks to ensure it is still able to support the flow, and if so, makes the reservation. If the QM is not able to do this, it sends a Denial to the preceding QM (toward the source) with a suggested bandwidth, and a Release to the succeeding QM (toward the destination).

[0098] It is important to understand that these messages are not being forwarded by the QMs, but instead are separate nested transactions. In this sense, the QoS Manager of each domain acts as a proxy for source S in requesting QoS from the next domain along the domain path. The mechanism described here is fully recursive and applies to any number of intermediate participating domains.

2.2.2 Communication from a Participating to a Non-Participating Domain

[0099] Now referring to FIG. 9, the pattern of control messages will be changed slightly if the destination lies in a non-participating domain, while the source still resides in a participating domain. FIG. 9 shows an example of this, with a participating domain sending traffic into a non-participating domain. It is assumed that the connection is through a special interface router I, 124, which is an element of the participating domain 109 that has been modified to interface to that non-participating domain 122. There are two possible QoS interfaces for the non-participating domain 122:

• • [0100] 1. Simple priority—This means that the non-participating domain has either a simple priority based QoS mechanism, or no QoS mechanism at all. The non-participating domain receives packets from interface router I with a simple priority mark in each individual packet. Examples of such mechanisms would be standard DiffServ, or a non-QoS aware domain.
  • [0101] 2. Request-Grant—This means that the non-participating domain has a QoS mechanism which involves requesting resources and waiting for the resources to be granted. It is expected that the interface router I 124 will issue this request to the non-participating domain 122, and then, if necessary, wait for a grant before sending data packets. An example of such a mechanism is standard IntServ, for which the request is a PATH message and the grant is a RESV message. Note that the QM architecture described in this document is also a request-grant mechanism.

[0102] The request from source S 109 is handled as for any other participating domain. When interface router I 124 receives a request whose next hop is determined to be the interface to the non-participating domain, it must generate a request of the type native to the non-participating domain. For example, if the non-participating domain 122 were a standard IntServ domain, the interface router would generate a PATH message directed to destination router D (see FIG. 10) and send it into non-participating domain B. Note that the request message contains the source and destination IP addresses and ports which are required to identify an individual flow.

[0103] Interface router I must then wait to receive the native response message from the non-participating domain. For example, if the non-participating domain were a standard IntServ domain, interface router I would wait for an RESV message. When this message is received, interface router I generates a corresponding grant message and sends it back to the previous QM. In this way, the grant is propagated back to the data source, which may then begin sending data packets.

[0104] Some non-participating domains may require a special flow ID to be set as an option in the IP header. In this case, the non-participating domain, or interface router I acting on its behalf, must generate such a flow ID. This flow ID is included in the grant message and propagates back to the source. The source then inserts this option field into the IP header of every packet of the identified flow. This is done because source router S and interface router I are the only two nodes where the paths of data and control packets are known to coincide. Setting the option field at the source frees interface router I from the necessity of maintaining a flow table and performing per packet look-ups. This flow ID is propagated through the participating domain as a field with an associated length, just as it will appear in the IP header option. The value chosen is transparent to the participating domain, which does not use this value. Thus, the format and nature are completely under the control of the non-participating domain.

[0105] When the non-participating domain is the other type and does not have a request-grant mechanism, the interface is much simpler. The interface router contains a mapping from the QoS levels provided by the participating domain to the priority or other levels defined for the non-participating domain. Each data packet is remarked according to these new levels and forwarded into the non-participating domain. In this case, interface router I responds to requests as the destination router, without consulting the non-participating domain.

2.2.3 Communication from a Non-Participating to a Participating Domain

[0106] Another problem to consider is what occurs when a flow enters a participating domain from a non-participating domain. FIG. 10 shows an example of this, where a non-participating domain wishes to inject traffic into a participating domain. It is assumed that the non-participating domain is connected to a special interface router I, which has been specially modified to interface to the non-participating domain. It is also assumed that the non-participating domain is one of the two types defined in Section 2.2.2, and presents either a request-grant interface or a set of priority levels.

[0107] If the non-participating router provides simple priority based QoS, interface router I becomes aware of the flow when it receives data packets from the non-participating domain. Interface router I must then determine from the packet what QoS level is appropriate and then send a Request to the QM for its domain, the participating domain shown in FIG. 10. The processing of the Request is exactly as if interface router I were the source of the flow.

[0108] Interface router I may either treat all packets received from the non-participating domain as being members of one flow, or attempt to inspect the packets and distinguish different flows. In the latter case, it must send a request to its QM for each flow it distinguishes. This is an implementation choice for the interface router. However, interface router I is not allowed to send packets with an enhanced QoS into the participating domain until it has received a grant from the QM. It may choose to either buffer the packets until a grant is received or it may forward them into the participating domain as best effort packets until the grant is received. This is an implementation choice for the interface router.

[0109] The more interesting case is when the non-participating domain itself presents a request-grant QoS interface. In this case, interface router I must recognize the request from the non-participating domain and issue a corresponding request to the QM of its domain. This is the same as when a request crosses a boundary between participating domains, except that interface router I must recognize the form of request message native to the non-participating domain. When, at a later time, it receives a grant from its QM, it must generate a native grant message into the non-participating domain. For example, if the non-participating domain is an IntServ domain, interface router I must recognize a PATH message from the non-participating domain and generate a request to the QM in the participating domain. It must also translate a grant from the QM into a corresponding RESV message to return to the non-participating domain. In this way, the interface router acts as a proxy source for members of the non-participating domain in the participating domain, while also acting as a proxy destination for the participating domain in the non-participating domain.

2.2.4 Communication Through Participating and Non-Participating Domains

[0110] Recursive application of the mechanisms described in the previous sections is sufficient to handle all possible cases. FIG. 11 is an example that illustrates something which may not be immediately obvious. In this example, a flow originates at source S in participating domain A, transits participating domain B and arrives at interface router I to non-participating domain C. It transits non-participating domain C and enters participating domain D. It enters participating domain D through interface router I and passes through D to an interface router I connected to non-participating domain E. It passes through this interface router to non-participating domain E, in which it is routed to destination D.

[0111] If we assume non-participating domains C and E distinguish flows and present a request-grant interface, then each can generate a flow ID which must be placed in the headers of the packets which constitute that flow. This is done by the source router for each flow. For non-participating domain C, the flow being marked originates at source S, and source S will put the flow ID in each packet. For non-participating domain E, the interface router at the entry to participating domain D is the source and will put the flow ID in each packet as it enters domain D.

[0112] It is important to recognize that from the point of view of the participating domains, this example illustrates two separate and distinct flows. The first flow originates at source router S and ends at the interface router where packets exit participating domain B. When the packets enter participating domain D, they constitute a new flow. No entity within any participating domain attempts to relate flows in different parts of the network.

[0113] A participating domain considers an interface router at which a flow passes to a non-participating domain to be the effective destination. It does not matter whether the flow reaches a destination within that non-participating domain or eventually enters a different participating domain. The two cases are indistinguishable to the participating domains that contain this flow.

[0114] Likewise, when a flow enters a participating domain through an interface router, this interface router is the effective source. It does not matter whether this flow originated from a source host within the non-participating domain or originally entered the non-participating domain from some other participating domain. The two cases are indistinguishable to the participating domains that contain this flow.

[0115] It is neither necessary nor desirable for the participating domains to realize that these two flows are actually two portions of the same flow. It should be apparent from the preceding sections that it is not necessary. It is also not desirable, because the QoS mechanism in the participating domains is responsible for providing some specified level of QoS to each flow. It cannot make any provision for an “overall” flow which has passed into and back out of some non-participating domain because it has no control over the QoS received while the flow was outside the participating domains. Therefore, it is undesirable to admit the concept of such flows.

2.2.5 Path Dependence

[0116] The DS/DQM QoS mechanism could be characterized as “IntServ by domain.” In this respect, it can be regarded as a modification of IntServ where the flows are kept separately, and the routers are aggregated into domains, rather than viewing the mechanism as a modified version of DiffServ. Hence, the mechanism depends explicitly on the sequence of domains through which the data flow passes, and also on passing into and out of non-participating domains through specific interface routers. However, the mechanism is independent of path within each domain, and independent of the links between two participating domains.

[0117] Thus, to some extent, the route must be constrained. The standard IntServ approach stores this information in a flow table in each router along the path. However, this method is not suitable for DS/DQM, since for DS/DQM, the only fixed points in the path are the source, destination, and interface routers (and interface routers effectively act as proxy sources and destinations). These are also the only points where the request-grant path and the data path are known to coincide. This implies that flows that are to be delivered to non-participating domains must use loose source routing to direct the packets to the correct interface router on the other end of the participating domain.

[0118] Flows which pass through a sequence of participating domains have a reservation along the “domain path,” which is the sequence of participating domains through which the data flow passes. In a dynamic network, this domain path may change. For this reason, the refresh mechanism is the same as the original request-grant mechanism. Periodic refreshes then cause reservations to be made along the new domain path. This is the same mechanism used by standard IntServ to handle changes in its detailed paths. Unlike standard IntServ, however, the data packets receive the same forwarding precedence in all domains whether they have a reservation or not, and there is no interruption in the QoS received by a flow when a domain path changes.

2.3 QM Tables

[0119] There are six tables of information contained within the QM to facilitate the use of the Request-Grant Protocol. These tables keep track of the submitted requests, the granted reservations, the peripheral domains, domain-wide QMs along with pertinent summary information, the reported congested links, and the links to peripheral domains. Because the Request and Reservation ID numbers are assigned locally by each QM, it is necessary to record these to facilitate communications between domains. In all cases, the predecessor refers to the source or QM that is one domain “closer” to the source, and the successor is the destination or QM one domain “closer” to the destination.

2.3.1 Pending Request Table

[0120] This table contains a record of requests that have been sent and have not yet been answered by a grant or denial and have not yet timed out.

• • [0121] QID—The Request ID generated by this QM
  • [0122] PQID—The Predecessor QID, the Request ID of the request that was received and caused this request to be generated.
  • [0123] RID—If refreshing a request, this is the previous Reservation ID, otherwise this is NULL.
  • [0124] PADDR—The Predecessor address, the IP address of the issuer of PQID.
  • [0125] QOS—The Requested level of QoS.
  • [0126] BW—The Requested bandwidth at the above QoS
  • [0127] TIME—This may or may not be a field, but simply indicates that each entry has an associated timer.
    2.3.2 Reservation Table

[0128] This table contains a list of all reservations that have been granted by this QM.

• • [0129] RID—The Reservation ID generated by this QM
  • [0130] SRID—The Successor RID, the reservation ID of the Grant received that triggered this Grant to be made.
  • [0131] QID—The Request ID, generated by this QM when the Request for this reservation was received.
  • [0132] QOS—The Granted level of QoS.
  • [0133] BW—The Granted bandwidth at the above QoS.
  • [0134] PADDR—The Predecessor address, the IP address to which this QM issued a Grant.
  • [0135] SADDR—The Successor address, the IP address from which this QM received a Grant.
  • [0136] TIME—This may or may not be a field, but simply indicates that each entry has an associated timer.
    2.3.3 QM Condition Table

[0137] This table contains a list of all QMs in the same domain, with summary information reported by each. This table includes the information for the local QM.

• • [0138] QM ID—The ID of the QM for this entry
  • [0139] BW Allocated—The amount of BW this QM has allocated to it. The TDB should equal the sum of the allocations of all QMs in the domain.
  • [0140] BW Reserved—The amount of BW this QM has granted in reservations.
  • [0141] Number of peripheral domains—The number of peripheral domains as found in the Peripheral Domain Table, Section 2.3.5.
    • [0142] Domain ID—The ID of the peripheral domain for this subentry
    • [0143] The number of links to the peripheral domain
    • [0144] The total capacity of the links to the peripheral domain
    • [0145] The amount of reserved bandwidth to the peripheral domain
  • [0146] The number of congested links reported by this QM.
  • [0147] TIME—This may or may not be a field, but simply indicates that each entry has an associated timer.
    2.3.4 External Link Table

[0148] This table contains a list of links to peripheral domains that have been reported to this QM by routers within its domain.

• • [0149] Domain ID—The ID of the peripheral domain of the node at the other end of the link.
  • [0150] Link ID—A unique identifier for the link.
  • [0151] Capacity—The total bandwidth available over this link.
  • [0152] TIME—This may or may not be a field, but simply indicates that each entry has an associated timer.
    2.3.5 Peripheral Domain Table

[0153] This table contains a list of all domains other than this QM's domain to which this domain connects. These peripheral domains are either associated with one or more links in this QM's external link table or were received in update messages from other QMs within this domain.

• • [0154] Domain ID—The domain to which this entry refers.
  • [0155] Number of connections to domain—The total number of links to this domain in the external link table and in updates from all other QMs in this domain
  • [0156] BW/QOS—The total bandwidth allocated for each QoS level for each of the connections. The sum of the reported capacities of all the links counted above.
  • [0157] Reserved BW/QOS—The total amount of bandwidth reserved for each QoS level. This is the sum of what this QM has reserved and what all other QMs in this domain report having reserved to this domain.
    2.3.6 Pending QM Grant Table

[0158] This table contains the information about the QM-Grants that have been made, including the QM making the QM-Grant and the bandwidth granted. When a QM-Denial or QM-ACK is received, the entry is deleted if received before the timer expires. This table is used in the Inter-QM protocol described in Section 4.

• • [0159] QM ID—The ID of the QM requesting the bandwidth transfer.
  • [0160] BW—The amount of bandwidth that was QM-Granted to the QM.
  • [0161] TIME—This may or may not be a field, but simply indicates that each entry has an associated timer.
    2.3.7 Congestion Table

[0162] This table contains a list of the links within this QM's domain which have reported congestion

• • [0163] Link ID—This ID must uniquely identify the link to avoid duplication
  • [0164] TIME—This may or may not be a field, but simply indicates that each entry has an associated timer
    3 Domain Organization and Evolution

[0165] To apply the DS/DQM QoS mechanism to a network, that network must be organized into a collection of domains containing one or more routers and connected to one another by external links. In some cases, such as a cluster of terminals connected to a base station and incapable of communicating independently of that base station, this organization is obvious and fixed. In other cases, such as a flat network of nodes that can freely talk amongst themselves, there is no predetermined organization.

[0166] This section describes a mechanism by which a flat, completely democratic network can self organize into a collection of linked domains. This mechanism also provides for detection of topological or traffic distribution anomalies and corresponding adjustments to the domain boundaries. The mechanism also provides for continual evolutionary adjustment in a dynamic network.

[0167] The mechanism frequently refers to the origin of a domain. This origin is the node that originated the formation of the domain by spontaneously sending organization messages to its neighbors. The origin is also the zero-point for the domain hop counts, which may be considered a coordinate system in the domain. The original origin of a domain is necessarily also a QM, but has no other significance. If the origin of the domain later moves to another network element, it may no longer be a QM.

[0168] This domain organization mechanism operates on every router in the network, with input information as the current condition of the router and the current condition of the router on the other end of each link connected to this router. The mechanism runs at start up and in response to certain events, such as a change in the condition of the router or receiving an organization message from a neighbor.

[0169] The goal of the algorithm is to organize the network into a set of one or more compact domains, and, if bottlenecks are detected in the topology, to adjust domain boundaries to coincide with these bottlenecks. It is further intended that this domain organization be fluid and continuously adapting to changes in the dynamic network. This is to be done as locally as possible with a minimum of overhead.

3.1 Router Condition Tables

[0170] There are two sets of information that all of the network routers must maintain, the network element state table and the link state table. The organization algorithm uses these two pieces of information to continuously update the domain formations.

3.1.1 Network Element Condition Table

[0171] This table is maintained in every router, and includes the hop count and ID numbers of the domain and the QM, as well as other domain specific information. The table is shared with the element's immediate neighbors upon any change in condition via the organization message defined in Section 6.2.1. Note that each element can be in one of four domain states, NO_DOMAIN, DOMAIN_ACQUIRED, DOMAIN_REQUIRED, or DOMAIN_EXCLUDED.

• • [0172] Domain State—This indicates if a domain has been acquired or not, or if the domain indicated is excluded from use.
  • [0173] Domain Origin (DO) Address—The address of the domain origin.
  • [0174] Domain ID—The ID of the Domain, which is a composite of the domain origin address and the UNIX time of domain creation.
  • [0175] Domain Hop Count—The number of hops from the network element to the domain origin.
  • [0176] QM ID—The ID of the QoS Manager that this network element uses.
  • [0177] QM Hop Count—The number of hops from this network element to the QoS Manager.
    3.1.2 Link Condition Table

[0178] This table of information contains the link ID and other information, which is used in the domain organization algorithm. Information regarding congestion on the link is forwarded to the QM as necessary.

• • [0179] Link ID—The ID of the link, which, when combined with the network element address, creates a unique ID for the link.
  • [0180] Congestion State—Flag that indicates if the link is congested or not.
  • [0181] Network Element State—The condition of the network element on the other end of the link, as described in Section 3.1.1.
    3.2 Domain Organization

[0182] When a group of routers is first started up, they will not be organized into domains, and the domain acquired state is NO_DOMAIN. Each router will only know the location and interfaces to use to communicate with its nearest neighbors, which are defined as those network elements a single hop away, and will not know the location of a QoS Manager to use for packet admission control. There is also a timer started in each router, which has length determined by a random seed. If a router does not receive an organizational message, as defined in Section 6.2.1, before the timer ends, the router becomes a domain origin (DO). In FIG. 12, this would be router six, labeled as “DO”. The domain origin creates the domain ID, which consists of the DO's IP address and the current UNIX time. The router sets both the domain and QM hop counts to zero, and the domain origin address and QM ID to its own address. It then changes the domain-acquired state to DOMAIN_ACQUIRED, and sends organization messages to each of its neighbors; for router six, this means that messages are sent to routers 2, 5, and 10.

[0183] When a router receives an organization message, the router updates the link condition table for that link, and then compares this new information to its own condition. For example, router 10 will first check its domain-acquired state. If it is NO_DOMAIN, and the link is not marked as congested, router 10 will change state to DOMAIN_ACQUIRED, and update its condition table to include the DO address and the domain and QM ID numbers. Router 10 then sets both its hop counts to one greater than those included in the message. Since there has been a change in the element condition, router 10 sends organization messages to each of its neighbors, routers 5, 6, 14, 13, and 9.

[0184] If a router receives an organization message, it updates the link condition table, and then examines if further processing is needed. If the router has a domain state of DOMAIN_ACQUIRED, the domain IDs and QM IDs match those in the local condition table, and the QM hop count is below the threshold, no further action is needed. If the domain state is DOMAIN_ACQUIRED and the IDs do not match the local table, or the QM hop count is above the threshold, more processing is required. The router could decide to switch to a different QM, become a new QM, or even change to a new domain. If the domain state is NO_DOMAIN, the router performs the same actions as router 10 did above, accepting all the new information as its own, including sending out messages to its neighbors. For example, router 13 would send organization messages to routers 9, 10, 14, 17, 16, and 12, and router 14 would send messages to routers 10, 13, 17, and 19. Note that the messages are fanning out from the DO, and eventually all the routers will have a QM. This is shown in FIG. 12, with the DO/QM shown in router 6, and all the other routers marked with the appropriate QM and domain hop counts. Note that since there is only a single QM for the domain, the domain and QM hop counts are the same for all the routers.

3.2.1 Multiple QoS Managers

[0185] One of the valuable features of the DS/DQM mechanism, when used in a mobile network, is the ability for the QoS Managers to be distributed. Therefore, there must be a way to create QMs in the domain in addition to the DO. As the organization messages are exchanged between routers that are farther and farther away from the DO, the hop counts will become larger. This QM hop count can be used to determine which routers become QMs.

[0186] Eventually the QM hop count will pass a set threshold. This threshold is the maximum number of hops that a router can be from its QM. If for any reason a router selects a QM with a QM hop count greater than the threshold value, it will start a timer based on a random seed. If the timer ends before the router selects a QM with an acceptable threshold, the router will become a QM. The router then sets the QM ID to its own IP address and the QM hop count to zero in the element condition table. Organization messages are then sent to all of the router's neighbors, with the updated QM ID and hop count information. This change in QM will propagate back towards the other QM(s) in the domain, until all routers in the domain have selected a QM within the acceptable hop count range.

[0187] FIG. 13 shows the example network from above, except with multiple QMs selected. Note that the QM threshold value in this example is a hop count of three, contrasted with the domain hop count that has a value of four in some routers. Increasing the threshold value would cause there to be fewer QMs, and for them to be farther apart. The size of the threshold also determines if there are multiple QMs in small networks, or if the DO will be the only QM.

3.2.2 QM or Domain Change

[0188] When a router with domain state DOMAIN_ACQUIRED receives an organization message, it compares the information contained in the message to that in its own condition table. If the two sets of data are different, the router might have reason to change to this other QM or domain. In making this decision, the condition table for each link needs to be examined for more information.

[0189] When deciding which QM to record in the condition table, the QM hop counts of the local condition table and those contained in the link condition tables are consulted. The QM with the lowest hop count is selected. If this is the QM already in the condition table, the hop count is checked to ensure that it is one greater than the lowest hop count to that QM. If the selected QM is not the one currently in the condition table, the QM ID is updated, and the hop count is changed to one more than the lowest known hop count to that QM. If there has been a change to the condition table, this router sends organization messages to its nearest neighbors with the new information.

[0190] The decision of which domain to select is dependent on the number of links associated with each domain and the domain hop count of each link. The domain that is associated with more links is selected, and the condition table is updated, using the link with the smallest hop counts. If there are two or more domains associated with the same number of links, the domain with the smallest hop count is selected, and then the condition table is updated. If multiple domains are associated with the same number of links and have the same smallest hop count, a domain is arbitrarily selected, possibly by smallest domain ID. When a new domain is selected, the domain ID, domain hop count, QM ID, and QM hop count are updated in the condition table, and then organization messages are sent to each of the router's nearest neighbors. No messages are sent if the condition table has not changed.

[0191] Given the way the domain organization works, it is expected that the domain is pulled along with a moving origin, with nodes switching into the domain as its origin approaches and the nodes left behind switching to other domains as the origin recedes. However, it is important to note how the domain origin processes organization messages. Clearly, it has a fixed hop count of 0 and does not recompute its hop count based on its neighbors. The DO does need to pay attention to the domain IDs of its neighbors. If the domain origin determines that a majority of its neighbors have a different domain ID, it should switch to the new domain and then compute its hop count in the new domain, in which it would not be the origin. If the domain origin should lose contact with all of its neighbors for any reason, it ceases to be a domain origin. If it subsequently comes back into contact, it behaves as any other node coming into contact would, and therefore, does not assume it is still a domain origin.

3.2.3 Loss of Domain Origin

[0192] The domain organization mechanism is based on hop count distances from a domain origin, which is the node that started the organization process by issuing the organization message to its neighbors. This particular node remains fixed at a hop count of 0. All other nodes set their hop count to the smallest value of any of their neighbors plus 1. The problem is that when the origin, the fixed 0 point, disappears, the mechanism becomes unstable, since all nodes cannot have a hop count 1 greater than the lowest hop count of any of their neighbors if none of the hop counts are fixed.

[0193] When a node of hop count 1 loses the link to the origin, it does not automatically recalculate its domain hop count. Instead, it sends a domain origin check message to the saved domain origin address. If the domain origin has simply lost the connection with this node but is still active in the domain, it responds to the origin check message. When the node receives a response to its probe, it then recalculates its domain hop count in the usual way. If the node times out waiting for a response to the probe, it then assumes the domain origin is actually missing. It has either disappeared or moved into another domain. It sets a random timer, which is necessary because all of the old origin's neighbors should discover its absence at about the same time.

[0194] When the random timer times out on one of these 1 hop nodes, that node sets its domain hop count to 0, and then issues organization messages to all of its neighbors which contain its own IP address as the domain origin address. When all the outstanding reservations between peripheral domains, etc., which depend upon the domain ID are considered, it seems apparent that the domain ID should not change, but that the original one should be maintained. This is why the domain origin address needs to be saved separately from the domain ID, even if the domain ID is the IP address of the original domain origin. When a node that is waiting on its random timer receives an organization message containing a domain origin address that is different from the saved domain origin address, it cancels the random timer, saves the new domain origin address, and recomputes its domain hop count in the usual way.

[0195] The principal problem is what subsequently happens to the old domain origin. If that origin has been destroyed, there is no problem. On the other hand, if it has just moved to another domain or been temporarily out of contact and subsequently returns, there is a potential problem. There are cases where a new domain is formed by means of one node timing out and creating a new domain using its IP address as the domain origin. As long as the domain which has selected a new origin does not change its domain ID, and the old origin is floating around out there somewhere and could possibly become the origin of a new domain, the possibility of having multiple domains with the same domain ID exists. For this reason, a domain ID that is not identical to the IP address of the founding domain origin is used. The IP address was chosen as the easy way to guarantee uniqueness, but additional information needs to be added so that if the same node creates another domain at some later time, it will compute a new and different domain ID. Therefore, the domain ID is composed of the IP address of the domain origin and the UNIX time at creation of the domain.

3.3 Domain Evolution

[0196] As changes occur in the mobile network, routers may leave and enter the network at any time, causing the conditions of each router to also change and triggering organization messages to be sent. Changes in the network may also trigger congestion in a specific link, which will cause the domain to split into two pieces along that link. When routers and other network elements move, parts of the network will become closer together, which will trigger a domain merge.

3.3.1 Domain Splitting

[0197] A domain split is needed if persistent and heavy congestion exists on a single or few links that a single router reports to its QM, which is detected by long queues and delays at the link layer. The organization message with the DOMAIN_EXCLUDED state is used to initiate a domain split. When an organization message is received with this state indicated, the network element checks the domain ID listed to its own domain ID. If they are the same, and the current domain hop count is greater than that in the message, the element sets its own domain state to DOMAIN_EXCLUDED, and sets a random timer to become a new domain origin. Another organization message is then sent to the neighbors with the DOMAIN_EXCLUDED state set. At this point, the network element is waiting to receive an organization message or to become a domain origin, as discussed in Section 3.2. Note that the excluded domain is not remembered after a new domain is acquired.

3.3.2 Domain Merging

[0198] Included in the information shared among the QMs is the list of peripheral domains, and how many links exist from that QM (or routers that reported to it) to each peripheral domain. When the total number of links to the peripheral domain from this domain exceeds a threshold value, organizational messages with the DOMAIN_REQUIRED state and the current domain ID of the chosen domain are sent to the routers in the peripheral domain by the QM of the chosen domain with the most links to that domain. Upon receiving this message, the network element will change its condition information to be the new domain, and then send the organization message with a DOMAIN_REQUIRED state to its neighbors that have the domain ID of its former domain. In this way, the former domain will become part of the selected domain.

4 Inter-QoS Manager Communication Protocol

[0199] To function correctly, the QoS Managers need to communicate among themselves at certain times to update the tables described in Section 2.3. The QMs share information about their own condition, as well as sharing what other QMs exist in the domain. A QM sends update messages to all the QMs it has in its QM condition table. These update messages include three different types of information, and are sent when the information changes exceed a certain configurable threshold.

[0200] The first type is an actual update of the QM's own condition. It includes the QM ID, the amount of bandwidth allocated to the QM, as well as the amount of bandwidth reserved by this QM, the number of congested links that have been reported to the QM by routers, and a timestamp on this data. The second type includes peripheral domain information. This includes the ID of the peripheral domain, the number of links to the domain that this router is aware of, and the total amount of bandwidth that is available from the domain, as well as reserved from the domain on those links. These first two types of information are sent out in a QM Update message when any of the bandwidth values, either allocated or reserved, change by a threshold amount. This threshold will be measured as a percentage of the previous value sent in the last update message. The last type of update is the QM list message, which includes the list of known QM IDs. This is sent whenever a new QM is added to the list and by a newly created QM.

[0201] These three types of update messages are used to discover new QMs in the domain, distribute and change the TDB due to changes in the domain, and maintain control of the domain bandwidth if a QM fails.

4.1 Discovery of New QMs

[0202] The domain information is distributed throughout the domain and stored in each of the QMs. This information is updated each time an update message is received from another QM. However, for the QMs to know where to send the updates, each QM must have a list of all of the QMs in the domain. The QM list message is used to facilitate this process, as well as information in the organization message.

[0203] The first QM created in the domain is the domain origin. At this point, there is only one QM, and it, therefore, knows about all the QMs in the domain, because it is the only one. As the routers receive organization messages, more QMs will be added to the domain as necessary. A router that becomes a QM knows about at least one other QM in the domain, because there was a QM listed in the organization message that it received, but that QM was too many hops away to select. Therefore, the new QM knows about itself and one other. This new QM will send out a QM list message to all the QMs on its list, informing them of this QM's existence.

[0204] When a QM receives a QM list message, the list is checked against the QM IDs contained in the QM's internal table. If the two lists match, no further action is needed. If there are QM(s) in the table that are not on the list, send a QM list message to the message source. If there are QM(s) on the list that are not in the table, add the QM(s) to the table. This change in the table triggers the QM list message to be sent from this QM to the other QMs on the list. Several messages may be received or sent by each QM before the process has ended. After this process is complete, each QM in the domain will have a complete list of the QMs contained in its internal table.

4.2 Distributing TDB Among QMs

[0205] In order for the TDB to be a useful concept, it must be allocated appropriately among the QMs in the domain, so that each QM can reserve bandwidth as requested. To facilitate the TDB distribution, another set of messages is needed, namely a QM Request, a QM Grant, a QM Denial, and a QM ACK. Using these messages, the QMs are able to make bandwidth available to the areas of the domain that need it.

[0206] When QMs are created, including the domain origin, they assume an initial bandwidth allocation of the bandwidth of the smallest link they are connected to. If more bandwidth is needed than what the QM currently is allocated, it must be granted a bandwidth allocation from another QM. These granted allocations are permanent; that is, the granting QM decrements its allocation by the granted amount, and the receiving QM's allocation is incremented. This also enforces the fact that a QM may not use the bandwidth of another QM until it has been granted.

[0207] When a QM (QM-A) needs more bandwidth than it is currently allocated, it may request allocation from another QM (QM-B), and QM-B either grants or denies the request. QM-A then responds to this with a QM ACK, completing the three-way handshake, as shown in the two message sequences in FIG. 14. QM-B decrements its allocation when the QM Grant is sent, and QM-A increments its allocation upon receiving the QM Grant. If QM-B does not receive a QM ACK, it increments its allocation back up to what it was before the QM Grant.

[0208] Each QM should attempt to maintain an allocation above the amount of reservations, so that Requests will not be unnecessarily denied. For this reason, if the unreserved bandwidth becomes less than 10% of the amount of reserved bandwidth, the QM will QM Request enough bandwidth so that the amount of unreserved bandwidth will exceed this level. However, the Requests must be made of QMs that have at least 20% more allocated bandwidth than reserved. If there are no QMs in the domain that have this amount of unreserved bandwidth, the QM is not able to request more.

4.3 Changing the TDB

[0209] The TDB must be able to react to changes in the network that affect the load the domain can handle. Each QM is responsible for appropriately reacting to congestion by changing the amount of its allocated bandwidth, which is facilitated by periodically checking the internal QM congestion table. The allocation for each QM is incremented and decremented as needed, and the TDB is then calculated as the sum of the allocations.

4.3.1 Incrementing

[0210] If no congestion is found in the QM's internal congestion table, the sum of reservations is compared to the allocation amount. If the sum of reservations is less than the allocation, no action is taken. If the sum of reservations is greater than or equal, within 10%, to the allocations, the QM increases its own allocation by a small fixed amount, which will be called x. This method allows the TDB to automatically increase as load is increased in a non-congested domain, until congestion is detected.

[0211] It may be possible that the allocation will be incremented after several consecutive checks of the congestion table. If this occurs, the fourth increment will be by 2x. Another increment after this would again be only x bandwidth.

4.3.2 Decrementing

[0212] If congestion is found to exist and is noted in the internal congestion table, the sum of reservations is compared to the amount of allocation. If the sum of reservations is greater than the allocation amount, no action is taken. If the sum of reservations is less than or equal to the allocation amount, the allocation is decremented.

[0213] The amount that the allocation is decremented depends on previous congestion responses by this QM. If the previous check of the congestion table resulted in an increment or no action, the allocation is decremented by x. If this is the second consecutive decrement, the allocation is decremented by 2x, and the third consecutive decrement is by 4x. If the next congestion check still shows congestion, a QM Congestion message, as defined in Section 6.3.3, is sent to the other QMs in the domain. This will result in the other QMs decrementing their allocation by x.

[0214] When the amount of allocation is less than the sum of reservations, no more requests are granted. If the allocation is decremented two or more consecutive times, Denials may be sent to the hosts to terminate currently active reservations.

4.4 Recovery after Failure of a QM

[0215] This mechanism is designed to perform well in a dynamic and mobile network. Therefore, it is expected that routers, including QMs, will be entering and leaving the network at any time. This means that there must be a way for the domain to efficiently recover after a QM fails or otherwise leaves the domain. There are three steps to this recovery. First, at least some part of the domain must recognize the fact that a QM has failed. Next, the remaining QMs must coordinate to ensure that only one QM attempts recovery. Finally, the selected QM performs the actual recovery.

4.4.1 Detecting a Failed QM

[0216] There are two possible ways that the elements in the domain would discover that a QM has failed. The first is that the QM simply does not respond to an inter-QM protocol message. The second is that a host sends a QM a release for a reservation that it did not grant, as in FIG. 6, which implies that the QM that did grant the reservation has failed.

[0217] Once a failed QM has been identified by another QM, it is possible to verify the failure by sending a ping-type message to the failed QM, which would be similar in format to the domain origin check message described in Section 6.2.4.

4.4.2 Coordinating for Recovery

[0218] When a QM is declared failed, it is necessary that only one other QM is responsible for recovery from the loss. If multiple QMs attempted to recover the TDB from the failed QM at the same time, the TDB would increase incorrectly, which could cause unnecessary faulty performance as more traffic is admitted to the domain than the domain can appropriately handle.

[0219] The QM that discovers the failed QM sends a Failed QM message to the domain origin. The domain origin responds to the first Failed QM message that it receives with a Failed ACK message, indicating that this QM will recover the portion of the TDB allocated to the failed QM. After the QM receives the ACK message, it sends the Failed QM message to all the QMs in the domain. When a QM (including the domain origin) receives a Failed QM message, it will respond by appropriately deleting the failed QM's entry from its tables. If a QM receives this message and it refers to a QM that does not exist in its table, the message will be ignored.

4.4.3 Recovering

[0220] When a QM receives the Failed ACK message from the DO, it knows that it has gained control of the failed QM. At this point it sets a timer to the time for which reservations are granted, since this is the longest possible time for any outstanding reservation to exist. When the timer expires, the allocation of the failed QM is added to the allocation of the controlling QM.

5 Routing Considerations

[0221] Each router must inspect the destination address of each IP packet it receives, select a next hop from among its connections, and forward the packet to that next hop according to a PHB specified by the packet's DS codepoint. This will be done based on a routing table, which is outside the scope of this paper, provided by an external mechanism, such as that developed the MOSAIC IP Mobility program, and a set of rules for selecting one next hop when multiple possibilities are present in the table. The routing mechanism is required to distribute the load that it receives as evenly as possible over the set of paths that include the next hops available for each destination. It must also trap certain messages from external links and redirect them to the router's QM rather than the destination. The following sections describe the expectations of the routing table and mechanism, and a proposed set of PHBs.

[0222] Note that both the routing table information and the set of PHBs presented in this section is the most accurate available to date, but is subject to future change.

5.1 Routing Table

[0223] Routing decisions are based on information that will be provided by the network routing discovery mechanism, which is outside the scope of this paper. This information is to be provided in the form of a routing table. This routing table consists of entries indexed by destination address, and includes a set of metrics with which to select a next hop for each packet. A proposed set of metrics is shown in Table 2, with descriptions of each, along with other relevant table entries. This set of metrics is merely included as a possible solution. The actual routing table to be used is dependent upon the final decision of the IP Mobility project, and is not available at this time.

[0224]

TABLE 2
Proposed Routing Table
Field	Description
DEST	The address of the destination of the route.
M_HOP	Metric indicating the number of hops taken by the route to the
	destination.
M_BW	Metric indicating max possible bandwidth of the route
	(computed as the min of all the bandwidths of all the links
	along the route)
M_LAT	Metric indicating min possible latency of the route (computed
	as the max of all the latencies of all the links along the route)
M_REL	Metric indicating reliability of the route (composite of
	the route)
M_COST	Metric indicating network cost of the route (perceived cost as
	indicated by the type of links taken by the route)
AGE	Time (in seconds) since this route was updated

[0225] The five proposed metrics listed, hop count, bandwidth, latency, reliability, and cost, will be used in computing which next hop to select. The age of the data for that route might also be considered. The details of how these metrics are defined and how they are compounded, as well as exactly how they are used, cannot be made specific until the route discovery mechanism is defined. The QoS mechanism must be able to be easily adjusted to work with whatever routing table is actually provided.

5.2 Routing Engine

[0226] The routing mechanism must process all received packets, as well as all packets originating within the router and addressed to another network destination. In processing these packets, the router performs several functions in determining what the correct action is to take.

[0227] If the packet is a request message from an external link, marked with the Alert Option field, the packet must be readdressed to this router's QM, and then forwarded as any other packet. If the destination address matches this router's IP address, the packet is extracted from the input packet stream, and sent to the router's IP stack.

[0228] For all other packets, the routing table must be searched for all entries that match the destination address of the packet. If there are one or more entries with suitable QoS metrics for the packet, those that do not have suitable metrics are ignored. When there are no entries with suitable QoS metrics, the packet is forwarded, using the best available service. Select the next hop table entry according to the weighting policy assigned for the QoS marked in the packet, using the available QoS metrics in the table. If there are multiple next hops with similar metrics, make an arbitrary selection. When exactly one possible next hop has been identified using these selection criteria, determine the appropriate interface for the selected route, and queue the packet for transmission on that interface according to its QoS marking.

[0229] In queuing the packet to the next hop interface, it is expected that the interface will provide multiple queues and a queue must be selected according to the DS codepoint. Note that packets directed to a non-participating domain are not routed in this way and must have been processed at some level in the stack of the router and passed back down directly to the interface to that non-participating domain. Whenever the interface is ready to transmit a packet, it will select the next packet to send based on the PHB rules, as described in Section 5.3. These rules will also govern how exceptional conditions are handled, e.g. packet discard when the appropriate queue for the target interface is full. Depending upon the DS codepoint of the packet, this condition may also be the cause of sending a congestion report to the router's QM.

5.3 Per Hop Behaviors

[0230] Each router must provide a set of PHBs by which packets are queued for forwarding. Per hop behaviors are the set of queuing and scheduling policies applied to the traffic on each outgoing link of each router in the network; the available PHBs are expected to be the same throughout a participating domain. Each packet is marked with one of these categories of service by the originator in accordance with the traffic admission mechanism.

[0231] There is a logical difference between the set of PHBs available at each router and the overall levels of QoS provided by the mechanism. In practice, little distinction is made, as all packets of a certain QoS level are marked with the same PHB selector (DiffServ codepoint) and conversely, all packets with the same PHB selector receive the same QoS. It should be clear from context whether a reference is to PHBs or levels of QoS.

[0232] A queue, a priority, an allocation, and a discard policy are defined for each PHB. Without going into implementation details, a minimum of four PHBs is expected. Elaboration into further levels of service is possible. The packets are selected from the queues for transmission, using weighted fair queuing, where the queue weights and link bandwidth allocations are configurable parameters per output link. All routers in a participating domain must offer the same set of PHBs on each output link, but these configurable parameters are not required to have the same value for all routers. Note that the DS/DQM mechanism is not dependent on any set of PHBs. The set described here is a proposed set, and is only accurate as of the date of this paper.

[0233]

TABLE 3
Service Level and Codepoint Fields
Service	Codepoint	Scheduled
Level	*msb	Priority	Typical Applications
Flash	*111/xxx	High, Absolute	Critical Situational Awareness
			(e.g. gas alert, bailout)
Expedited	*101/110	High, Absolute	High-priority voice
Assured 2-	*010/001	High,	Low-latency Command and
Preferred		Weighted	Control
Assured 2	*010/000	High,	Low-latency Situational
		Weighted	Awareness
Assured 1-	*001/001	Medium,	Voice
Preferred		Weighted
Assured 1	*001/000	Medium,	Low-latency video
		Weighted
Best Effort-	*000/001	Low, Weighted	Command and Control,
Preferred			Situational Awareness
Best Effort	*000/000	Low, Weighted	Video, file transfers, email,
			etc.

[0234] A hierarchical queue structure is used to implement the desired behavior. Five queues are established: Flash, Expedited, Assured 2, Assured 1, and Best Effort, as described in Table 3. These queues are specified with the three most significant bits of the codepoint, called the Class Selector. The Assured 1-Preferred, Assured 2-Preferred and Best Effort-Preferred levels are handled within the Assured 2, Assured 1 and Best Effort queues, respectively. The “-Preferred” marking indicates a preference for non-discarding should congestion occur.

[0235] Packets are taken from the Flash queue first on an absolute priority basis. If the Flash queue is empty, packets are taken from the Expedited queue on an absolute priority basis. If both the Flash and Expedited queues are empty, packets are taken on a Weighted Fair Queuing (WFQ) basis from the three remaining levels. It is intended that the various percentage levels for the WFQ algorithm be administratively controllable at runtime.

[0236] The absolute priority of the Flash category means that when using Flash service, there is no weighting or fairness algorithm with regard to lower priority traffic; Flash traffic can completely shut out other traffic. Packets in this queue may never be discarded; packets with lower priority will be discarded to make room if necessary. Traffic volume in this category is not limited, but is expected to be very low, with a frequency of less than 10⁻⁴ packets per second and a packet size limited to 100 bytes per packet. Significant traffic levels in this category would seriously impair all other traffic. The Flash service is provided for critical low volume traffic, e.g. threat warning or fire control. Single packet messages are envisioned, possibly predefined with bit field data, so that multiple packets arriving at the same time can be merged by a user provided application function in each router rather than queued. Such packets may be sent without admission control. The intent is to provide extremely fast service for highly critical discrete data. Obviously these are largely application issues, and providing this level of service is dangerous in terms of potential for misuse and resulting poor overall performance.

[0237] The Expedited queue provides an absolute priority over the lower classes of service. Therefore, this queue is emptied of packets before any lower queues are processed, and should only be used when the highest priority is needed. Packets in this queue are discarded last, but the traffic volume of this category will be as allocated by the RGP.

[0238] The remaining service categories, Assured 2, Assured 1, and Best Effort, are for regular traffic flows of arbitrary size and duration. These flows are divided into high, medium, and low priorities. The priorities are weighted to assure that high priority traffic cannot starve out all lower priority traffic. Their discard policies are in inverse proportion to their priority; i.e. low priority packets are discarded first when queue space is exhausted. These priorities are subdivided into two classes of service distinguished by preferred status. A packet with preferred status has the same priority as one without preferred status, but with minimized discard. This service is for packets that are not time critical but need reliable delivery. It is also limited to an allocated share of the link bandwidth.

[0239] Traffic volume for Assured 2 and Assured 1 is limited to a specified proportion of the link bandwidth. It is an open question whether to enforce this allocation limit at each link or accept the limitation as imposed by admission control and allow the usage on individual links to fluctuate. In the latter case, higher priority packets are allowed to “hog” the link at times to partially compensate for the approximate nature of admission control, at the expense of lower priority traffic. Note that it is implicit in this case that the queue weight would be higher than the link allocation.

[0240] Best Effort service is first in line to be discarded and absorbs all unused bandwidth on the link. It corresponds to conventional best effort service and is not limited. Note that there is a preferred status available in the Best Effort category, which is limited to an allocated share of the bandwidth as in the higher priorities.

6 DS/DQM Protocol Packet Formats

[0241] All DS/DQM messages will be User Datagram Protocol (UDP) messages. UDP sits on top of IP. The diagram in FIG. 15 represents the basic UDP/IP header that will be used to support all QM messages.

[0242] There are two areas in this packet format that are slightly different than normal, but within the UDP/IP Specification. These areas are shaded in gray. The first area is the DiffServ Code Point. This 6-bit field is where the packet priority is stored. This is different from the Type of Service fields that are normally in this location. The second is the IP Alert Code in the options field. This alert will only be used in the Request message. This is because the request message needs to be routed to the QM as it moves toward the destination. This option will allow the routers to quickly identify a request message and forward it to the QM as necessary.

[0243] There are several messages that are used in the protocol, including the five RGP messages, as well as a congestion report message, an end-to-end feedback message, an organization message, and a QM update message. A message type field identifies the different messages and is defined by an 8-bit field located at the beginning of the body of the message. The Message Type Byte is defined in Table 4. All message bodies reside on top of the UDP/IP packet header show in FIG. 15.

[0244]

TABLE 4
Message Type
		Message Type
	Message	Byte
	Request	00000001
	Trial-Request	00000010
	Grant	00000011
	Denial	00000100
	Trial-Denial	00000101
	Release	00000110
	Release ACK	00000111
	RGP Time-Out	00001000
	Organization	00001001
	Congestion Report	00001010
	Congestion Clear	00001011
	ELR	00001100
	Domain Origin	00001101
	Check
	QM Update	00001110
	Message
	QM Update ACK	00001111
	QM Congestion	00010000
	Peripheral	00010001
	Domains
	QM List	00010010
	Failed QM	00010011
	Failed ACK	00010100
	QM Check	00010101
	QM Request	00010110
	QM Grant	00010111
	QM Denial	00011000
	QM ACK	00011001

[0245] In the following message formats, the bandwidth and QoS fields all have consistent units. Bandwidth is measured in kilobits per second, allowing a range from 1 kb/s to 64 Mb/s. The QoS field consists of the codepoint byte to be used, as described in Section 5.3.

6.1 RGP Packet Formats

[0246] This section defines the protocol formats for the five messages that are used as shown in Section 2.1, including the Request, Trial-Request, Grant, Denial, Trial-Denial, Release, Release Acknowledgement, and RGP Time-Out.

6.1.1 Request

[0247] The message packet format is as shown in FIG. 16, with the fields as defined below. The Request is sent to the destination, although often rerouted to a QM, except that the Request sent by the source is sent directly to its QM.

[0248]

Message Type	This is the message type as defined in Table 4.
Quality of Service	The QMs use the Quality of Service Requested
Requested	field when admitting the packets to the domain.
	The selected value will be mapped into the DiffServ
	Code Point in the IP header.
Bandwidth	This field contains the amount of bandwidth that
Requested	the application would like to reserve.
QM ID	The ID of the QM that generated the Reservation if
	this is a refresh. This value is NULL if it is a new
	Request.
Domain ID	The ID of the domain that originated this Request
	message.
RID	The Reservation ID generated by this QM if this is
	a refresh. This value is NULL if it is in a new
	Request.
QID	The Request Identification number generated by
	the sender of the Request.
Message Source	This field contains the port address of the host
Port	application that originated the request.
Message Destination	This field contains the port address of the
Port	destination application for which this flow is
	destined.
Message Source IP	This field contains the IP address of the host that
	originated the request.
Message Destination	This field contains the IP address of the original
IP	destination.

6.1.2 Trial-Request

[0249] This message packet format is as shown in FIG. 17, with the fields as defined below. The Trial-Request message is sent to the destination, although often rerouted to a QM.

[0250]

Message Type	This is the message type as defined in Table 4.
Suggested Quality of	This field contains the suggested QoS level at
Service	which the QM can Grant this Request.
Suggested Bandwidth	This field contains the maximum amount of
	bandwidth that the QM can reserve for this
	Request.
QM ID	The ID of the QM that generated the
	Reservation if this is a refresh. This value is
	NULL if it is a new Request.
Domain ID	The ID of the domain that originated this
	Request message.
RID	The Reservation ID generated by this QM if
	this is a refresh. This value is NULL if it is
	in a new Request.
QID	The Request Identification number generated
	by the sender of the Request.
Message Source Port	This field contains the port address of the host
	application that originated the request.
Message Destination	This field contains the port address of the
Port	destination application for which this flow is
	destined.
Message Source IP	This field contains the IP address of the host
	that originated the request.
Message Destination IP	This field contains the IP address of the
	original destination.

6.1.3 Grant

[0251] The message packet format is as shown in FIG. 18, with the fields as defined below. The Grant message is sent to the predecessor QM or the source in response to a Request. The Option Length and Data fields are optional; they will only be present if options need to be included in the IP header.

[0252]

Message Type	This is the message type as defined in Table 4.
Granted Quality of	This field contains the quality of service that
Service	has been granted by the QM. This will be the
	same as the request. The field is simply
	used for confirmation.
Bandwidth Reserved	This field contains the amount of bandwidth
	that was granted. This, like the Granted QoS,
	should be the same as the request.
RID	The Reservation ID generated by this QM.
QID	The Request ID from PQID in pending request
	table of Grant generator.
Duration Reservation	This field contains the amount of time for
Valid	which the grant is valid.
QM ID	The ID of the QM that generated the Grant.
Message Source IP	This field contains the IP address of the host
	that originated the request.
Message Destination IP	This field contains the IP address of the
	original destination.
Option Length	This field contains the length of the Option
	Data field.
Option Data	This field contains any option information that
	needs to be included in the IP header of the
	data packets. This field will be pre-formatted
	into the proper format, and merely be copied
	onto the end of the IP header. This field can
	be up to 40 bytes long.

6.1.4 Denial

[0253] The message packet format is as shown in FIG. 19, with the fields as defined below. The Denial message is sent to the predecessor QM or the source in response to a Request.

[0254]

Message Type	This is the message type as defined in Table 4.
Suggested Quality	This field contains a recommendation of what
of Service	quality of service the application should ask for.
Suggested	This field contains a recommendation of what
Bandwidth	amount of bandwidth the application should ask
	for.
QID	The Request ID number of the Request being
	answered. This is found in the pending request
	table of the QM generating this message.
Message Source IP	This field contains the IP address of the host that
	originated the request.
Message	This field contains the IP address of the original
Destination IP	destination.

6.1.5 Trial-Denial

[0255] The message packet format is as shown in FIG. 20 with the fields as defined below. The Trial-Denial message is sent to the predecessor QM or the source in response to a Trial-Request or Request.

[0256]

Message Type	This is the message type as defined in Table 4.
Suggested Quality	This field contains a recommendation of what
of Service	quality of service the application should ask for.
Suggested	This field contains a recommendation of what
Bandwidth	amount of bandwidth the application should ask
	for.
QID	The Request ID number of the Request being
	answered. This is found in the pending request
	table of the QM generating this message.
Message Source IP	This field contains the IP address of the host that
	originated the request.
Message	This field contains the IP address of the original
Destination IP	destination.

6.1.6 Release

[0257] The message packet format is as shown in FIG. 21, with the fields as defined below. The Release message is sent to the Successor QM or destination.

[0258]

Message Type	This is the message type as defined in Table 4.
Quality of Service	This field contains the quality of service that has
	been granted by the QM.
Bandwidth Reserved	This field contains the amount of bandwidth that
	was granted.
RID	The Reservation ID generated by this QM.
QID	The Request ID from PQID in pending request table
	of Release generator.
QM ID	The ID of the QM that Granted the reservation.

6.1.7 Release Acknowledgement

[0259] The Release acknowledgement message is sent from the QM back to the Host. This lets the host know that the QM has received its release. If the Host does not get an acknowledgement back from the host, it will assume the QM has been disabled and try to find a new QM.

[0260]

Message Type	This is the message type as defined in Table 4.
Quality of Service	This field contains the quality of service that
	has been granted by the QM.
Bandwidth Reserved	This field contains the amount of bandwidth that
	was granted.
RID	The Reservation ID generated by this QM.

6.1.8 RGP Time-Out

[0261] The RGP Time-Out message is sent from a QM to the predecessor, either a QM or host, when a Request has timed out. The message allows the QMs along the domain path to share information about the flow when possible.

[0262]

Message Type	This is the message type as defined in Table 4.
Quality of Service	This field contains the QoS associated with the
Requested	message that timed out.
Bandwidth Requested	This field contains the amount of bandwidth
	associated with the message that timed out.
QM ID	The ID of the QM that generated the Time-Out
	message.
RID	The Reservation ID generated by this QM if a
	Request refresh. This value is NULL if a new
	Request timed out.
QID	The Request Identification number generated by
	the sender of the Time-Out message if a Request
	timed out.

6.2 Network Organization and Maintenance Messages

[0263] These messages are used to communicate between any of the elements of the network, between the source and destination of a data flow, two neighboring network elements, or between a router and its selected QoS Manager. This type of message is used to organize the network into domains, and maintain network performance.

6.2.1 Organization

[0264] This message is used when a router connects to the domain to pass state information between a Host and its neighbors. The host sends this message to its neighbors whenever it has a change in state.

[0265]

Message Type	This is the message type as defined in Table 4.
Domain Hop Count	The number of hops from the router sending the
	message to the QM acting as the domain origin.
QM Hop Count	The number of hops from the router sending the
	message to its QM.
Router Address/ID	The address or ID of the router that is sending the
	organization message.
Domain Origin	The address of the Domain Origin.
Address
Domain ID	The ID of the domain on the other end of the link.

6.2.2 Congestion Report and Clear

[0266] The congestion report and clear messages are sent from the routers to the QoS Manager. When a router becomes congested, it will generate a report, which will allow the QM to throttle back the amount of traffic being injected into the domain. Both of these messages use the same message format, shown in FIG. 25, and each is sent a single time. The congestion message is sent once every time that the traffic on the link exceeds the congestion threshold on a queue, and the congestion clear message is sent once when all the queues are below the clear threshold. Note that even though the same message format is used, there are different message types for the report and clear messages.

[0267]

Message Type	This is the message type as defined in Table 4.
Number of	This field contains the number of reports from this router
Reports	being delivered to the QM
Router Address	The address of the reporting router.
Link ID	The ID of the link, which, when combined with the
	router address, uniquely identifies the congested/
	uncongested link.

6.2.3 External Link Registration

[0268] The external link registration (ELR) message is sent from the router to the QM to inform the QM of its existence and bandwidth capabilities.

[0269]

Message Type	This is the message type as defined in Table 4.
Number of	The number of External Link Registrations being
Reports	reported in this update.
Domain ID	The ID of the domain on the other end of the link.
Router Address	The address of the router that registered the external
	link.
Link ID	The ID of the link, which, when combined with the
	router address, uniquely identifies the external link.
Link Bandwidth	The Bandwidth of the external link.

6.2.4 Domain Origin Check

[0270] This message is sent from a router to the Domain Origin when the origin is suspected of having moved from the domain. The origin responds to this message with an ACK only if it is still acting as the domain origin for this domain.

[0271]

Message Type	This is the message type as defined in Table 4.
Domain Origin	The address of the Domain Origin.
Address
Domain ID	The ID of the domain on the other end of the link.

6.3 Inter-QM Protocol Messages

[0272] These messages are exchanged between the QMs in the domain to share information needed on a domain-wide basis. This includes congestion information, the list of existing QMs, the amount of allocated and reserved bandwidth for each QM, information about the peripheral domains and the links to them, and a message to notify other QMs that there has been a loss of a QM in the domain. There is also a set of Inter-QM Request-Grant messages, which includes a QM Request, QM Grant, QM Denial, and QM ACK, which are used to exchange bandwidth.

6.3.1 QM Update

[0273] This report updates the other QMs about information stored in its own condition table. This information also carries a timestamp, which is used to measure the reliability of the data when a QM is no longer reachable.

[0274]

Message Type	This is the message type as defined in Table 4.
Number of Congested	This is the total number of congested links that
Links	have been reported to this QM.
QM ID	The ID of the QoS Manager to which the follow-
	ing information refers.
Bandwidth Allocated	The amount of bandwidth currently allocated to
	that QM
Bandwidth Reserved	The amount of bandwidth the QM currently has
	reserved. This should be less than Bandwidth
	Allocated, although, if the TDB has just been
	decremented, it may not be.
Timestamp	This is a timestamp, of when the reporting QM
	last received data from the QM that is being
	reported. This timestamp is UNIX time, the time
	in seconds since Jan. 1, 1970.

6.3.2 QM Update Acknowledgement

[0275] This message is sent from one QoS Manager to another in acknowledgement of the QM Update. The ACK is similar to the beginning of the QM Update message, but changes the Message Type value and the QM ID.

[0276]

Message Type	This is the message type as defined in Table 4.
Number of Congested	This is the total number of congested links that
Links	have been reported to this QM (as shown in the
	Update message).
QM ID	The ID of the QM that generated the update_ack
	message.

6.3.3 QM Congestion

[0277] This message is sent from a QM that is experiencing congestion to the other QMs in the domain to notify the other QMs that they need to decrement their TDB allocation.

[0278]

Message Type	This is the message type as defined in Table 4.
Bandwidth	The amount of bandwidth currently allocated to this QM.
Allocated
QM ID	The ID of the QM that generated this QM Congestion
	message.

6.3.4 Peripheral Domain

[0279] This report is sent to the other QMs so that each QM has a complete set of data on the domains peripheral to the local domain. The information included regarding allocated and reserved bandwidth is the total amount of bandwidth per QoS level over all the known connections existing in the QM's external link table.

[0280]

Message Type	This is the message type as defined in Table 4.
Number of Reports	The number of Peripheral Domain reports included
	in this update message.
Domain ID	The ID of the Peripheral Domain.
Connections Per	The total number of connections to the Peripheral
Domain	Domain.
Allocated BW/QoS	The total amount of BW allocated to this QM at
	each QoS level.
Reserved BW/QoS	The total amount of BW reserved by this QM at
	each QoS level.

6.3.5 QM List

[0281] This message is used to inform other QMs about the list of known QMs within the domain that this QoS Manager is aware of.

[0282]

Message Type	This is the message type as defined in Table 4.
Number of	The number of QoS Managers included in this update
QMs	message.
QM ID	The ID of the QM.

6.3.6 Failed QM

[0283] This message is sent to the domain origin and then to all the QMs in the domain to inform them that a failed QM has been detected.

[0284]

	Message Type	This is the message type as defined in Table 4.
	Failed QM ID	The ID of the Failed QM.
	Source QM ID	The ID of the QM sending the message.

6.3.7 Failed ACK

[0285] The domain origin uses this message to respond to the first Failed QM message, in Section 6.36, to inform the source of the Failed QM message that it may take control of the allocated bandwidth of that QM. Note that any subsequent Failed QM messages with the same QM ID are not ACKed.

[0286]

	Message Type	This is the message type as defined in Table 4.
	Failed QM ID	The ID of the Failed QM.

6.3.8 QM Check

[0287] A QM sends this message when another QM in the same domain has possibly failed, or is no longer acting as a QM in this domain. If the QM is still active in the domain, the QM sends this message back to the source, with the Flags field set to 1.

[0288]

	Message Type	This is the message type as defined in Table 4.
	QM ID	The ID of the QM thought to have failed.
	Domain ID	The ID of the domain.

6.3.9 QM Request

[0289] This message is used by the QMs to request more bandwidth from each other. A QM may only request bandwidth from a QM that has more than 20% more allocated bandwidth than reserved.

[0290]

Message Type	This is the message type as defined in Table 4.
Bandwidth	The amount of bandwidth requested of the Destination
Requested	QM.
Source QM ID	The ID of the Requesting QM, the source of this
	message.
Destination QM	The ID of the QM the bandwidth is requested from,
ID	the destination of this message.

6.3.10 QM Grant

[0291] This is the message sent in response to a QM Request if the QM that received the QM Request is able to give that amount of bandwidth to another QM.

[0292]

Message Type	This is the message type as defined in Table 4.
Requested	The amount of bandwidth requested.
Bandwidth
Requesting QM ID	The ID of the Requesting QM.
Granting QM ID	The ID of the Granting QM.

6.3.11 QM Denial

[0293] This is the message sent in response to a QM Request if the QM that received the QM Request is not able to fill the request. This might occur if Granting the bandwidth would drop the unreserved bandwidth to below 10% more than the amount of reserved bandwidth.

[0294]

Message Type	This is the message type as defined in Table 4.
Requested	The amount of bandwidth requested.
Bandwidth
Requesting QM ID	The ID of the Requesting QM.
Denying QM ID	The ID of the Denying QM.

6.3.12 QM ACK

[0295] The Requesting QM sends this message in response to a QM Grant and a QM Denial. Using a three-way handshake ensures that portions of the TDB are not lost if a message is not completed.

[0296]

Message Type	This is the message type as defined in Table 4.
Requested	The amount of bandwidth requested.
Bandwidth
Requesting QM ID	The ID of the Requesting QM.

Appendix A Modifications for Subnetwork or Other Operation

[0297] There are two modifications that have been specified as modifications made to this mechanism to make it usable by subnetworks that need information other than the DS codepoint to successfully provide meaningful QoS to the data packets. Information such as the allotted bandwidth or flow identification can be included in the IP header using a specified option field, which is specified in RFC 791, and formatted as shown in FIG. 40.

A.1 QoS Bandwidth Option Field

[0298] This option allows the IP header of the data packets to include the amount of bandwidth the flow is allowed to use in the network. The information included in the Grant message of the DS/DQM mechanism would be used to format this option field in the data packets if necessary.

[0299] The Option Code byte contains three sub-fields. The first is the “copy bit” and is set to 1 to indicate that this field should be copied into each fragment of the packet if the packet needs to be fragmented. The second sub-field is the two bit “class” field and is set to 0 to indicate that this is used for a normal or control operation. The last sub-field contains the actual control code and is set by the IANA. At this time, the values 0-24 have been assigned, and so it will be assumed that if approved, this option would receive that value 25, which is the next available option code. Therefore, the Option Code field has a total value of 153, and looks as shown in FIG. 41.

[0300] The length field contains the total number of bytes of the option, including the option code and length fields. Hence, the value for this option is 4 bytes.

[0301] The Data field for this option is 16 bits long and will contain the bandwidth allotted for this data flow, with a granularity of Kb/s. Therefore, the range of bandwidth that this option is able to support is from 1 Kb/s to 64 Mb/s.

A.2 QoS Flow ID Option Field

[0302] This option allows the data packets to include assigned flow identification numbers in the IP header. However, this option has not been fully developed.

[0303] Networks that support the use of IntServ to provide QoS would use this option, since per flow information needs to be maintained across the IntServ network. If encryption is used in the network, the port addresses are encrypted also, and the routers are not able to properly route the packets according to the reserved path. Therefore, the flow ID option field can be used to store the port numbers or a flow ID in the IP header, so that each router can relate the data packet to its appropriate reserved path.

[0304] Throughout this description, reference is made to mobile networks and to an IP network, because it is believed that the beneficial aspects of the present invention would be most readily apparent when used in connection with mobile IP networks; however, it should be understood that the present invention is not intended to be limited to mobile IP networks and should be hereby construed to include other non-mobile and non-IP networks as well.

[0305] It is thought that the method and apparatus of the present invention will be understood from the foregoing description and that it will be apparent that various changes may be made in the form, construct steps, and arrangement of the parts and steps thereof, without departing from the spirit and scope of the invention or sacrificing all of their material advantages. The form herein described is merely a preferred exemplary embodiment thereof.