s07 - ip qos - signaling mechnisms

IP QoS Signaling Mechanism-5Resource Reservation Protocol Resource Reservation Protocol • RSVP is a protocol used to reserve resources in a path between a source and a destination • RSVP

Trang 1

Objectives

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

Trang 2

Resource Reservation Protocol (RSVP)

Overview

The section introduces Resource Reservation Protocol (RSVP) as the signaling mechanism in QoS-enabled networks using the Integrated Services model

Objectives

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

Trang 3

Resource Reservation Protocol

• RSVP is a protocol used to reserve resources in a path between a source and a destination

• RSVP signals all network devices that a certain application needs certain QoS guarantees

• RSVP requires applications to initiate the request

• RSVP by itself does not provide any guarantees

• An RSVP-interoperable QoS mechanism (WFQ, WFQ) must be used to implement guarantees according to RSVP reservations

CB-RSVP is an Internet Engineering Task Force (IETF) signaling protocol, used to reserve bandwidth in a path between a source and a destination In RSVP, the end-node (the application node) station reserves bandwidth for a flow along its path

to a destination in a network The user can supply the information about how much capacity to reserve

RSVP mechanisms enable real-time traffic to reserve bandwidth necessary for consistent latency A video conferencing application can use settings in the router

to propagate a request for a path with the required bandwidth and delay for video conferencing destinations RSVP then signals all network devices along the path, and confirms or rejects the reservation RSVP will check and repeat reservations

at regular intervals When RSVP is used, the routers sort and prioritize packets much as a statistical time-division multiplexer would sort and prioritize several signal sources that share a single channel

RSVP requires RSVP-aware applications, as signaling is performed by the node In addition, RSVP does not provide any guarantees by itself RSVP is the

Trang 4

reserve reserve

Local Admission Control

If end-to-end RSVP is desired in a network, all devices in the reservation path must be RSVP-enabled When a device receives an RSVP message, it determines whether it has enough resources to satisfy the reservation request at the local level

There are two main RSVP messages used for signaling When a reservation is needed, the sending client sends an RSVP PATH message into the network requesting a specific bandwidth to a specific destination (or multicast address, in the case of IP multicast application) The purpose of the PATH message is to discover all RSVP-enabled routers along the path from the sender to the receiver, and to create initial reservations The PATH message is forwarded along the flow path and every intermediate RSVP-capable router adds its identification to the PATH message When the receiving end-node receives the PATH message, it confirms the reservation by replying with an RSVP RESV message The RESV message is forwarded back upstream towards the initial sender using the list of RSVP-enabled routers generated by the PATH message If the RESV message successfully arrives at the initial sender, each hop in the end-to-end connection has reserved the appropriate resources and an end-to-end reservation is established If the appropriate resources are not available, the reservation is refused and the application must default to traditional, best effort communications

Trang 5

n Connectionless behavior − routers automatically adapt to route changes

n Timeliness − state changes propagate immediately, but only as far as needed

n Robustness − the method is self-correcting, because incorrect reservations will always time-out even in the most unexpected situations

n Flexibility − provides easy dynamic reservation changes

The cost of this approach is that it requires ongoing refresh processing for established states by the endpoints

Trang 6

Pass-through RSVP

• Part of the network may not support RSVP

• Best-effort delivery is used in those parts

request

reserve reserve

reserve

Best-effort forwarding

RSVP not enabled

request request

reserve reserve

When a part of the network does not support RSVP, that is, when the RSVP messages are not processed by every intermediate hop between the two application endpoints, some other mechanism may be employed to try to meet the application requirements in the non-RSVP-enabled part of the network One such possibility may be to perform only best-effort delivery between RSVP-enabled networks using an undersubscribed network in between The PATH messages discover all RSVP-aware routers, and are forwarded as plain IP packets on non-RSVP-enabled hops The RESV messages are then interpreted only by the RSVP-aware hops, discovered via the PATH message

Trang 7

Pass-through RSVP with Class of Service

• Part of the network may not support RSVP

• Mark RSVP flows with a Class-of-service marker (e.g IP precedence or DSCP)

• Make sure the core provides guarantees to the RSVP class

request

reserve reserve

reserve

RSVP not enabled

request request

reserve reserve

Mark RSVP flow with DSCP

Class-based guarantee

