Note
Access to this page requires authorization. You can try signing in or changing directories.
Access to this page requires authorization. You can try changing directories.
Managing and controlling the utilization of network bandwidth is important for an enterprise to reduce cost and to ensure quality of service for applications using network resources. Media communication traffic has the potential to over-use the available bandwidth on network links unless the utilization is closely monitored and bandwidth policy restrictions are actively enforced. Even if the bandwidth utilization is known, enforcing the bandwidth policy can be difficult because the clients involved in the media session could be dispersed across the enterprise and can be in different geographical or network regions.
This protocol is a proprietary extension to the Traversal Using Relay NAT (TURN) protocol, as described in [MS-TURN], which provides support for controlling access to network bandwidth. This extension uses the optional attribute space of the Simple Traversal of UDP through NAT (STUN) protocol to define new attributes that a TURN client can use to check for the availability of, and reserve, network bandwidth to be used for the transport of its media streams.
A typical deployment supported by this extension where a client is communicating with a peer over a bandwidth managed network link is shown in the following diagram.
Figure 1: Client communicating with peer
The preceding diagram shows two clients in two different network sites where a network site is made up of a collection of Internet Protocol version 4 (IPv4) subnets. Network Site1 might be a corporation’s home office while Network Site2 is a regional branch office. Network Site2 connects back to the home office over a WAN Link which has limited bandwidth capacity. These network sites and WAN Link make up the bandwidth admission control network topology.
The TURN client named Client1 in Network Site1 is attempting to communicate with the TURN client named Client2 in Network Site2. Client1 allocates a public transport address from its TURN server. It then uses a signaling protocol, such as the Session Initiation Protocol (SIP), to communicate its local transport address and relay allocated transport address, which is the transport address allocated by the TURN server, to Client2.
When Client2 receives Client1’s media transport addresses, it attempts to allocate a public transport address from its TURN server. As part of the allocation attempt, Client2 checks for bandwidth availability across the WAN link. To check for bandwidth availability, Client2 includes the following attributes in its Allocate Request message, as described in [MS-TURN]:
A Bandwidth Admission Control Message attribute, as specified in section 2.2.1, with a value of "Reservation Check".
A Bandwidth Reservation Amount attribute, as specified in section 2.2.3, with values that cover the bandwidth range required for the media stream.
A Remote Site Address attribute, as specified in section 2.2.4, containing the transport address of Client1.
A Remote Relay Site Address attribute, as specified in section 2.2.5, containing the transport address allocated by Client1’s TURN server.
A Local Site Address attribute, as specified in section 2.2.6, containing the local transport address of Client2.
A MS-Service Quality attribute, as specified in [MS-TURN] section 2.2.2.22, containing the type and service quality of the media stream.
The TURN server implementing these extensions uses the transport addresses from the Reservation Check, along with the transport address that it allocates on behalf of Client2, to identify the network location of the two clients and their respective TURN servers in the bandwidth admission control network topology. Once it has the network locations of the clients and the TURN servers, it identifies the following network paths; Client1 to Client1 TURN server, Client2 to Client2 TURN server, Client1 to Client2. The server checks the policy and available bandwidth for each of these network paths to see if the Reservation Check can be satisfied.
When the server finishes checking the network paths, it responds to Client2 with an Allocate Response message, as described in [MS-TURN], that includes the following attributes:
A Bandwidth Admission Control Message attribute, as specified in section 2.2.1, with a value of "Reservation Check".
A Remote Site Address Response attribute, as specified in section 2.2.8, containing flags indicating the results of the bandwidth policy check along with the bandwidth range available to be used by the transport address that was included in the Remote Site Address attribute, as specified in section 2.2.4, of the Reservation Check request.
A Remote Relay Site Address Response attribute, as specified in section 2.2.9, containing flags indicating the results of the bandwidth policy check along with the maximum bandwidth available to be used by the transport address that was included in the Remote Relay Site Address attribute, as specified in section 2.2.5, of the Reservation Check request.
A Local Site Address Response attribute, as specified in section 2.2.10, containing flags indicating the results of the bandwidth policy check along with the maximum bandwidth available to be used by the transport address that was included in the Local Site Address attribute, as specified in section 2.2.6, of the Reservation Check request.
A Local Relay Site Address Response attribute, as specified in section 2.2.11, containing flags indicating the results of the bandwidth policy check along with the maximum bandwidth available to be used by the transport address that was allocated by the TURN server as a result of the Allocate Request message.
Client2 can now use any of the transport addresses that were marked as valid by the server to run connectivity checks to Client1. If none of the transport addresses were marked valid, Client2 fails the connection attempt for lack of network bandwidth resources. When Client2 finishes connectivity checks, it notifies the server of the transport addresses it is using for the media stream. Client2 does this notification by including the following attributes in another Allocate Request message:
A Bandwidth Admission Control Message attribute, as specified in section 2.2.1, with a value of "Reservation Commit".
A Bandwidth Reservation Amount attribute, as specified in section 2.2.3, with values that identify the bandwidth to be used for the media stream.
A Remote Site Address attribute, as specified in section 2.2.4, containing the transport address of Client1.
If Client1 is using the transport address allocated by its TURN server, a Remote Relay Site Address attribute, as specified in section 2.2.5, is included with the public transport address allocated by Client1’s TURN server.
A Local Site Address attribute, as specified in section 2.2.6, containing the transport address of Client2.
If Client2 is using the transport address allocated by its TURN server, a Local Relay Site Address attribute, as specified in section 2.2.7, is included with the public transport address allocated by Client2’s TURN server.
When the server receives the Reservation Commit message from Client2, it uses the site address attributes included in the message to locate the network sites used by clients. Once it has the network locations of the clients, it identifies the network paths that will be used for this reservation and commits the bandwidth amount of the reservation against the network paths. This reduces the amount of bandwidth that is available for future calls over these network paths. After completing the bandwidth reservation, the server replies to the client letting it know that the bandwidth has been reserved for the media stream. It sends this reply in an Allocate Response message and includes the following attributes:
A Bandwidth Admission Control Message attribute, as specified in section 2.2.1, with a value of "Reservation Commit".
A Bandwidth Reservation Identifier attribute, as specified in section 2.2.2, with a value that identifies the reservation with the server (2). This identifier is used in all subsequent update/change, cancellation, and bandwidth update messages dealing with the reservation.
After Client2 has committed a bandwidth reservation with the server, it can attempt to increase or decrease the amount of bandwidth it has reserved for the media stream by sending a reservation update request to the server. The client notifies the server of this update request by sending another authenticated Allocate Request message:
A Bandwidth Admission Control Message attribute, as specified in section 2.2.1, with a value of "Reservation Update".
A Bandwidth Reservation Identifier attribute, as specified in section 2.2.2, with the reservation id value returned by the server in response to the Reservation Commit message.
A Bandwidth Reservation Amount attribute, as specified in section 2.2.3, with values that identify the bandwidth to be used for the media stream.
When the server receives the Reservation Update message from Client2, it uses the reservation id to identify the existing bandwidth reservation and the network paths involved in the reservation. The server can update the reservation with the new values requested by the client, increasing or decreasing the bandwidth as requested. After completing the bandwidth reservation update, the server replies to the client letting it know the amount of bandwidth that has been reserved for the media stream. It sends this reply in an Allocate Response message and includes the following attributes:
A Bandwidth Admission Control Message attribute, as specified in section 2.2.1, with a value of "Reservation Update".
A Bandwidth Reservation Identifier attribute, as specified in section 2.2.2, with a value that identifies the reservation with the server (2).
A Bandwidth Reservation Amount attribute, as specified in section 2.2.3, with values that identify the bandwidth that is reserved for the media stream.
The basic message flow for a scenario that uses SIP for signaling is shown in the following diagram.
Figure 2: SIP signaling message flow