Triggering bandwidth reservation and priority remarking

In one embodiment, a reservation proxy monitors for received connectivity check messages or beginning-of-media-flow indication messages. When either type of message is observed, the reservation proxy requests resource allocation for a media flow associated with the received message. The amount of resource allocation requested may be coordinated by exchanging messages with a call controller or policy server for one of the endpoints of the media flow, or the amount of resource allocation may be identified within the received message.

TECHNICAL FIELD

The present disclosure relates generally to the field of networking.

BACKGROUND

An endpoint transferring media can reserve network resources for the media flow by sending a Resource ReSerVation (RSVP) protocol request. The endpoint typically sends a resource request in conjunction with establishing the media flow.

The RSVP protocol is not available on many endpoints, and accordingly, RSVP proxies located remotely from the endpoints have been used to send RSVP requests on behalf of endpoints. The RSVP proxies determine when RSVP requests should be initiated on behalf of an associated endpoint using methods such as stateful packet analysis. Under stateful packet analysis, the RSVP proxy analyzes packets for all media flows extending through itself. Whenever the RSVP proxy detects a new media flow, the RSVP proxy observes the flow type. The RSVP proxy then uses the flow type observation to heuristically determine resource requirements for the new flow and sends an RSVP request using the determined requirements. To ensure that resources are reserved for the lifetime of the flow, the RSVP proxies maintain state tables denoting previously analyzed flows.

The heuristically determined bandwidth requirements are frequently inaccurate and maintenance of the state tables by the RSVP proxies consumes local resources. The disclosure that follows solves these and other problems.

DESCRIPTION OF EXAMPLE EMBODIMENTS

Overview

In one embodiment, a reservation proxy monitors for received connectivity check messages or other beginning-of-media-flow indication messages. When either type of message is observed, the reservation proxy requests resource allocation for a media flow associated with the received message. The amount of resource allocation requested may be coordinated by exchanging messages with a call controller or policy server for one of the endpoints of the media flow, or the amount of resource allocation may be identified within the received message.

Description

Several preferred examples of the present application will now be described with reference to the accompanying drawings. Various other examples of the invention are also possible and practical. This application may be exemplified in many different forms and should not be construed as being limited to the examples set forth herein.

The figures listed above illustrate preferred examples of the application and the operation of such examples. In the figures, the size of the boxes is not intended to represent the size of the various physical components. Where the same element appears in multiple figures, the same reference numeral is used to denote the element in all of the figures where it appears. When two elements operate differently, different reference numerals are used regardless of whether the two elements are the same class of network device.

Only those parts of the various units are shown and described which are necessary to convey an understanding of the examples to those skilled in the art. Those parts and elements not shown are conventional and known in the art.

FIG. 1illustrates an example RSVP proxy for triggering RSVP requests in response to STUN messages.

Referring toFIG. 1, computers A and B use Interactive Connectivity Establishment (ICE) or a similar protocol so that a media path15can be established between them. During the initial stages of ICE, call controllers (not shown) for each of computers A and B exchange signaling messages. During a later stage of ICE, as part of a connectivity check, computer B generates a STUN request message11addressed to STUN server30located on computer A. STUN is a protocol used for Network Address Translator (NAT) discovery and for NAT binding verifications, which has also been leveraged to facilitate connectivity checks during ICE.

The RSVP proxy1that is located between computers A and B receives traffic exchanged between those endpoints. According to resource reservation software5, the RSVP proxy1monitors received traffic to determine whether the received traffic includes a STUN request or other messages sent using a network address translator discovery protocol. The RSVP proxy1may use any method to identify STUN requests, such as looking for a STUN magic cookie. Although in the present example the proxy1is an RSVP type, in other examples a Next Steps In Signaling (NSIS) device or any other reservation proxy may be used.

The STUN request11is received and the RSVP proxy1identifies the STUN request11B included within. The RSVP proxy1also examines an attached IP header11A to determine whether the STUN request11B is a peer-to-peer connectivity check type or another type such as a NAT binding verification.