Another option may be to apply class-of-service based delivery on a enabled part of the network In that case, RSVP-based application traffic is marked with appropriate class markers (IP precedence or DSCP bits) at the entry

non-RSVP-to the non-RSVP-enabled part The core network can then be engineered non-RSVP-to provide special service to the RSVP class, using, for example, WFQ and WRED

IP precedence and DSCP are packet markers, located in the ToS byte of the IP header, which identify traffic classes on each hop in the network IP precedence

or DSCP bits are usually set at the network edge, where traffic is classified and marked, and the markers used to identify traffic classes in downstream network devices Each device along the path may apply appropriate QoS mechanisms based on the packet marker, resulting in differentiated per-hop behaviour (PHB) for each class of traffic The DiffServ model defines several standard PHBs, based on marking traffic with the DSCP header bits

Trang 8

RSVP Applications

• RSVP is used for applications where bandwidth and delay related guarantees are necessary

• Typical applications are:

– Voice over IP (Cisco phones, Microsoft NetMeeting, )

– MPLS Traffic Engineering

RSVP allows end systems to request QoS guarantees from the network The need for network resource reservations differs for data traffic versus real-time traffic,

as described in the following paragraphs:

datagram services for data traffic This asynchronous packet switching may not need guarantees of service quality End-to-end controls between data traffic senders and receivers help ensure adequate transmission of bursts of information

when using datagram services Because real-time traffic sends an almost constant flow of information, the network “pipes” must be consistent Some guarantee must be provided that service between real-time hosts will not vary Routers operating on a first-in, first-out (FIFO) basis risk unrecoverable disruption of the real-time information that is being sent

Many network-aware applications today use RSVP for signaling Some known examples include Cisco IP telephones, Microsoft NetMeeting, and MPLS Traffic Engineering

Trang 9

• Both default to 75% of the configured bandwidth

• Total reservable bandwidth cannot exceed 75% of the configured bandwidth

bandwidth bandwidth

Router(config-if)#

• Set the interface bandwidth in kbps

• This value should reflect the real bandwidth of the link

Basic RSVP is configured by two interface commands The ip rsvp bandwidth

command sets the maximum total amount of reservable bandwidth on an interface

By default, it is configured to 75% of the configured bandwidth, which is also its maximum allowed value A per-flow reservable bandwidth can also be configured, setting the maximum bandwidth a single flow can reserve over this interface By default, it is also set to 75% of the configured bandwidth

Note RSVP cannot be configured with VIP-distributed Cisco Express Forwarding

(dCEF)

The bandwidth interface command sets the interface bandwidth and is used by

routing protocols (to calculate costs) and by a variety of QoS mechanisms With RSVP, this is used as the configured bandwidth parameter, referenced by the limits

in the ip rsvp bandwidth command

Trang 10

Configuring Proxy RSVP

ip rsvp sender sessionIP senderIP protocol dport sport srchop

-IP src -intf bandwidth burst

ip rsvp sender session -IP sender -IP protocol dport sport

src-hop-IP src-intf bandwidth burst

Router(config)#

• Simulates a host sending a PATH message

• Generates a PATH message on behalf of a host or an application

ip rsvp reservation session-IP sender-IP protocol dport sport

next -hop-IP next -hop-intf {ff | se | wf} {rate | load} bw burst

ip rsvp reservation session -IP sender -IP protocol dport sport

next-hop -IP next-hop -intf {ff | se | wf} {rate | load} bw burst

Router(config)#

• Simulates a host sending a RESV message

• Generates a RESV message on behalf of a host or an application

RSVP typically requires both host and network implementations, although Cisco IOS software provides an RSVP command line interface that allows you to statically set up RSVP reservations without host involvement

Use the ip rsvp sender command to make the router simulate that it is receiving

RSVP PATH messages from an upstream host The command can be used to proxy RSVP PATH messages for non-RSVP-capable senders By including a local (loopback) previous hop address and previous hop interface, you can also use this command to proxy RSVP for the router you are configuring

To enable a router to simulate receiving and forwarding Resource Reservation

Protocol (RSVP) RESV messages, use the ip rsvp reservation global configuration command To disable this feature, use the no form of this command

Use this command to make the router simulate receiving RSVP RESV messages from a downstream host This command can be used to proxy RSVP RESV messages for non-RSVP-capable receivers By giving a local (loopback) next hop address and next hop interface, you can also use this command to proxy RSVP for the router you are configuring Several different reservation types can be specified For detailed reservation settings, consult the Cisco IOS documentation

