Reporting Capabilities Reporting Capabilities

4.3.4 Reporting Capabilities Reporting Capabilities

To ensure that Integrated Services functions correctly, it is useful for end nodes to be able to collect information about the capabilities and available resources on the path between them. What bandwidth is available? What is the maximum MTU size supported? What IntServ capabilities are supported?

In RSVP, this information is built up in an Adspec object (shown in Figure 4.6), which is initiated by the data sender and updated by each RSVP-capable node along the path. The Adspec object is srcinally built to contain the global param- eters (type 1). Then, if the sender supports the guaranteed service, there is a set of service parameters of type 2. Finally, if the sender supports the controlled load service there is a set of service parameters of type 5. The IntServ length encom- passes the full sequence of service parameters.

As the object progresses through the network, the reported parameters are updated, giving the composed parameters for the path. This serves to reduce the capabilities reported as the object progresses. For example, if one node has lower bandwidth capabilities on a link it will reduce the advertised bandwidth in the object it forwards. In this way, when the Adspec object reaches the far end of the path, it reports the best available capabilities along the path.

If some node recognizes but cannot support either the guaranteed service or the controlled load service and the service parameters are present in an Adspec, it sets the Break Bit (shown as B in Figure 4.6) and does not update the parameters for the service type.

The global parameters recorded are straightforward. They report the number of IntServ-capable hops traversed, the greatest bandwidth available (as an IEEE floating point number of bytes per second), the minimum end-to-end path latency (measured in microseconds), and the greatest supported MTU (in bytes). To support the guaranteed service, it is necessary to collect more information than just the global parameters. Two error terms are defined:

■ The error term C is rate-dependent and represents the delay a datagram in the

flow might experience due to the rate parameters of the flow—for example, time taken serializing a datagram broken up into ATM cells.

■ The error term D is rate-independent and represents the worst case non-rate-

based transit time variation. The D term is generally determined or set for an individual node at boot or configuration time. For example, in a device or trans- port mechanism where processing or bandwidth is allocated to a specific time- slot, some part of the per-flow delay may be determined by the maximum amount of time a flow’s data might have to wait for a slot.

The terms C and D are accumulated across the path and expressed as totals (Ctot and Dtot) in bytes and microseconds, respectively. Further, because traffic may be reshaped within the network, partial sums (Csum and Dsum) of the error terms C and D along the path since the last point at which the traffic was reshaped are also reported. Knowing these four delay terms, a node may calculate how much bufferage is needed to ensure that no bytes will be lost.

0

01234567890123 1

IntServ length = 19

Length of service data = 8

Parameter length = 1 Parameter length = 1 Parameter length = 1 Parameter length = 1 Parameter length = 1 Parameter length = 1 Parameter length = 1 Parameter length = 1 Length of service data = 8

Length of service data = 0

Reserved Version₍₀₎

Param type = 4 (IS hop count)

Param type = 6

(path between est) _{Global/default} parameters Guaranteed service parameters Controlled load service parameters Param type = 8

(Min path latency)

Param type = 10 (path MTU) Service type = 2 (guaranteed serv) Param type = 133 (composed Ctot) Param type = 134 (composed Dtot) Param type = 135 (composed Csum) Param type = 10 (composed Dsum) Service type = 5 (controlled load) Reserved B Service type =1 (default/global) Flags = 0 Flags = 0 Flags = 0 Flags = 0 Reserved B Reserved B Flags = 0 Flags = 0 Flags = 0 Flags = 0 IntServ hop count

Path bandwidth estimate

Minumum path latency

Composed path MTU

End-to-end composed value for Ctot

End-to-end composed value for Dtot

Since-last-reshaping point composed C [Csum]

Since-last-reshaping point composed D [Dsum]

2 3

4 5 6 7 8 9 0 123456789 0 1

FIGURE 4.6 FIGURE 4.6

Encoding of the IntServ parameters as used to collect capabilities information by RSVP. 4.3

78

78 CHAPTER 4CHAPTER 4 IP Service Management

Support of the controlled load service does not require any additional informa- tion, but it is still useful to know whether any nodes on the path do not support the service. For this reason, a “null” service parameter is inserted in the Adspec object so that the Break Bit may be recorded.

4.3.5

4.3.5 Choosing to Choosing to Use IntServUse IntServ

IntServ is sometimes described as an “all or nothing” model. To guarantee a par- ticular quality of service across the network, all nodes on the data path must support IntServ and whichever signaling protocol is used to distribute the require- ments. It may be determined, however, that this level of guarantee is not abso- lutely necessary and that the improvement in service generated by using resource reservations on some nodes within the network may be helpful. Protocols such as RSVP recognize this and allow for data paths that traverse both RSVP-capable and RSVP-incapable nodes.

The focus of IntServ is real-time data traffic. It is not a requirement for data exchanges that are not time-dependent, and such flows are better handled by DiffServ where there is no overhead of another signaling protocol and no need for complex resource reservations at each node. However, if real-time quality of service is required, IntServ provides a formal and simple mechanism to describe the flows and requirements.

Some people, especially those with an ATM background, consider the simplic- ity of IntServ’s description of quality of service to be a significant drawback. Compared with the detailed qualification of flows and behavior available in ATM, IntServ appears to offer a crude way of characterizing traffic. However, IntServ (which is specifically designed for packet routers, not cell switches) has proved useful in the Internet where it is used in conjunction with RSVP to support voice over IP, and its very simplicity has brought it as many supporters as detractors. For the ATM purists, RFC 2381 addresses how IntServ parameters may be mapped to ATM QoS parameters.

The alternative to using IntServ is to not use it. There are some strong alterna- tive viewpoints:

■ Limitations on bandwidth are likely to apply most significantly at the edges of

the Internet. This implies that if an application is able to find a local link of sufficient bandwidth to support its functions, there will always be sufficient bandwidth within the Internet to transfer its data. Although this may be an ideal toward which service providers strive within their own networks, it is rarely the case that end-to-end data transfer across the Internet is limited only by the capacity of the first and last links. With the development of bandwidth-greedy applications, there is a continual conflict between bandwidth demand and avail- ability. Besides, quality of service for real-time applications is not simply an issue of the availability of unlimited bandwidth, but is a function of the delays and variations introduced within the network.

■ Simple priority schemes such as DiffServ provide sufficient grading of service to

facilitate real-time applications. This may be true when only a proportion of the traffic within the network requires real-time quality of service, in which case simply giving higher priority to real-time traffic can ensure that it is handled promptly and gets the resources it needs. However, as the percentage of high-priority traffic increases, the priority scheme becomes unable to handle the requirements ade- quately and all high-priority data flows are equally degraded. There is no way to announce that links are over their capacity or to prevent new flows.

■ It is the responsibility of the application and its IP transport protocol to handle

the vagaries of the network. Adaptive real-time protocols for distributing data have been developed (e.g., the Real-Time Transport Protocol) and provide mechanisms to smooth and buffer delayed or interrupted data. But although these approaches may “heal” the data flows, they can still provide interruptions that the human user is unwilling or unable to accept—readers who have tried to have meaningful conversations over a satellite telephone will know how even a predictable delay of one or two seconds can disrupt dialog.