s01 - ip qos intrduction

It includes the following topics: n Introduction to IP Quality of Service n Integrated Services Model n Differentiated Services Model n Building Blocks of IP QoS Mechanisms n Enterprise

Trang 1

Introduction

Overview

The module presents a thorough overview of quality of service models and mechanisms as implemented in complex service provider and enterprise networks

It includes the following topics:

n Introduction to IP Quality of Service

n Integrated Services Model

n Differentiated Services Model

n Building Blocks of IP QoS Mechanisms

n Enterprise Network Case Study

n Service Provider Case Study

Objectives

Upon completion of this module, you will be able to perform the following tasks:

n Describe the need for IP QoS

n Describe the Integrated Services model

n Describe the Differentiated Services model

n Describe the building blocks of IP QoS mechanisms (classification, marking, metering, policing, shaping, dropping, forwarding, queuing)

n List the IP QoS mechanisms available in the Cisco IOS

n Describe what QoS features are supported by different IP QoS mechanisms

Trang 2

Introduction to IP Quality of Service

Objectives

Upon completion of this lesson, you will be able to perform the following tasks:

n Describe different types of applications and services that have special resource requirements

n List the network components that affect the throughput, delay and jitter in IP networks

n List the benefits of deploying QoS mechanisms in IP networks

n List QoS mechanisms available in Cisco IOS

n Describe typical enterprise and service provider networks and their QoS-related requirements

Trang 3

Why IP QoS?

• Application X is slow!

• Video broadcast occasionally stalls!

• Phone calls over IP are no better than over satellite!

• Phone calls have really bad voice quality!

• ATM (the money-dispensing-type) are responsive!

non-•

The purpose of this module is to determine the following:

n What is, or might be, missing in today’s IP networks?

n What can IP Quality of Service (QoS) do to help solve the problem?

A decade ago when the Internet was still in its early stages there was not much available Most users were using Gopher to find information and FTP to retrieve it The Internet was something new and exciting and no one was really bothered by the fact that it was slow

Today, however, the Internet is serving a large population of all walks of life The Internet has also grown in its service offering Users are using the Internet to view static or dynamic information, transmit voice and video, shop, play etc

Along with these new applications of the Internet come some demands on the service(s) it provides:

n Some applications are slow

n Video broadcast or conferencing may have bad picture quality or appear jerky

n Voice sessions may have bad voice quality or periods of silence

n Critical transactions may take too long (too many seconds)

n Bulk transfers take too long (too many hours) This module focuses on most common quality-related problems people encounter in

IP networks

Trang 4

Because

• Application X is slow! (not enough BANDWIDTH )

• Video broadcast occasionally stalls! (DELAY temporarily increases – JITTER )

• Phone calls over IP are no better than over satellite! (too much DELAY )

