Comparing QoS Models: IntServ vs DiffServ in Cisco Networks

Quality of Service in enterprise networks isn't a single monolithic system. Before you can configure policy maps and class maps with confidence, you need a clear mental model of how traffic prioritization actually works at scale. Two foundational QoS architectures define this space: Integrated Services (IntServ) and Differentiated Services (DiffServ). Understanding their design philosophies, limitations, and practical tradeoffs is essential for both the ENCOR exam and real-world enterprise deployments.

The Core Problem Both Models Solve

IP networks are inherently best-effort. Every packet competes equally for bandwidth and forwarding resources. When congestion occurs, packets get dropped or delayed without regard for whether they carry a VoIP call or a bulk file transfer. QoS models exist to change this behavior by classifying, marking, and managing traffic so that latency-sensitive or business-critical flows receive preferential treatment.

Both IntServ and DiffServ address this problem, but they take fundamentally different approaches in terms of signaling, scalability, and operational complexity.

IntServ: Per-Flow Reservation Model

Integrated Services was defined in RFC 1633 and operates on a per-flow reservation model. Before a flow transmits delay-sensitive traffic, it signals the network to reserve bandwidth along every hop in the path. This signaling is handled by the Resource Reservation Protocol (RSVP), defined in RFC 2205.

How RSVP Works

RSVP uses a sender-initiated PATH message that travels from source to destination, recording route state along the way. The receiver responds with a RESV message that travels upstream, triggering bandwidth reservations at each hop. Every router in the path must support RSVP and maintain per-flow state.

! Enable RSVP on an interface with a 10 Mbps bandwidth limit
! and a 1 Mbps maximum single-flow reservation
interface GigabitEthernet0/1
 ip rsvp bandwidth 10000 1000

To verify RSVP state and active reservations:

Router# show ip rsvp interface
Router# show ip rsvp reservation
Router# show ip rsvp sender

IntServ Service Classes

IntServ defines two service classes beyond best-effort:

• Guaranteed Service: Provides strict bandwidth and delay bounds. No packet loss due to congestion if the flow stays within its reserved parameters.
• Controlled-Load Service: Provides behavior similar to a lightly loaded network. Not a hard guarantee, but significantly better than best-effort.

Why IntServ Doesn't Scale

The fundamental limitation of IntServ is state maintenance. Every router in the path must track state for every active flow. In a large enterprise or service provider core with thousands of concurrent flows, this creates memory and processing overhead that becomes unmanageable. RSVP messages also require periodic refresh (default every 30 seconds), which generates control plane traffic proportional to the number of active flows.

For these reasons, IntServ with RSVP is rarely deployed across an entire enterprise network. It sees limited use in specific scenarios such as MPLS Traffic Engineering tunnels, voice admission control at the WAN edge, or smaller, tightly controlled environments.

DiffServ: Class-Based Marking Model

Differentiated Services, defined in RFC 2474 and RFC 2475, abandons per-flow state entirely. Instead of reserving resources for individual flows, DiffServ marks packets at the network edge with a Per-Hop Behavior (PHB) code, and every router in the path makes forwarding decisions based on that marking. No signaling protocol is required, and no per-flow state is maintained in the core.

The DSCP Field

DiffServ repurposes the IP header's Type of Service (ToS) byte. The upper 6 bits form the Differentiated Services Code Point (DSCP), providing 64 possible markings. The lower 2 bits are the Explicit Congestion Notification (ECN) field.

Key DSCP values you must know for the ENCOR exam:

• CS0 (DSCP 0): Best-effort, equivalent to ToS 0.
• CS1 through CS7: Class Selector values, backward-compatible with IP Precedence.
• AF11 through AF43: Assured Forwarding. Four classes with three drop precedences each.
• EF (DSCP 46): Expedited Forwarding. Used for voice bearer traffic. Provides low latency, low jitter, and low loss.
• CS6 (DSCP 48): Used for network control traffic such as routing protocols.

Trust Boundaries and Classification

DiffServ depends on correctly marking traffic at the trust boundary, typically the access layer switch or the WAN edge router. Traffic entering the network is classified, marked, and then treated according to its DSCP value at every downstream hop.

! MQC example: classify voice traffic and mark with EF
class-map match-any VOICE-BEARER
 match protocol rtp audio

policy-map MARK-TRAFFIC
 class VOICE-BEARER
  set dscp ef

interface GigabitEthernet0/0
 service-policy input MARK-TRAFFIC

Verification:

Router# show policy-map interface GigabitEthernet0/0
Router# show class-map

Per-Hop Behaviors

Each router applies a PHB to packets based on their DSCP marking. The three standardized PHBs are:

• Default PHB: Best-effort forwarding for DSCP 0.
• Assured Forwarding (AF) PHB: Four traffic classes with three drop precedences. Higher AF class receives more bandwidth; lower drop precedence means lower probability of being dropped during congestion.
• Expedited Forwarding (EF) PHB: Guarantees a minimum departure rate independent of other traffic. This is the foundation of a Low Latency Queue (LLQ) in Cisco's implementation.

IntServ vs DiffServ: Direct Comparison

• Granularity: IntServ operates per-flow; DiffServ operates per traffic class.
• Scalability: IntServ does not scale to large networks; DiffServ scales to service provider cores.
• Signaling: IntServ requires RSVP; DiffServ requires no signaling protocol.
• State: IntServ maintains per-flow state on every router; DiffServ maintains no per-flow state in the core.
• Guarantees: IntServ provides hard per-flow guarantees; DiffServ provides class-level assurances.
• Deployment complexity: IntServ requires all-hop RSVP support; DiffServ only requires marking at the edge.

Real-World Enterprise Application

In practice, modern Cisco enterprise networks rely almost exclusively on DiffServ implemented through Modular QoS CLI (MQC). The Cisco QoS Baseline and the RFC 4594 configuration guide define a standard 12-class model that maps business traffic types to appropriate DSCP values, queuing behaviors, and bandwidth allocations.

RSVP and IntServ occasionally appear at the WAN edge for admission control, particularly in legacy voice deployments using Cisco Unified Communications Manager with RSVP-based call admission control. In those architectures, RSVP signals at the edge while DiffServ handles forwarding behavior in the core, giving you the best of both models at different layers of the network.

For the ENCOR exam, expect scenario questions that test whether you can identify which model is appropriate given a described network constraint, and whether you understand why DiffServ replaced IntServ as the dominant enterprise QoS framework.

What's Next

With the QoS model comparison firmly in place, the next step is digging into Cisco's MQC implementation in detail: building class maps, policy maps, and service policies to implement a DiffServ-based QoS strategy. We'll cover classification, marking, queuing, and shaping configurations with full CLI examples and output verification.

Tools and resources for this topic

• CCNP ENCOR 350-401 Official Cert Guide — The definitive ENCOR study resource by Brad Edgeworth. Covers enterprise infrastructure, virtualisation, and automation.