139 lines
11 KiB
HTML
139 lines
11 KiB
HTML
|
<?xml version="1.0" encoding="UTF-8"?>
|
||
|
|
<!DOCTYPE html
|
||
|
|
PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
|
||
|
|
<html lang="en-us" xml:lang="en-us">
|
||
|
|
<head>
|
||
|
|
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
|
||
|
|
<meta name="security" content="public" />
|
||
|
|
<meta name="Robots" content="index,follow" />
|
||
|
|
<meta http-equiv="PICS-Label" content='(PICS-1.1 "http://www.icra.org/ratingsv02.html" l gen true r (cz 1 lz 1 nz 1 oz 1 vz 1) "http://www.rsac.org/ratingsv01.html" l gen true r (n 0 s 0 v 0 l 0) "http://www.classify.org/safesurf/" l gen true r (SS~~000 1))' />
|
||
|
|
<meta name="DC.Type" content="concept" />
|
||
|
|
<meta name="DC.Title" content="Integrated service" />
|
||
|
|
<meta name="abstract" content="The second type of outbound bandwidth policy you can create is an integrated service policy. Integrated service provides the capability for IP applications to request and reserve bandwidth using the ReSerVation Protocol (RSVP) and quality of service (QoS) APIs." />
|
||
|
|
<meta name="description" content="The second type of outbound bandwidth policy you can create is an integrated service policy. Integrated service provides the capability for IP applications to request and reserve bandwidth using the ReSerVation Protocol (RSVP) and quality of service (QoS) APIs." />
|
||
|
|
<meta name="DC.Relation" scheme="URI" content="rzak8what_is.htm" />
|
||
|
|
<meta name="DC.Relation" scheme="URI" content="rzak8traffic_control.htm" />
|
||
|
|
<meta name="DC.Relation" scheme="URI" content="rzak8servicetype.htm" />
|
||
|
|
<meta name="DC.Relation" scheme="URI" content="rzak8outboundlimits.htm" />
|
||
|
|
<meta name="DC.Relation" scheme="URI" content="rzak8markings.htm" />
|
||
|
|
<meta name="DC.Relation" scheme="URI" content="rzak8rsvp.htm" />
|
||
|
|
<meta name="DC.Relation" scheme="URI" content="rzak8markings.htm" />
|
||
|
|
<meta name="DC.Relation" scheme="URI" content="rzak8example_3.htm" />
|
||
|
|
<meta name="DC.Relation" scheme="URI" content="rzak8example_2.htm" />
|
||
|
|
<meta name="copyright" content="(C) Copyright IBM Corporation 1998, 2006" />
|
||
|
|
<meta name="DC.Rights.Owner" content="(C) Copyright IBM Corporation 1998, 2006" />
|
||
|
|
<meta name="DC.Format" content="XHTML" />
|
||
|
|
<meta name="DC.Identifier" content="rzak8intserv" />
|
||
|
|
<meta name="DC.Language" content="en-us" />
|
||
|
|
<!-- All rights reserved. Licensed Materials Property of IBM -->
|
||
|
|
<!-- US Government Users Restricted Rights -->
|
||
|
|
<!-- Use, duplication or disclosure restricted by -->
|
||
|
|
<!-- GSA ADP Schedule Contract with IBM Corp. -->
|
||
|
|
<link rel="stylesheet" type="text/css" href="./ibmdita.css" />
|
||
|
|
<link rel="stylesheet" type="text/css" href="./ic.css" />
|
||
|
|
<title>Integrated service</title>
|
||
|
|
</head>
|
||
|
|
<body id="rzak8intserv"><a name="rzak8intserv"><!-- --></a>
|
||
|
|
<!-- Java sync-link --><script language="Javascript" src="../rzahg/synch.js" type="text/javascript"></script>
|
||
|
|
<h1 class="topictitle1">Integrated service</h1>
|
||
|
|
<div><p>The second type of outbound bandwidth policy you can create is
|
||
|
|
an integrated service policy. Integrated service provides the capability for
|
||
|
|
IP applications to request and reserve bandwidth using the ReSerVation Protocol
|
||
|
|
(RSVP) and quality of service (QoS) APIs. </p>
|
||
|
|
<p>Integrated service policies use the RSVP protocol and the Resource Reservation
|
||
|
|
Setup Protocol (RAPI) API (or qtoq socket API) to guarantee an end-to-end
|
||
|
|
connection. This is the highest level of service you can designate; however,
|
||
|
|
it is also the most complex.</p>
|
||
|
|
<p>Integrated service deals with traffic delivery time and assigning particular
|
||
|
|
traffic special handling instructions. It is important to be conservative
|
||
|
|
with your integrated service policies because it is still relatively expensive
|
||
|
|
to guarantee data transfer. However, over provisioning your resources can
|
||
|
|
be even more expensive.</p>
|
||
|
|
<p>Integrated service reserves resources for a particular policy before the
|
||
|
|
data is sent. The routers are signaled before data transfer and the network
|
||
|
|
actually agrees to and manages (end-to-end) data transfer based on a policy.
|
||
|
|
A <dfn class="term">policy</dfn> is a set of rules that designate an action. It is basically
|
||
|
|
an admission control list. The bandwidth request comes in a reservation from
|
||
|
|
the client. If all the routers in the path agree to the requirements coming
|
||
|
|
from the requesting client, the request gets to the server and IntServ policy.
|
||
|
|
If the request falls within the limits defined by the policy, the QoS server
|
||
|
|
grants permission for the RSVP connection and will then set aside the bandwidth
|
||
|
|
for the application. The reservation is performed using the RSVP protocol
|
||
|
|
and RAPI API, or the RSVP protocol and qtoq QoS sockets APIs.</p>
|
||
|
|
<p>Every node that your traffic travels through must have the ability to use
|
||
|
|
the RSVP protocol. The routers provide QoS through the following traffic control
|
||
|
|
functions: packet scheduler, packet classifier, and admission control. The
|
||
|
|
ability to carry out this traffic control is often referred to as RSVP-enabled.
|
||
|
|
As a result, the most important part of implementing integrated services policies
|
||
|
|
is being able to control and predict the resources in your network. To get
|
||
|
|
predictable results, every node in the network must be RSVP-enabled. For example,
|
||
|
|
your traffic is routed based on resources, not on which paths have RSVP-enabled
|
||
|
|
routers. Crossing routers that are not RSVP-enabled might cause unpredictable
|
||
|
|
performance problems. The connection is still made, but the performance that
|
||
|
|
the application requests is not guaranteed by that router. The following figure
|
||
|
|
shows how the integrated service function logically works.</p>
|
||
|
|
<div class="fignone"><span class="figcap">Figure 1. RSVP path between client and server</span><br /><img src="Rzak8505.gif" alt="Shows your server sending traffic through routers along a pathway to the client." /><br /></div>
|
||
|
|
<p>The RSVP-enabled application on the server detects a connection request
|
||
|
|
from the client. In response, the server's application issues a PATH command
|
||
|
|
to the client. This command is issued using the RAPI APIs or qtoq QoS sockets
|
||
|
|
APIs and contains router IP address information. A PATH command contains information
|
||
|
|
about the available resources on the server and the routers along the path
|
||
|
|
as well as route information between the server and the client. The RSVP-enabled
|
||
|
|
application on the client then sends a RESV command back along the network
|
||
|
|
path to signal the server that the network resources have been allocated.
|
||
|
|
This command makes the reservation, based on the router information from the
|
||
|
|
PATH command. The server and all routers along the path reserve the resources
|
||
|
|
for the RSVP connection. When the server receives the RESV command, the application
|
||
|
|
starts transmitting data to the client. The data is transmitted along the
|
||
|
|
same route as the reservation. Again, this shows how important the routers'
|
||
|
|
abilities to carry out this reservation are to the success of your policies.</p>
|
||
|
|
<p>Integrated service is not meant for short term RSVP connections, like HTTP.
|
||
|
|
Of course this is at your discretion. Only you can decide what is best for
|
||
|
|
your network. Consider what areas and applications are having performance
|
||
|
|
problems and need QoS. Applications used in an integrated service
|
||
|
|
policy must be able to use the RSVP protocol. Currently, your server does
|
||
|
|
not have any RSVP-enabled applications, so you will need to write the application
|
||
|
|
to use RSVP.</p>
|
||
|
|
<p>As packets arrive and attempt to leave your network, your server determines
|
||
|
|
whether it has the resources to send the packet. This acceptance is determined
|
||
|
|
by the amount of space in the token bucket. You manually set the number of
|
||
|
|
bits to allow into your token bucket, any bandwidth limits, token rate limits,
|
||
|
|
and the maximum number of connections your server allows. These values are
|
||
|
|
referred to as performance limits. If the packets remain within the server's
|
||
|
|
limits, the packets conform and are sent out. In integrated services, each
|
||
|
|
connection is granted its own token bucket.</p>
|
||
|
|
<div class="section"><h4 class="sectiontitle">Integrated service using differentiated service markings</h4><p>If
|
||
|
|
you are unsure that the entire network can guaranteed an RSVP connection,
|
||
|
|
you can still create an integrated service policy. However, if the network
|
||
|
|
resources cannot use RSVP, the connection cannot be guaranteed. In this situation,
|
||
|
|
you might want to apply a codepoint to the policy. This codepoint is typically
|
||
|
|
used in differentiated service policies to give a class of service to traffic.
|
||
|
|
Even if the connection is not guaranteed, this codepoint will attempt to give
|
||
|
|
the connection some priority.</p>
|
||
|
|
</div>
|
||
|
|
</div>
|
||
|
|
<div>
|
||
|
|
<ul class="ullinks">
|
||
|
|
<li class="ulchildlink"><strong><a href="rzak8traffic_control.htm">Traffic control functions</a></strong><br />
|
||
|
|
Traffic control functions only apply to integrated service and
|
||
|
|
are not specific to iSeries™.</li>
|
||
|
|
<li class="ulchildlink"><strong><a href="rzak8servicetype.htm">Integrated service types</a></strong><br />
|
||
|
|
There are two integrated service types: controlled load and guaranteed.</li>
|
||
|
|
<li class="ulchildlink"><strong><a href="rzak8outboundlimits.htm">Token bucket and bandwidth limits</a></strong><br />
|
||
|
|
Token bucket limits and bandwidth limits are together known as performance limits. These performance limits help guarantee packet delivery in outbound bandwidth policies, both integrated and differentiated service.</li>
|
||
|
|
<li class="ulchildlink"><strong><a href="rzak8markings.htm">Integrated service using differentiated service markings</a></strong><br />
|
||
|
|
Use differentiated service markings in an integrated service policy to maintain priority of packets sent in a mixed environment.</li>
|
||
|
|
</ul>
|
||
|
|
|
||
|
|
<div class="familylinks">
|
||
|
|
<div class="parentlink"><strong>Parent topic:</strong> <a href="rzak8what_is.htm" title="If you are new to quality of service (QoS), you can read some basic QoS concepts. This will give you an overview of how QoS works and how QoS functions work together.">Concepts</a></div>
|
||
|
|
</div>
|
||
|
|
<div class="relconcepts"><strong>Related concepts</strong><br />
|
||
|
|
<div><a href="rzak8rsvp.htm" title="You can read this topic to learn about protocols, APIs, and requirements for a router that is enabled for the ReSerVation Protocol (RSVP). The current quality of service (QoS) APIs include the RAPI API, the qtoq socket API, the sendmsg() API, and the monitor APIs.">QoS APIs</a></div>
|
||
|
|
<div><a href="rzak8markings.htm" title="Use differentiated service markings in an integrated service policy to maintain priority of packets sent in a mixed environment.">Integrated service using differentiated service markings</a></div>
|
||
|
|
<div><a href="rzak8example_3.htm" title="If you need predictable delivery and still need to request a reservation, you also use an integrated service policy. This example uses a controlled load service.">Scenario: Predictable B2B traffic</a></div>
|
||
|
|
<div><a href="rzak8example_2.htm" title="If you need dedicated delivery and want to request a reservation, you use an integrated service policy. There are two types of integrated service policies to create: Guaranteed and controlled load. In this example, guaranteed service is used.">Scenario: Dedicated delivery (IP telephony)</a></div>
|
||
|
|
</div>
|
||
|
|
</div>
|
||
|
|
</body>
|
||
|
|
</html>
|