Any method of distinguishing peer-to-peer connectivity check type STUN messages from other types may be used. In the present example, the RSVP proxy1observes the destination address X included in the IP header11A, which is compared to a local table or database. When the comparison identifies that the destination address does not correspond to a public STUN server used for binding verification, the RSVP proxy1concludes that the STUN request11B is sent to a peer that is configured to receive media, such as voice or video. Other methods of distinguishing the STUN request type may be used, such as filtering out STUN requests addressed to UDP port 3478, which is typically used for NAT binding verifications. When destination addresses for received STUN requests correspond to a network device that is not configured to receive media, such as a public STUN server, the STUN requests are forwarded without sending a reservation request.

Another embodiment uses STUN Indication messages, which are sent from computer B to computer A and do not elicit a STUN response. These STUN Indication messages contain the same bandwidth information, but are not part of an ICE exchange and do not elicit a connectivity check. The embodiment using STUN Indications is illustrated inFIG. 6.

Referring again toFIG. 1, when the STUN request11B is a peer-to-peer connectivity check type, the RSVP proxy1checks the STUN request11B for a bandwidth request attribute11C. When computer B or a call controller for computer B caused the bandwidth request attribute11C to be inserted into the STUN request11B, the RSVP proxy1is able to determine an amount of bandwidth associated with the call. In other words, the resource amount is determined without requiring heuristical determination by the RSVP proxy1. In other examples, the STUN request11B does not include the attribute11C and the RSVP proxy1uses any method of heuristically determining a required amount of bandwidth for the call, including heuristical determination based on call type.

The RSVP request12or another similar resource request may be sent to another RSVP proxy (not shown). In such a case, network resources are requested to be reserved by network devices such as routers located between the RSVP proxy1and the other RSVP proxy (not shown). Alternatively, the RSVP request12may instead be sent to computer A if computer A is configured with RSVP or similar protocol. In that case, network resources are requested to be reserved between the RSVP proxy1and the computer A.

The RSVP proxy1also attaches a notification attribute11D to the STUN request11A before forwarding the STUN request message11. The notification attribute is added at the end of the STUN request message11, outside an integrity-check protected portion. The notification attribute11D notifies any other proxies located between the RSVP proxy1and the computer A that the STUN request message11has already triggered a resource reservation request. In other words, this attribute11D may be used to prevent multiple resource reservations to be requested for a same media flow.

The RSVP proxy1may receive back a STUN response13before receiving back the RSVP response14, depending on network congestion and other factors. When the STUN response13is received first, the RSVP proxy1may optionally store the STUN response13in a local memory6until determining whether resources are reserved.

Delayed forwarding of the STUN response13until receiving the RSVP response14is advantageous particularly in the instance when resources are not available for the RSVP request12. In such a case, the RSVP proxy1determines that no resources are available and then drops the STUN response13without forwarding. As a result, computer B does not complete the peer-to-peer connectivity check, which disrupts the ICE exchange and prevents the media flow15from being established between the computers A and B. Preventing the media flow15when the network is too congested is helpful as an overloaded network is prevented from becoming further overloaded and potentially dropping, or causing degradation of, already established connections.

When the RSVP response14indicates that resources are available, the RSVP proxy1forwards the STUN response13allowing the ICE process to complete between computers A and B. As a result, media path15is established between computers A and B. The media path15uses reserved resources, so that computers A and B are assured some minimum guaranteed level of Quality of Service (QoS).

FIG. 2illustrates an example of the RSVP proxy illustrated inFIG. 1for requesting resource requirements from a call controller.

Referring toFIG. 2, during ICE or a similar connectivity establishment protocol, username inclusion software15on computer A provides, to computer B, a username pattern21A that is associated with the call controller8. This username pattern21A may include an encoding of an IP address for the call controller8for computer A or some other value that allows RSVP proxy1to identify call controller8from other call controllers on the network. When ICE is the protocol used for connectivity establishment, the username pattern21A may be transferred within the signaling messages19that are exchanged during the initial stages of ICE. In other examples, the username pattern21A may be provided by software located on call controller8instead of computer A. Accordingly, when a STUN request21is generated by computer B, the username pattern21A is included within STUN request21.

The RSVP proxy1receives the STUN request21and may perform any of the processes previously described with respect toFIG. 1. Additionally, in this example the RSVP proxy1locates the username pattern21A. The RSVP proxy1decodes the username pattern21A to identify the IP address for call controller8. Using the decoded IP address (or any other value that allows identification of call controller8from other network devices located on the network), the RSVP proxy1sends request22. Request22solicits the call controller8to provide an amount of bandwidth needed to exchange media between the computers A and B.