• Phone calls have really bad voice quality! (too many

• ATM (the money-dispensing-type) are non responsive! (too many DROPs )

•

Quality of Service is usually identified by the following parameters:

n Amount of bandwidth available to a certain application or user

n Average delay experienced by IP packets on end-to-end or link basis

n Jitter that affects applications that transmit packets at a certain fixed rate and

expect to receive them at approximately the same rate (for example, voice and video)

n Drops of packets when a link is congested can severely impact fragile

applications

n Admission control which prevents too many sessions from congesting links

and causing degradation in quality of service (for example, voice sessions)

Trang 5

to the overall delay

• Variable delay – sometimes there is a lot of other traffic which results in more delay

• Drops – packets have to be dropped when a link is congested

If the network is empty any application should get enough bandwidth, acceptable low and fixed delay and not experience any drops The reality, however, is that there are multiple users or applications using the network at the same time

Trang 6

Available Bandwidth

• Maximum available bandwidth equals the bandwidth of the weakest link

• Multiple flows are contesting for the same bandwidth resulting in much less bandwidth being available to one single application.

BW avail = BW max /Flows

The example above illustrates an empty network with four hops between a server and a client Each hop is using different media with a different bandwidth The maximum available bandwidth is equal to the bandwidth of the slowest link

The calculation of the available bandwidth, however, is much more complex in cases where there are multiple flows traversing the network The calculation of the available bandwidth in the illustration is a rough approximation

Trang 7

Propagation delay (P2) Processing and queuing delay (Q2)

Propagation delay (P3) Processing and queuing delay (Q3)

Delay = P1 + Q1 + P2 + Q2 + P3 + Q3 + P4 = X ms

Propagation delay (P4)

The figure illustrates the impact a network has on the end-to-end delay of packets going from one end to the other Each hop in the network adds to the overall delay because of the following two factors:

1 Propagation (serialization) delay of the media that, for the most part, depends solely on the bandwidth

2 Processing and queuing delays within a router, which can be caused by a wide variety of conditions

Ping (ICMP echoes and replies) can be used to measure the round-trip time of IP packets in a network There are other tools available to periodically measure responsiveness of a network

Trang 8

Processing and Queuing Delay

• Processing Delay is the time it takes for a router to take the packet from an input interface and put it into the output queue of the output interface

• Queuing Delay is the time a packets resides in the output queue of a router.

• Propagation or Serialization Delay is the time it takes to transmit a packet.

n Processing Delay is the time it takes for a router to take the packet from an

input interface and put it into the output queue of the output interface The processing delay depends on various factors, such as:

– CPU speed – CPU utilization – IP switching mode – Router architecture – Configured features on both input and output interface

n Queuing Delay is the time a packet resides in the output queue of a router It

depends on the number and sizes of packets already in the queue and on the bandwidth of the interface It also depends on the queuing mechanism

n Propagation or Serialization Delay is the time it takes to transmit a packet It

usually only depends on the bandwidth of the interface CSMA/CD media may add slightly more delay due to the increased probability of collisions when an interface is nearing congestion

Trang 9

IP

Forwarding

IP IP IP IP

Tail-drop

The usual packet loss occurs when routers run out of buffer space for a

particular interface (output queue) The figure illustrates a full output queue of an interface, which causes newly arriving packets to be dropped The term used for such drops is simply “output drop” or “tail-drop” (packets are dropped at the tail of the queue)

Routers might also drop packets for other (less common) reasons, for example:

n Input queue drop - main CPU is congested and cannot process packets (the input queue is full)

n Ignore - router ran out of buffer space

n Overrun - CPU is congested and cannot assign a free buffer to the new packet

n Frame errors (CRC, runt, giant)—hardware-detected error in a frame

Trang 10

How to Increase Available

• Take some bandwidth from less important applications.

Compress the Headers cTCP data

• Compress the header of IP packets.

Compress the Payload Compressed packet

• Compress the payload of layer-2 frames.

Priority Queuing (PQ) Custom Queuing (CQ) Modified Deficit Round Robin (MDRR) Class-based Weighted Fair Queing (CB-WFQ) Stacker

Predictor

TCP Header Compression RTP Header Compression

There are several approaches to solving a problem of insufficient bandwidth:

n The best approach is to increase the link capacity to accommodate all applications and users with some extra bandwidth to spare This solution sounds simple enough but in the real world it brings a high cost in terms of the money and time it takes to implement Very often there are also technological limitations to upgrading to a higher bandwidth

n Another option is to classify traffic into QoS classes and prioritize it according

to importance (business-critical traffic should get enough bandwidth, voice should get enough bandwidth and prioritized forwarding and the least important traffic should get the remaining bandwidth) There are a wide variety of mechanisms available in the Cisco IOS that provide bandwidth guarantees, for example:

– Priority or Custom Queuing – Modified Deficit Round Robin (on Cisco 12000 series routers) – Distributed ToS-based and QoS-group-based Weighted Fair Queuing (on Cisco 7x00 series routers)

– Class-based Weighted Fair Queuing

n Optimizing link usage by compressing the payload of frames (virtually) increases the link bandwidth Compression, on the other hand, also increases delay due to complexity of compression algorithms Using hardware

Trang 11

data (payload-to-header ratio is small) Typical examples of header compression are TCP Header Compression and RTP Header Compression

Trang 12

How to Reduce Delay?

• Upgrade the link The best solution but also the most expensive.

FIFO queuing

• Forward the important packets first.

Compress the Headers cRTP data

• Compress the header of IP packets.

Priority Queuing (PQ) Custom Queuing (CQ) Strict Priority MDRR

IP RTP prioritization Class-based Low-latency Queuing (CB-LLQ)

TCP Header Compression RTP Header Compression

RTP Compress the Payload Compressed packet

• Compress the payload of layer-2 frames (it takes time).

Stacker Predictor

Assuming that a router is powerful enough to make a forwarding decision in a negligible time it can be said that most of the processing, queuing delay and propagation delay is influenced by the following factors:

n Average length of the queue

n Average length of packets in the queue

n Link bandwidth There are several approaches to accelerate packet dispatching of delay-sensitive flows:

n Increase link capacity Enough bandwidth causes queues to shrink, making sure packets do not have to wait long before they can be transmitted Additionally, more bandwidth reduces serialization time On the other hand, this might be an unrealistic approach due to the costs associated with the upgrade

n A more cost-effective approach is to enable a queuing mechanism that can give priority to delay-sensitive packets by forwarding them ahead of other packets There are a wide variety of queuing mechanisms available in Cisco IOS that have pre-emptive queuing capabilities, for example:

– Priority Queuing – Custom Queuing – Strict-priority or Alternate Priority queuing within the Modified Deficit

Trang 13

n Payload compression reduces the size of packets and, therefore, virtually increases link bandwidth Additionally, compressed packets are smaller and need less time to be transmitted On the other hand, compression uses complex algorithms that take time and add to the delay This approach is, therefore, not used to provide low-delay propagation of packets

n Header compression on the other hand is not as CPU-intensive and can be used

in combination with other mechanisms to reduce delay It is especially useful for voice packets that have a bad payload-to-header ratio, which is improved by reducing the header of the packet (RTP header compression)

By minimizing delay, jitter is also reduced (delay is more predictable)

Trang 14

How to Prevent Packet Loss?

• Upgrade the link The best solution but also the most expensive.

FIFO queuing

• Guarantee enough bandwidth to sensitive packets.

Custom Queuing (CQ) Modified Deficit Round Robin (MDRR) Class -based Weighted Fair Queuing (CB-WFQ)

Dropper

• Prevent congestion by randomly dropping less important packets before congestion occurs

Weighted Random Early Detection (WRED)

Packet loss is usually a result of congestion on an interface Most applications that use TCP experience slow down due to TCP adjusting to the network’s resources (dropped TCP segments cause TCP sessions to reduce their window sizes) There are some other applications that do not use TCP and cannot handle drops (fragile flows)

The following approaches can be taken to prevent drops of sensitive applications:

n Increased link capacity to ease or prevent congestion

n Guarantee enough bandwidth and increase buffer space to accommodate bursts

of fragile applications There are several mechanisms available in Cisco IOS that can guarantee bandwidth and/or provide prioritized forwarding to drop-sensitive applications, for example:

– Priority Queuing – Custom Queuing – Modified Deficit Round Robin (on Cisco 12000 series routers) – IP RTP prioritization

– Class-based Weighted Fair Queuing – Class-based Low-latency Queuing

n Prevent congestion by dropping other packets before congestion occurs

Weighted Random Early Detection can be used to start dropping other packets

Trang 15

n Traffic Policing can limit the rate of less important packets to provide better service to drop-sensitive packets (Committed Access Rate and Class-based Policing)

Trang 16

Which Applications Have Which

Batch (e.g

FTP) Fragile (e.g

Important

Not Important

Once the applications are identified and prioritized it must be decided which QoS mechanisms are to be put in place

The approach to provide QoS to applications is usually used in Enterprise Networks where important (business-critical) applications are easy to identify Most applications can be classified based on TCP or UDP port numbers Some applications use dynamic port numbers that, somewhat, makes classification more difficult Cisco IOS supports Network-based Application Recognition (NBAR), which can be used for such application

Trang 17

Which Services can be Implemented in a Network?

• Service provider networks typically offer services based on source and destination addresses

Trang 18

How can QoS be Applied?

• Best effort – no QoS is applied to packets (default behavior)

• Integrated Services model – applications signal to the network that they require special QoS

• Differentiated Services model – the network recognizes classes that requires special QoS

By investigating the history of the Internet it can be divided into three QoS-related periods:

n Best-effort The Internet was designed for best-effort, no-guarantee delivery

of packets This behavior is still predominant in today’s Internet

n Integrated Services model Introduced to supplement the best-effort delivery

by setting aside some bandwidth for applications that require bandwidth and delay guarantees The Integrated Services model expects applications to signal their requirements to the network Resource Reservation Protocol (RSVP) is used to signal QoS requirements to the network

n Differentiated Services model Added to provide more scalability in

providing QoS to IP packets The main difference is that the network recognizes packets (no signaling is needed) and provides the appropriate services to them

Today’s IP networks can use all three models at the same time

Trang 19

Summary

IP Quality of Service is used to improve performance of IP networks Quality of Service can be measured based on available bandwidth, end-to-end delay, packet loss and jitter Different QoS mechanisms can be used to provide a predictable service

There are many different types of QoS mechanisms available in the Cisco IOS:

n Queuing mechanisms: Priority Queuing (PQ), Custom Queuing (CQ),

Weighted Fair Queuing (WFQ) with its distributed versions, IP RTP Prioritization, Modified Deficit Round Robin (MDRR), Class-based Weighted Fair Queuing (CB-WFQ) and Class-based Low-latency Queuing (CB-LLQ)

n Traffic Shaping mechanisms: Generic Traffic Shaping (GTS), Frame Relay

Traffic Shaping (FRTS) and Class-based Shaping

n Traffic Policing mechanisms: Committed Access Rate (CAR) and

Class-based Policing

n Dropping mechanisms: Weighted Random Early Detection (WRED)

n Link Efficiency mechanisms: Stacker, Predictor, TCP Header Compression

and RTP Header Compression

n Signaling mechanism: Resource Reservation Protocol (RSVP)

Review Questions

Answer the following questions:

n What are the relevant parameters that define the quality of service?

n What can be done to give more bandwidth to an application?

n What can be done to reduce delay?

n What can be done to prevent packet loss?

n Name the three QoS models?

Trang 20

Integrated Services Model

Objectives

n Describe the IntServ model

n List the key benefits and drawbacks of the IntServ model

n List some implementations that are based on the IntServ model

n Describe the need for Common Open Policy Service (COPS)

Trang 21

applications

The Internet Engineering Task Force (IETF) is responsible for standardization of the Internet and most of the protocols used in the Internet When faced with a challenge, vendors introduce their own solutions However, the IETF is there to create standards that allow different vendor’s equipment to interoperate One of the challenges in the past was to introduce Quality of Service into the best-effort driven Internet The Integrated Services (IntServ) model was proposed as standard with Resource Reservation Protocol (RSVP) as the mechanism used to signal QoS requirements to the network

The IntServ model is described in the RFC 1633 (http://www.ietf.org/rfc/rfc1633.txt)

The use of RSVP for Integrated Services is described in RFC 2210 (http://www.ie tf.org/rfc/rfc2210.txt)

Trang 22

IntServ Building Blocks

• Resource Reservation is used to identify an application (flow) and signal if there are enough available resources for it

• Admission Control is used to determine if the application (flow) can get the requested resources

request request request request

reserve reserve

Local Admission Control

Remote Admission Control

Local Admission Control

Policy Decision Point (PDP)

Policy Enforcement Point (PEP)

The IntServ model itself describes the application of QoS in IP networks

Additional standards were developed to cover the exact protocols used to implement Quality of Service:

n Resource Reservation is implemented using the Resource Reservation Protocol (RSVP)

n Admission Control is either implemented locally on the routers or offloaded to

central servers

Common Open Policy Service (COPS) is another IETF standard that defines a

protocol that can be used for policy exchange between network devices (Policy Enforcement Point or PEP) and policy servers (Policy Decision Point or PDP)

An additional standard was added to integrate RSVP with COPS

The COPS (Common Open Policy Service) Protocol is defined in RFC 2748 (http://www.rfc-editor.org/rfc/rfc2748.txt)

COPS usage for RSVP is defined in RFC 2749 (http://www.rfc-editor.org/rfc/rfc2749.txt)

Trang 23

Reservation and Admission

• Common Open Policy Service ( COPS ) was developed to offload admission control to a central policy server (RFC 2748-2753)

Following is a list of some of the IETF standards (RFCs) that describe RSVP, COPS, the IntServ model and applications:

n Resource ReSerVation Protocol (RSVP), Version 1, Functional Specification (http://www.ietf.org/rfc/rfc2205.txt)

n RSVP Management Information Base using SMIv2 (http://www.ietf.org/rfc/rfc2206.txt)

n RSVP Extensions for IPSEC Data Flows (http://www.ietf.org/rfc/rfc2207.txt)

n Resource ReSerVation Protocol (RSVP), Version 1, Applicability Statement, Some Guidelines on Deployment (http://www.ietf.org/rfc/rfc2208.txt)

n Resource ReSerVation Protocol (RSVP), Version 1, Message Processing Rules (http://www.ietf.org/rfc/rfc2209.txt)

n The Use of RSVP with IETF Integrated Services (http://www.ietf.org/rfc/rfc2210.txt)

n Specification of the Controlled-Load Network Element Service (http://www.ietf.org/rfc/rfc2211.txt)

n Specification of Guaranteed Quality of Service (http://www.ietf.org/rfc/rfc2212.txt)

n Integrated Services Management Information Base using SMIv2 (http://www.ietf.org/rfc/rfc2213.txt)

n Integrated Services Management Information Base, Guaranteed Service Extensions using SMIv2 (http://www.ietf.org/rfc/rfc2214.txt)

n General Characterization Parameters for Integrated Service Network Elements (http://www.ietf.org/rfc/rfc2215.txt)

Trang 24

n The COPS (Common Open Policy Service) Protocol (http://www.ietf.org/rfc/rfc2748.txt)

n COPS usage for RSVP (http://www.ietf.org/rfc/rfc2749.txt)

n RSVP Extensions for Policy Control (http://www.ietf.org/rfc/rfc2750.txt)

n Signaled Preemption Priority Policy Element (http://www.ietf.org/rfc/rfc2751.txt)

n Identity Representation for RSVP (http://www.ietf.org/rfc/rfc2752.txt)

n A Framework for Policy-based Admission Control (http://www.ie tf.org/rfc/rfc2753.txt)

n SBM (Subnet Bandwidth Manager): A Protocol for RSVP-based Admission Control over IEEE 802-style networks (http://www.ietf.org/rfc/rfc2814.txt)

n Definitions of Managed Objects for Common Open Policy Service (COPS) Protocol Clients (http://www.ietf.org/rfc/rfc2940.txt)

n COPS Usage for Policy Provisioning (COPS-PR) (http://www.ietf.org/rfc/rfc3084.txt)

Trang 25

RSVP-enabled Applications

• RSVP is typically used by applications carrying voice or video over IP networks (initiated by a host)

• RSVP with extensions is also used by MPLS Traffic Engineering to establish MPLS/TE tunnels (initiated by a router)

RSVP, as a resource reservation protocol, was designed for use by end devices in networks (for example, personal computers and servers) It is a protocol that has

to be supported by an application that requires network resources and needs guarantees

n Typical examples of applications that would benefit from RSVP are voice sessions that require a small amount of bandwidth with low-delay propagation

n Cisco routers that act as voice gateways can use RSVP to request resources (controlled-load and guaranteed-delay)

n Cisco routers that use Multiprotocol Label Switching (MPLS) Traffic Engineering (MPLS/TE) use RSVP with extensions to reserve bandwidth and set up MPLS/TE tunnels through MPLS and RSVP enabled networks

n Cisco Soft Phone or Microsoft NetMeeting are Windows applications that use RSVP to get resources for their VoIP sessions

There are an increasing number of applications that use RSVP to request QoS guarantees from a network

Trang 26

IntServ Implementation Options

1) Explicit RSVP on each network node

2) RSVP ‘pass -through’ and CoS transport

- map RSVP to CoS at network edge

- pass -through RSVP request to egress

RSVP

Class of Service

or Best Effort

3) RSVP at network edges and ‘pass -through’ with

- best-effort forwarding in the core (if there is enough bandwidth in the core)

The figure illustrates three options available when implementing QoS mechanisms via RSVP in a network

1 The first option is to simply enable RSVP on all interfaces of all the routers in the network This approach is mainly used in enterprise networks that have more predictable RSVP flows (in terms of quantity and direction because they typically use hub-and-spoke topology) Large service provider networks are less inclined to use RSVP throughout their networks either because RSVP would require too many concurrent reservations on a single interface or because the routers are not capable of providing guarantees to individual flows

on high-bandwidth interfaces

2 An alternative option is to use RSVP on network edges where there is typically less bandwidth per interface and congestion is more likely The edge-to-core routers (for example, access or distribution layer routers) mark RSVP flows with IP markers, which can then be used in a DiffServ enabled core—the Differentiated Services model is covered in the next lesson)

3 Another option is to use RSVP on network edges and rely on best-effort delivery in a non-congested core

Trang 27

Explicit RSVP Transport IntServ End-to-End

A second issue is that WFQ is a very CPU-intensive algorithm and does not run at high speed on today’s routers In the backbone, high speed is a mandatory

requirement

Trang 28

RSVP Pass-Through IntServ - DiffServ Integration

Precedence Classifier Premium Standard

Ingress Router

• RSVP protocol

Mapped to classes

• WRED applied based

on class

Egress Router

• RSVP protocol sent on to destination

• WFQ applied to manage egress flow

WRED

An alternative to enabling RSVP end-to-end is to use RSVP as a means to signal special requirements between the customer and the ISP edge, but not to use it in the backbone In this model, packets are mapped on RSVP flows into special service classes which give each class preferential treatment in the core of the network when congestion occurs This avoids the scalability problem of end-to-end RSVP, since these flows are processed between the end station and the network edge and not in the middle of the backbone

By using WRED on routers, instead of WFQ, much higher speeds can be supported Alternatively, Class-based WFQ can be used on moderate-speed links

to provide better control of bandwidth allocation The third option is not to use RSVP in the core and rely on best-effort delivery if the core is not congested Lastly, mapping classes of service to ATM is more straightforward than mapping RSVP directly to ATM

This concept may accelerate the ability of ISPs to offer an RSVP service and enable new application areas

Trang 29

IntServ Support in IOS

• RSVP and Weighted Fair Queuing supported since ’95

• RSVP signaling for VoIP calls supported on all VoIP platforms

• IOS supports hop-by-hop and pass-through RSVP

• RSVP-to-DSCP (DiffServ Code Point) mapping (RSVP proxy) in 12.1T

Both RSVP and WFQ have been available for some time and can be used on all low-end platforms and on high-end platforms that are typically used to concentrate customer networks

Newer RSVP mechanisms include:

n Mapping of RSVP to DSCP (the Differentiated Services model with the details

of the DiffServ Code point is covered in the next lesson)

n Mapping of RSVP to ATM SVCs (this technology is covered in the “IP QoS -

IP over ATM” module)

Trang 30

Benefits and Drawbacks of the

IntServ Model

Benefits and Drawbacks of the

IntServ Model

+ RSVP benefits:

• Explicit resource admission control (end to end)

• Per-request policy admission control (authorization object, policy object)

• Signaling of dynamic port numbers (for example, H.323)

• Continuous signaling due to stateless architecture

• Not scalable

The main benefits of RSVP are:

n It signals QoS requests per individual flow The network can then provide guarantees to these individual flows The problem of this is that it does not scale

to large networks because of the large numbers of concurrent RSVP flows

n It informs network devices of flow parameters (IP addresses and port numbers) Some applications use dynamic port numbers, which can be difficult for network devices to recognize NBAR is a mechanism that has been introduced to supplement RSVP for applications that use dynamic port numbers but do not use RSVP

It supports admission control that allows a network to reject (or down-grade) new RSVP sessions if one of the interfaces in the path has reached the limit (all reservable bandwidth is booked)

The main drawbacks of RSVP are:

n Continuous signaling due to stateless operation of RSVP

n RSVP is not scalable to large networks where per-flow guarantees would have

to be made to thousands of flows

Trang 31

Common Open Policy Service

• Common Open Policy Service (COPS) provides the following benefits when used with RSVP:

– Centralized management of services

– Centralized admission control and authorization of RSVP flows

scalable

The Common Open Policy Service (COPS) is an add-on to RSVP It can be used

to offload certain tasks from network devices to a central server The result is that the configuration of individual devices is more standardized (template-based) and all individual parameters are managed from a centralized location In addition, COPS supports admission control of individual flows (the network device determines the available resources and the central server authorizes the flow)

Trang 32

Summary

The Integrated Services (IntServ) model was introduced to allow vendors of routers to add interoperable QoS mechanisms to their best-effort packet forwarding Resource Reservation Protocol (RSVP) is used by end-devices to signal QoS requirements to the network Common Open Policy Service (COPS) is used to offload policy management to central servers

Review Questions

Answer the following questions:

n What are the two building blocks of the Integrated Services model?

n Which protocol is used to signal QoS requirements to the network?

Trang 33

Differentiated Services Model

Objectives

n Describe the DiffServ model

n List the key benefits of the DiffServ model compared to the IntServ model

n Describe the purpose of the DS field in IP headers

n Describe the interoperability between DSCP-based and IP-precedence-based devices in a network

n Describe the Expedited Forwarding service

n Describe the Assured Forwarding service

Trang 34

Differentiated Services Model

• Differentiated Services model describes services associated with traffic classes

• Complex traffic classification and conditioning is performed at network edge resulting in a per-packet Differentiated Services Code Point ( DSCP ).

• No per-flow/per-application state in the core

• Core only performs simple ‘per-hop behavior's’ on traffic aggregates

• Goal is Scalability

The Differentiated Services (DiffServ) model describes services associated with traffic classes Traffic classes are identified by the value of the DiffServ

Code Point (DSCP replaces IP precedence in the ToS field of the IP header)

The main goals of the DiffServ model are to provide scalability and a similar level

of QoS to the IntServ model, without having to do it on a per-flow basis The

network simply identifies a class (not application) and applies the appropriate

per-hop behavior (QoS mechanism)

The DiffServ model and associated standards are described in the following IETF standardization documents (RFCs):

n An Architecture for Differentiated Services (http://www.ietf.org/rfc/rfc2475.txt)

n Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers (http://www.ietf.org/rfc/rfc2474.txt)

n Assured Forwarding per-hop behavior (PHB) Group (http://www.ietf.org/rfc/rfc2597.txt)

n An Expedited Forwarding per-hop behavior (PHB) (http://www.ietf.org/rfc/rfc2598.txt)

Trang 35

The DiffServ model describes services and allows for more user-defined services

to be used in a DiffServ-enabled network

Services are provided to classes A class can be identified as a single application

or, as in most cases, it can be identified based on source or destination IP address The idea is for the network to recognize a class without having to receive any request from applications This allows the QoS mechanisms to be applied to other applications that do not have the RSVP functionality, which is the case for 99% of applications that use IP

The introduction of the DiffServ Code Point (DSCP) replaces the IP precedence but maintains interoperability with non-DS compliant devices (those that still use IP precedence) Because of this backward-compatibility DiffServ can be gradually deployed in large networks

Trang 36

The DiffServ field (DS fie ld) is the former 8-bit Type of Service field The main difference is that the DSCP supports more classes (64) than IP precedence (8) The most important part of designing QoS is to provision services as explained on the next page

Trang 37

Why is Provisioning Important?

• QoS does not create bandwidth!

multiple classes

• QoS gives better service to a provisioned class with respect to another class

well-Provisioning requires a thorough network analysis to determine parameters for services that are being deployed in the network The result of provisioning is the allocation of bandwidth among all classes in times of congestion

Services are implemented by defining per-hop behavior (PHB) properties PHBs are implemented by using the available QoS mechanisms in networks devices

Trang 38

A DS domain consists of DS boundary nodes and DS interior nodes DS

boundary nodes interconnect the DS domain to other DS or non-DS-capable domains While DS interior nodes only connect to other DS interior or boundary nodes within the same DS domain Both DS boundary nodes and interior nodes

must be able to apply the appropriate PHB to packets based on the DS code

point; otherwise unpredictable behaviour may result

DS boundary nodes act both as a DS ingress node and as a DS egress node for

traffic traversing the network in different directions Traffic enters a DS domain at

a DS ingress node and leaves a DS domain at a DS egress node A DS ingress node is responsible for ensuring that the traffic entering the DS domain conforms

to any Traffic Conditioning Agreement (TCA) between it and the other domain

to which the ingress node is connected A DS egress node may perform traffic conditioning functions on traffic forwarded to a directly connected peering domain, depending on the details of the TCA between the two domains

A differentiated services region (DS Region) is a set of one or more contiguous

DS domains DS regions are capable of supporting differentiated services along paths that span the domains within the region

The DS domains in a DS region may support different PHB groups internally and different code point-PHB mappings However, to permit services that span across

the domains, the peering DS domains must each establish a peering Service

Level Agreement (SLA) that defines (either explicitly or implicitly) a TCA The

TCA specifies how transit traffic from one DS domain to another is conditioned at

Trang 39

code point mappings This eliminates the need for traffic conditioning between those DS domains

Trang 40

Traffic Terminology

application-to-application flow of packets which is identified by source address, source port, destination address, destination port and protocol id

• Traffic stream : an administratively significant set of one or more flows which traverse a path segment A traffic stream may consist of a set of active flows which are selected by a particular classifier.

• Traffic profile : a description of the temporal properties of a traffic stream such as average and peak rate and burst size.

The terminology used throughout the course includes the following:

n Flow (or microflow) is a sequence of packets identified by source and

destination IP addresses, protocol identifier (for example, TCP and UDP) and source and destination port numbers

n Traffic stream is a collection of flows with a common set of parameters (for

example, the same port number and the same source and destination network)

n Traffic profile specifies typical properties of a traffic stream (average rate and

burstiness) Provisioning should be performed based on traffic profiles and the importance of traffic streams

Định dạng
Số trang	92
Dung lượng	3,84 MB