IntServ

1. Best-effort service on the Internet

The traditional internet operates with a "best-effort" delivery model. The network forwards packets according to available resources without reserving bandwidth or specifying delay and loss parameters for a flow. The model does not distinguish a packet's importance to its application, so treatment depends on current load and device configuration. This was sufficient for many early applications such as email and file transfer. When a packet was delayed or lost, the Transmission Control Protocol (TCP) retransmitted the data, which extended the transfer. Retransmission restores stream completeness but increases transfer time.

Real-time applications such as Voice over IP (VoIP), live video transmission, and online gaming have requirements for delay and delay variation. An audio packet for a phone call that arrives 500 milliseconds late reaches the receiver after its part of the conversation has been used. Delay variation (jitter) and packet loss during congestion degrade these services. Timing and delivery-order requirements are not recorded along the path by this model. A router has no information about the receiver's playback deadline. An architecture was needed to describe predictable traffic-treatment parameters.

2. IntServ and resource reservation

The Integrated Services (IntServ) model was described by the IETF for services with specified performance parameters. Its basis is explicit resource reservationfor a flow. The application receives the selected service class's parameters after admission control accepts the request.

An application using IntServ signals its requirements and requests the resources needed to meet them. The reservation is checked at every router along the path from sender to receiver. When the routers accept the requested share of bandwidth, buffer capacity, and queue treatment, the flow receives agreed end-to-end parameters. A lack of resources at one router causes the request to be rejected and the failed reservation to be reported. The reservation covers intermediate devices, so the decision is not made only by an end host. Conformance to the traffic description remains a condition for using the agreed parameters. This mechanism provides explicit and quantifiable QoS.

3. IntServ mechanisms

The IntServ architecture is built on three concepts that work in concert: the flow, resource reservation, and admission control.

A. Data flows

IntServ operates on the concept of a flow. A flow is a distinguishable data stream from one application. A VoIP call between two users is one flow, a video stream from a server to a user is another, and a file transfer is a third. Source and destination addresses together with port numbers are commonly used to identify it. A router can assign a separate treatment profile on that basis. Routers must identify flow packets to apply the associated service.

B. Resource reservation

An application initiates a reservation by specifying its traffic characteristics and required service level. Signaling carries these parameters to devices on the path. The traffic description lets devices assess whether the requested treatment fits their available capacity. The parameters include an average rate and an allowed burst. The network accounts for two primary resources:

• Bandwidth: A portion of link capacity is assigned to the flow so it can transmit at the required rate while other traffic is served. The assignment does not make the link exclusive to that flow. Router scheduling enforces the assignment.
• Buffer Space: Service parameters account for space for flow packets in router buffers. This handles small traffic bursts without dropping conforming packets and includes queueing in the delay calculation. The buffer size must reflect the burst characteristic in the traffic description. The buffer reduces drops caused by short-term arrivals.

C. Admission control

Admission control compares a request with current commitments and available router resources. A router accepts the reservation when it can still serve existing flows within their parameters after the new reservation is added. Otherwise it rejects the request. The check is performed locally at each device, and the combined decisions determine whether the service can be established along the path. Rejecting a new request leaves established reservations intact. This check protects established reservations from overcommitment.

4. RSVP: The Signaling Protocol for IntServ

The mechanism applications use to communicate requirements and establish reservations is the Resource Reservation Protocol (RSVP). RSVP is a network-control protocol. It carries PATH and RESV messages and signaling state, while application data is sent separately. RSVP uses soft state refreshed by periodic messages. Without refresh, a reservation expires. PATH and RESV messages refresh state after topology changes.

The basic PATH and RESV exchange

The basic RSVP exchange has two directions and uses PATH and RESV messages.

1. Step 1: The PATH Message (Sender to Receiver)

   The exchange begins with the data sender, such as a video server. Its application sends an RSVP PATH message to the receiver's IP address. The message follows the route used by the data. Each IntServ-aware router records path state, including the previous hop, so a RESV message can be sent toward the sender. The path state is created at each router and can be refreshed by a subsequent PATH message. After a route change, path state can be rebuilt. PATH does not reserve resources.

2. Step 2: The RESV Message (Receiver to Sender)

   When PATH reaches the receiver, such as a video client, the receiver creates an RSVP RESV message. It carries the requested service, for example 5 Mbps of bandwidth, and travels toward the sender along the path established by PATH.

   The RESV message travels hop by hop toward the sender. Each router on the path performs the following actions:

   • The router's admission control module examines the reservation request.
   • It checks its available bandwidth and buffer resources to see if it can satisfy the request.
   • If it can, it allocates resources, updates reservation state, and forwards the RESV message to the next router toward the sender.
   • If it cannot satisfy the request, it rejects it and sends a reservation error message back to the receiver.

   If RESV reaches the original sender, every router on the path has accepted and stored the reservation. The agreed service applies end to end to traffic that conforms to its parameters, so the sender can begin transmission. A rejection at any router stops reservation setup. RSVP does not carry the application flow. After the reservation is established, the data uses ordinary IP forwarding.

RSVP reservations are initiated by receivers. The model also supports multicast, where one sender transmits to multiple receivers. Each receiver can send an independent request adapted to its needs and link capacity. This exchange lets receivers request resources independently of the sender.

5. IntServ Service Classes

IntServ defines two primary classes of service that an application can request.

• Guaranteed Service

  Guaranteed Service provides a mathematically determined, deterministic upper bound on end-to-end packet delay. An application describes its traffic with a token bucket model that specifies an average rate and an allowed burst. For traffic that conforms to its profile, the service provides no queue-overflow loss and delivery within the calculated delay bound, assuming functioning network elements and an unchanged route. The conformance condition limits traffic outside the specified profile. This variant serves real-time applications with strict timing requirements.

• Controlled-Load Service

  Controlled-Load Service does not specify a strict numerical delay bound. Its goal is performance close to that received by the same flow in an uncongested best-effort network. The absence of a strict limit does not remove admission control. The application still needs its own timing-recovery and buffering mechanism, so this service suits adaptive real-time applications that tolerate delay variation.

6. IntServ scalability

Per-flow service parameters require reservation state and signaling in devices along the path. RSVP state is refreshed, so a large number of flows also increases signaling traffic. Reservation updates also require processing at each participating router. The resulting path state grows with the number of active reservations. It can also increase control-plane work. As the number of flows grows, these entries limit IntServ scalability.

• Per-flow state maintenance:A core router in a large ISP network might handle a large number of concurrent flows. In the IntServ model, it stores a separate reservation entry for every flow. An entry includes service parameters and treatment state for the flow. This growing number of entries increases the device's memory and processing requirements.
• Signaling overhead: RSVP messages consume network bandwidth and router processing time. In a large network, PATH and RESV messages establish, refresh, and remove reservation state. Refresh continues for the lifetime of the service.
• Complexity: Implementing and managing IntServ and RSVP across a multi-vendor, multi-provider network requires coordination of state, signaling, and policies between domains. Coordination also covers service classes and policy consistency.

For these reasons, IntServ is rarely used in large public networks. It fits smaller, controlled private networks, such as corporate video-conferencing networks and industrial control systems, where the flow count remains manageable. Smaller scale makes state maintenance and admission control easier. The IntServ model is a reference point for aggregating reservation state with DiffServ. RSVP-TE extensions use RSVP to establish LSP tunnels in MPLS and can use resource reservations.