Once the RSVP proxy1receives back a response23that identifies an amount of bandwidth required for the media exchange, an RSVP request24is generated. The RSVP request24requests resources sufficient to transfer the bandwidth amount indicated by response23.

After sending STUN request21and RSVP request24, the RSVP proxy1receives back STUN response25and RSVP response26in any order depending on network congestion. The STUN response25, which may be correlated to the STUN request21using a STUN transaction identifier, may be temporarily stored or immediately forwarded to computer B. Once computers A and B complete ICE, a media flow15is established using the reserved resources.

FIG. 3illustrates an example router for triggering priority remarking of media packets in response to STUN messages.

Referring toFIG. 3, a network device such as router30located between the computers A and B may also receive the STUN request21. The router30may receive the STUN request21before or after the RSVP proxy1described inFIGS. 1 and 2. The router30may be located on a call path that does not extend through the RSVP proxy or any other reservation device. In other words, priority remarking may be used on a call that does not use reserved resources and which does not elicit reservation attempts by proxies, endpoints or other devices. Although in this example, the priority adjustment software29is located on router30, in other examples the software29is located on any other network device that is capable of adjusting priority values included in media packets.

In response to receiving STUN request21, the router30determines a value to be used in a Differentiated Services Code Point (DSCP) field or other priority field for media packets in an associated media flow. In the present example, a request31is made using the username pattern21A to ask call controller8for the priority value. In other examples, any of the previously described methods may be used, including observing an indication of an attribute included in the STUN request21or using heuristical determination to identify an appropriate priority value. The router30receives back, in any order, a STUN response25and a response32identifying the DSCP value indication32A that is equal to N.

After receiving the STUN response25, a media flow15is established that extends through the router30. The media flow15includes various media packets such as IP packet34A. The IP packet34A includes an IP header34B having a DSCP value field34C that is equal to some value such as value M.

The router observes the value M included in the DSCP value field34C of the received IP packet34A. The observed value M is then compared to the value N specified by the call controller8. Accordingly, since there is a difference in this example, the router30formats the IP packet34A according to the indicated DSCP value N. The router30then forwards the formatted IP packet35A having IP header35B and a DSCP field35C set to value N.

The router30may perform this priority remarking on every media packet included in the media flow15. Accordingly, when a different router (not shown) located between router30and computer B receives the formatted media packets, the different router processes the media packets according to the priority value N. The remarking by router30thus may increase or decrease the priority of the media flow30to better match current network congestion.

Also, this renumbering allows the packets to travel through a network for computer A at a first priority, and then travel through a network for computer B at a second priority. This may be advantageous, for example, when the different networks serve different types of traffic. For example, when the network for computer A is a network that primarily exchanges traffic of a personal nature, the media flow may receive a relatively high priority while traversing the personal network. Then, when entering a network serving primarily business traffic, the media flow15may be remarked by the router30to a different priority that is relatively low for the business network.

FIG. 4illustrates an example method for using the RSVP proxy illustrated inFIGS. 1-2.

In block401, the proxy1determines whether a received address request includes a notification that another proxy reserved resources on behalf of an endpoint associated with the address request. When the notification is not included, in block402the proxy1determines whether the address request is addressed for a connectivity check or a binding verification. Address requests that are not addressed for a connectivity check are forwarded normally in block403A.

When the address request is addressed for a connectivity check, in block403B the proxy1determines resource requirements for a call flow associated with the address request using any method. Next, in block404the proxy1sends a resource reservation request based on the determined resource requirements. The proxy1also attaches a notification to the address request to prevent double reservation, and then forwards the address request in block405.

In block406, the proxy1receives back a response to the address request, which may be stored until a resource reservation response is received. The proxy1also receives back the resource reservation response in block407.

In block408, the proxy1determines whether the resources are reserved according to the resource reservation response. When the resources are not reserved, in block409A the proxy1drops the response to the address request. When the resources are reserved, in block409B the proxy1forwards the response to the address request.

FIG. 5illustrates an example method for using the router illustrated inFIG. 3.

In block501, the router30determines whether a received address request is addressed for a connectivity check or a binding verification. When the received address request is not addressed for a connectivity check, in block502A the router30forwards the address request normally.

When the received address request is addressed for a connectivity check, in block502B the router30determines priority requirements for a call flow associated with the address request using any method and also forwards the address request. In block503, the router30receives back a response to the address request. The router30forwards the response to the address request in block504.