Trang 11

RSVP Admission Control

• RSVP has two tasks:

– Determine if there are enough available resources

– Determine if the application in question is allowed access to these resources

• RSVP-enabled devices keep track of existing reservations locally

• RSVP-enabled devices can offload the authorization part of admission control to central servers (COPS)

A RSVP-enabled router therefore needs to perform two tasks:

which can be used to satisfy the reservation request

request (admission control)

The first task can be performed by keeping track of existing reservations, and of total reservable capacity locally on each device If a reservation request exceeds the locally available reservable resources, the reservation request is denied

Authorization of reservations could be performed locally, but such an approach would not scale to more than a few devices Fortunately, there is a standardized, centralized framework for policy networking, which includes authorization within admission control This framework is based on a set of services and protocols called the Common Open Policy Service (COPS)

Trang 12

Common Open Policy Service

• COPS allows a more centralized approach to building RSVP enabled networks (more scalable)

• COPS provides additional control over who can reserve what

request request request request

reserve reserve

Remote Admission Control

Policy Decision Point (PDP)

Policy Enforcement Point (PEP)

Common Open Policy Service (COPS) is an open framework designed for management in policy networking COPS provides a service to network devices and implements management protocols, which enable scalable provisioning of Quality of Service policies in a network

COPS is designed so that it provides a centrally managed, but distributed system for configuring network devices according to centralized policy decisions In the case of RSVP, COPS provides centralized databases, which network devices query for reservation/admission control information RSVP-enabled devices therefore need no locally stored configuration, but receive this information in real-time from the appropriate COPS server COPS, therefore, scales QoS

provisioning, and enables a device-independent QoS policy throughout the network COPS defines the following types of policy services:

policy (a router performing RSVP admission control, a firewall filtering traffic)

and makes it available to the PEP devices

Trang 13

Configuring RSVP for COPS

Process Locally? Reject?

Process Message

Reject Message Send an error message to the source

Local Override?

Yes Default

Local Policy?

Yes

Process Remotely?

Ask PDP No

The figure shows the flowchart used to consult either the local policy settings, or the COPS service Both the local policy and the COPS service can be used simultaneously on the same router Individual COPS commands are also presented

in the flowchart, next to the functions they enable

The admission process in policy networking proceeds as follows for locally processed messages:

locally (that is, without referring to the policy server) If the router has been configured to adjudicate specific access control lists (ACLs) locally and the message matches one of those lists, the policy module of the router applies the operators with which it had been configured Otherwise, policy processing continues

message to the sender and removes the PATH or RESV message from the

Trang 14

(cont.)

Process Locally? Reject?

Process Message

Reject Message Send an error message to the source

Local Override?

Yes Default

Local Policy?

Yes

Process Remotely?

Ask PDP No

ip rsvp policy cops servers

If policy decisions are offloaded to a policy server, policy processing continues as follows:

applies the default local policy However, if no default local policy has been configured, the message is directed toward remote policy processing

servers (more specifically, PDPs), and the message matches one of these ACLs, the router sends that message to the specific PDP for adjudication Otherwise, policy processing continues

message is sent back to the sender, indicating this condition If the PDP specifies an “accept” decision, the message is accepted and processed using normal RSVP processing rules

router applies the default PDP configuration If a default COPS configuration has been entered, policy processing continues Otherwise, the message is considered to be unmatched

Trang 15

before the PDP replies to the request, the PDP is assumed to be down and the request is given to the default policy

Trang 16

RSVP Example

interface Serial0/0 bandwidth 256

ip address 10.5.8.65 255.255.255.252 encapsulation ppp

fair-queue 64 256 20

ip rtp header-compression

ip rsvp bandwidth 160

interface Serial0/0 bandwidth 128

Trang 17

ip rsvp policy cops minimal

ip rsvp policy cops timeout 600

ip rsvp policy cops report-all

! access-list 100 permit udp any any

COPS (PEP)

COPS (PDP)

This figure shows a COPS-enabled RSVP configuration The RSVP interface

configuration does not change, and COPS parameters are defined with the ip rsvp

policy commands In this example, the COPS PDP adjudicates all UDP traffic

reservations

Định dạng
Số trang	34
Dung lượng	1,47 MB