In response to the growing demand for an Integrated Services Internet, the Internet
Engineering Task Force (IETF)[#!ietf!#] set up an Integrated Services (intserv) Working
Group[#!intserv!#][#!intservch!#] which has since defined several service classes that if supported by the
routers traversed by a data flow
can provide the data flow with certain QOS
commitments. By contrast best-effort traffic entering a router will receive no such
service commitment and will have to make do with whatever resources are available.
The level of QOS provided by these enhanced QOS classes is programmable on a per-
flow basis according to requests from the end applications. These requests can be
passed to the routers by network management procedures or, more commonly, using a
reservation protocol such as RSVP which is described in section 2.5. The requests
dictate the level of resources(e.g. bandwidth, buffer space) that must be reserved
along with the transmission scheduling behaviour that must be installed in the routers
to provide the desired end-to-end QOS commitment for the data flow.
A data flow identifies the set of packets to receive special QOS. It
is defined by a ``Session'' identified by a generalized port
specification, as in 2.5,
comprising the IP address, transport layer protocol type and port
number of the destination along with
a list of specific senders to that Session that are entitled to
receive the special QOS. Each sender is
identified by source address, and port number while it's protocol
type must be the same as for the Session. We outlined the notion of an
IP address for unicast and multicast in chapter one.
|
In determining the resource allocations necessary to satisfy a request, the router needs to take account of the QOS support provided by the link layer in the data forwarding path. Furthermore, in the case of a QOS-active link layer such as ATM or certain types of LAN the router is responsible for negotiations with the link layer to ensure that the link layer installs appropriate QOS support should the request be accepted. This mapping to link-layer QOS is medium-dependent and the mechanisms for doing so are currently being defined by the Integrated Services over Specific Lower Layers (issll) Working Group of the IETF[#!issl!#] In the case of a QOS-passive link-layer such as a leased-line the mapping to the link-layer QOS is trivial since transmission capacity is handled entirely by the router’'s packet scheduler.
Each router must apply admission control to requests to ensure that they are only accepted if sufficient local resources are available. In making this check, admission control must consider information supplied by end applications regarding the traffic envelope that their data flow will fall within. One of the parameters in the traffic envelope that must be supplied is the maximum datagram size of the data flow, and should this be greater than the MTU of the link then admission control will reject the request since the Integrated Services models rely on the assumption that datagrams receiving an enhanced QOS class are never fragmented. Think of the packet arrival process as having a pattern like a waveform. The envelope is its typical shape.
Once an appropriate reservation has been installed in each router along the path, the data flow can expect to receive an end-to-end QOS commitment provided no path changes or router failures occur during the lifetime of the flow, and provided the data flow conforms to the traffic envelope supplied in the request. Due to refresh timers used by RSVP, a flow may recover its QoS commitment with out taking any special action. With the advent of QoS aware routing, it may be that there is not even a gap in the perceived provision of the service contract.
Service-specific policing and traffic reshaping actions as described in sections 2.8.1 and 2.8.2 will be employed within the network to ensure that non-conforming data flows do not affect the QOS commitments for behaving data flows. The IETF has considered various QOS classes such as [#!commit!#][#!pbe!#][#!guaranteed!#][#!controlled!#] although to date only two of these, Guaranteed Service[#!guaranteed!#] and Controlled-Load Service[#!controlled!#], have been formally specified for use with RSVP[#!rsvpandintserv!#]. First, we will look at the simpler of these services, namely Controlled Load.