In block505, the router30receives media packets for the call flow associated with the address request. The router30determines whether the media packets indicate the determined priority in block506. When the media packets do not indicate the determined priority, in block507A the router30formats the media packets using the determined priority value and then forwards the formatted packets. When the media packets do indicate the determined priority, in block507B the router30forwards the media packets without remarking the priority indication.

FIG. 6illustrates another example of the RSVP proxy illustrated inFIG. 1.

Referring toFIG. 6, computer B needs to establish communications with computers A and Z. To minimize network traffic and for other reasons, computer B is configured to use multicasting to establish the communications. Multicast communications are communications that are sent once, copied at an intermediary device, and then delivered to more than one endpoint (such as hundreds of endpoints or more). When multicasting is used, ICE and STUN requests and responses are not required and are generally omitted.

Since STUN requests are not available to trigger resource reservation in a multicast scenario, other types of beginning-of-media-flow indications may be used to trigger resource reservation or priority remarking. Generally, any type of message can be used as a beginning-of-media-flow indication. Types of messages that are usable as beginning-of-media-flow indications include STUN Indications, but can also include any other messages that are sent using a protocol typically known to both proxies and endpoints. In the present example, computer B is configured to multicast a STUN Indication91A to trigger resource reservation and/or priority remarking. A STUN request is retransmitted until a STUN response is received; while a STUN Indication has no corresponding response. This makes STUN Indications suitable for large multicast groups.

RSVP proxy1receives the communication91including the STUN Indication91A. The software5uses any method to determine an appropriate bandwidth value for an associated media flow, such as processing the bandwidth request attribute91B included within the communication91. The RSVP proxy1then sends one or more RSVP requests92used to reserve resources for media flows to the computers A and Z. The amount of resources requested in the RSVP request92is set according to the bandwidth request attribute91B.

The RSVP proxy1may also attach a notification attribute91C to the STUN Indication91A before copying and forwarding the STUN Indication91A to computers A and Z. In other examples, the RSVP proxy1instead forwards the STUN Indication91A to another intermediary device that then performs the multicast processing including copying and forwarding. The attribute91C may be used to prevent duplicate resource reservations.

Finally, computer B uses multicasting to establish a media path109. The multicast media path109includes media path legs109A and109Z, which are established over the reserved resources.

FIG. 7illustrates an example method of using the RSVP proxy illustrated inFIG. 6.

In block701, the proxy1determines whether a received beginning-of-media-flow indication includes a notification that another proxy reserved resources on behalf of an endpoint associated with the indication. When the notification is not included, in block702the proxy1determines resource requirements for a call flow associated with the received indication using any method. Next, in block703the proxy1sends one or more resource reservation requests based on the determined resource requirements. The proxy1also attaches a notification to the received indication to prevent double reservation, and then forwards the indication in block704.

In block705, the proxy1may receive back one or more responses to the resource requests. In block706, the proxy1processes a multicast media flow that uses the reserved resources.

The above examples are described with respect to computers establishing a call. In other examples, the methods described above may be used to reserve resources for calls between any other endpoints such as a personal computer, an IP phone, a Personal Digital Assistant (PDA), a cell phone, a smart phone, a Publicly Switched Telephone Network (PSTN) gateway, etc.

Several preferred examples have been described above with reference to the accompanying drawings. Various other examples of the invention are also possible and practical. The system may be exemplified in many different forms and should not be construed as being limited to the examples set forth above.

The figures listed above illustrate preferred examples of the application and the operation of such examples. In the figures, the size of the boxes is not intended to represent the size of the various physical components. Where the same element appears in multiple figures, the same reference numeral is used to denote the element in all of the figures where it appears.

Only those parts of the various units are shown and described which are necessary to convey an understanding of the examples to those skilled in the art. Those parts and elements not shown are conventional and known in the art.

The system described above can use dedicated processor systems, micro controllers, programmable logic devices, or microprocessors that perform some or all of the operations. Some of the operations described above may be implemented in software and other operations may be implemented in hardware.

Having described and illustrated the principles of the invention in a preferred embodiment thereof, it should be apparent that the invention may be modified in arrangement and detail without departing from such principles. I claim all modifications and variation coming within the spirit and scope of the following claims.