s07 - ip qos - signaling mechnisms.pdf

7/29/2019 S07 - IP QoS - Signaling Mechnisms.pdf

1/34

7

Signaling Mechanism

Overview

The module describes RSVP as the signaling mechanism used in QoS enabled

networks. The module builds on knowledge about the IntServ model with the

addition of Common Open Policy Service (COPS) discussed in the introductory

module.

Objectives

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

n Describe Resource Reservation Protocol (RSVP).

n Configure RSVP.

n Describe and configure RSVP on shared media using Subnet Bandwidth

Management (SBM).

n Monitor and troubleshoot RSVP.


2/34

7-2 IP QoS Signaling Mechanism Copyright 2001, Cisco Systems, Inc.

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:

n Describe Resource Reservation Protocol (RSVP).

n Configure RSVP.

n Monitor and troubleshoot RSVP.


3/34

Copyright 2001, Cisco Systems, Inc. IP QoS Signaling Mechanism 7-3

2001, Cisco Systems, Inc. IP QoS Signaling Mechanism-5

Resource Reservation ProtocolResource Reservation Protocol

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

RSVP signals all network devices that a certainapplication 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, CB-WFQ) must be used to implement guarantees

according to RSVP reservations

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 videoconferencing 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 end-

node. In addition, RSVP does not provide any guarantees by itself. RSVP is the

protocol used to communicate QoS requirements between the end-node and the

layer-3 network, assessing the ability or inability of the network to support the

requested level of service.

RSVP is the signaling protocol underlying the IntServ QoS reference model.

Together with appropriate QoS-enforcing mechanisms in the network, such as

WFQ, it forms a foundation for implementation of IntServ-based services.


4/34



End-to-end RSVPEnd-to-end RSVP

All network devices have to be enabled forRSVP

Each network device determines whether ithas enough resources

request request request request

reservereservereservereserve

LocalAdmission

Control

Local

Admission

Control

LocalAdmission

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 todiscover 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.RSVP keeps track of the soft state of reservations in routers. This soft state

provides dynamic membership information, adapts to routing changes, and, as the

number of flows increases, enables dynamic changes in reservations to meet those

changing needs. RSVP reservations time out unless periodically refreshed by the

communication endpoint, usually at 30-second intervals.

The benefits of soft state behavior are:


5/34


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.


6/34



Pass-through RSVPPass-through RSVP

Part of the network may not support RSVP

Best-effort delivery is used in those parts

request

request

request

reservereserve

reserve

LocalAdmission

Control

LocalAdmission

Control

Best-effort

forwarding

RSVPnot

enabled

request request

reservereserve

LocalAdmission

Control

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.


7/34



Pass-through RSVPwith Class of ServicePass-through RSVPwith Class of Service

Part of the network may not support RSVP

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

Make sure the core provides guarantees tothe RSVP class

request

request

request

reservereserve

reserve

LocalAdmission

Control

LocalAdmission

Control

RSVPnot

enabled

request request

reservereserve

Mark RSVP flowwith DSCP

LocalAdmission

Control

Class-based

guarantee

Another option may be to apply class-of-service based delivery on a non-RSVP-

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

to the non-RSVP-enabled part. The core network can then be engineered 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 andmarked, 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.


8/34



RSVP ApplicationsRSVP Applications

RSVP is used for applications wherebandwidth 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:

n Data traffic seldom needs reserved bandwidth because internetworks provide

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.

n Real-time traffic (that is, voice or video information) experiences problems

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 well-

known examples include Cisco IP telephones, Microsoft NetMeeting, and MPLS

Traffic Engineering.


9/34



Configuring Simple RSVPConfiguring Simple RSVP

ip rsvp bandwidth [total-BW[per-flow-BW]]ip rsvp bandwidth [total-BW[per-flow-BW]]

Router(config-if)#

Set the amount of reservable bandwidth (total-BW) and themaximum per-flow reservable bandwidth (per-flow-BW) in kbps

Both default to 75% of the configured bandwidth

Total reservable bandwidth cannot exceed 75% of the

configured bandwidth

bandwidth bandwidthbandwidth 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 bandwidthcommand 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.


10/34



Configuring Proxy RSVPConfiguring Proxy RSVP

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

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{ f f | s e | wf } { r a t e | l oad} bw burst

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

next-hop-IP next-hop-intf{ f f | s e | wf } { r a t e | l oad} 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.


11/34



RSVP Admission ControlRSVP Admission Control

RSVP has two tasks:

Determine if there are enough available resources

Determine if the application in question is allowedaccess to these resources

RSVP-enabled devices keep track of existingreservations locally

RSVP-enabled devices can offload theauthorization part of admission control tocentral servers (COPS)

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

n The router needs to determine whether there are currently available resources,

which can be used to satisfy the reservation request.

n The router needs to be able to authorize an application to make the reservation

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 exceedsthe 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).


12/34



Common Open Policy ServiceCommon Open Policy Service

COPS allows a more centralized approach tobuilding RSVP enabled networks (more scalable)

COPS provides additional control over who canreserve what

request request request request

reservereservereservereserve

LocalAdmission

Control

Remote Admission

Control

LocalAdmission

Control

Policy Decision

Point (PDP)

request

reply

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 devicestherefore 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:

n The Policy Enforcement Point (PEP) is the device that enforces network

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

n The Policy Decision Point (PDP) is the device that stores policy information

and makes it available to the PEP devices.


13/34



Configuring RSVP for COPSConfiguring RSVP for COPS

Process

Locally?Reject?

Process

Message

Reject Message

Send an error

message to thesource

Yes Yes

No No

Local

Override?

YesDefault

LocalPolicy?

Yes

Process

Remotely?

Ask

PDP

No

No

Reject?

No

Yes

No

YesDefault

Reject?

NoNo

Yes

ip rsvp policy local acl

ip rsvp policy localip rsvp policy local local-override

DefaultRemote

Policy?

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:

n The router receives a PATH or RESV message and first tries to adjudicate it

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.

n For each message rejected by the operators, the router sends an error

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

database. If the message is not rejected, policy processing continues.

n If the local override flag is set for this entry, the message is immediately

accepted with the specified policy operators. Otherwise, policy processing

continues.


14/34



Configuring RSVP for COPS(cont.)

Configuring RSVP for COPS(cont.)

Process

Locally?Reject?

Process

Message

Reject Message

Send an error

message to thesource

Yes Yes

No No

Local

Override?

YesDefault

LocalPolicy?

Yes

Process

Remotely?

Ask

PDP

No

No

Reject?

No

Yes

No

YesDefault

Reject?

NoNo

Yes

ip rsvp policy cops acl servers

ip rsvp policy default-reject

DefaultRemote

Policy?

ip rsvp policy cops servers

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

follows:

n If the message does not match any ACL configured for local policy, the router

applies the default local policy. However, if no default local policy has been

configured, the message is directed toward remote policy processing.

n If the router has been configured with specific ACLs against specific policy

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.

n If the PDP specifies a reject decision, the message is discarded and an error

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.

n If the message does not match any ACL configured for specific PDPs, the

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.

n If the default policy decision for unmatched messages is to reject, the message

is immediately discarded and an ERROR message is sent to the sender

indicating this condition. Otherwise, the message is accepted and processed

using normal RSVP processing rules.

Whenever a request for adjudication (of any sort) is sent to a PDP, a 30-second

timer associated with the PATH or RESV message is started. If the timer runs out


15/34


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

request is given to the default policy.


16/34



RSVPExample

RSVPExample

interface Serial0/0

bandwidth 256

ip address 10.5.8.65 255.255.255.252encapsulation ppp

fair-queue 64 256 20ip rtp header-compression

ip rsvp bandwidth 160

interface Serial0/0

bandwidth 128ip address 10.10.3.33 255.255.255.252

encapsulation ppp

fair-queue 64 256 10ip rtp header-compression

ip rsvp bandwidth 80

The figure shows a basic example of RSVP configuration in Cisco IOS routers.

The two routers in the figure are both configured for RSVP, and both utilize WFQ

to guarantee bandwidth to RSVP flows in RSVP-reserved queues. Different

maximum reservable bandwidths are allocated, based on the real bandwidth of the

link.


17/34



RSVP with COPSExample

RSVP with COPSExample

interface Serial0/0bandwidth 2048

ip address 10.1.1.1 255.255.255.252encapsulation ppp

fair-queue 64 256 100

ip rsvp bandwidth 512!

ip rsvp policy cops 100 servers 10.100.1.1 10.101.1.1ip rsvp policy default-reject

ip rsvp policy cops minimal

ip rsvp policy cops timeout 600ip 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.


18/34



Monitoring and TroubleshootingRSVP


show ip rsvp installed [detail]show ip rsvp installed [detail]

Router#

Lists installed reservations per interface

Router#show ip rsvp installed

RSVP:Ethernet2/1

BPS To From Protoc DPort Sport Weight

Conversation

44K 145.20.0.202 145.10.0.201 UDP 1000 1000 0 264

44K 145.20.0.202 145.10.0.201 UDP 1001 1001 13 266

98K 145.20.0.202 145.10.0.201 UDP 1002 1002 6 265

1K 145.20.0.202 145.10.0.201 UDP 10 10 0 264

RSVP:Serial3/0 has no installed reservations

Router#show ip rsvp installed

RSVP:Ethernet2/1

BPS To From Protoc DPort Sport Weight

Conversation

44K 145.20.0.202 145.10.0.201 UDP 1000 1000 0 264

44K 145.20.0.202 145.10.0.201 UDP 1001 1001 13 266

98K 145.20.0.202 145.10.0.201 UDP 1002 1002 6 265

1K 145.20.0.202 145.10.0.201 UDP 10 10 0 264

RSVP:Serial3/0 has no installed reservations

The show ip rsvp installed command shows all active conversations over an

RSVP-enabled path, which has resource reservations installed. The actual

reserved bandwidth is shown, along with the session parameters (endpoints and

applications).


19/34





show ip rsvp installed [detail] [interface]show ip rsvp installed [detail] [interface]

Router#

Router#show ip rsvp installed detail

RSVP:Ethernet2/1 has the following installed reservationsRSVP Reservation. Destination is 145.20.0.202, Source is 145.10.0.201,

Protocol is UDP, Destination port is 1000, Source port is 1000Reserved bandwidth:44K bits/sec, Maximum burst:1K bytes, Peak rate: 44K bits/sec

QoS provider for this flow:WFQ. Conversation number:264. Weight:0 (PQ)

Conversation supports 1 reservationsData given reserved service:316 packets (15800 bytes)

Data given best-effort service:0 packets (0 bytes)Reserved traffic classified for 104 seconds

Long-term average bitrate (bits/sec):1212 reserved, 0M best-effort

RSVP Reservation. Destination is 145.20.0.202, Source is 145.10.0.201,Protocol is UDP, Destination port is 1001, Source port is 1001

Reserved bandwidth:44K bits/sec, Maximum burst:3K bytes, Peak rate: 44K bits/secQoS provider for this flow:WFQ. Conversation number:266. Weight:13


Data given best-effort service:0 packets (0 bytes)

Reserved traffic classified for 107 secondsLong-term average bitrate (bits/sec):33 reserved, 0M best-effort

...

Router#show ip rsvp installed detailRSVP:Ethernet2/1 has the following installed reservations

RSVP Reservation. Destination is 145.20.0.202, Source is 145.10.0.201,


QoS provider for this flow:WFQ. Conversation number:264. Weight:0 (PQ)Conversation supports 1 reservations

Data given reserved service:316 packets (15800 bytes)Data given best-effort service:0 packets (0 bytes)

Reserved traffic classified for 104 seconds

Long-term average bitrate (bits/sec):1212 reserved, 0M best-effortRSVP Reservation. Destination is 145.20.0.202, Source is 145.10.0.201,


QoS provider for this flow:WFQ. Conversation number:266. Weight:13


Data given best-effort service:0 packets (0 bytes)Reserved traffic classified for 107 seconds

Long-term average bitrate (bits/sec):33 reserved, 0M best-effort...

The show ip rsvp installed detail command shows detailed information about

active conversations currently installed in the RSVP reservation table. Detailed

timing and accounting for every conversation is displayed, together with the QoS

mechanism used to provide service guarantees.


20/34





show ip rsvp reservation [detail]show ip rsvp reservation [detail]

Router(config)#

List RSVP reservations

show ip rsvp request [detail]show ip rsvp request [detail]

Router(config)#

List pending RSVP requests

The show ip rsvp reservation command lists all existing RSVP reservations over

an interface. The show ip rsvp request command shows all pending RSVP

requests that have no fixed reservation in place.


21/34



Monitoring and TroubleshootingRSVP with COPS


show ip rsvp policy [{cops | local} [acl]]show ip rsvp policy [{cops | local} [acl]]

Router#

Router#show ip rsvp policy cops

COPS/RSVP settings:Generate reports for all decisions

Do not query PDP for error messages

COPS/RSVP entry. ACLs: 100PDPs: 10.100.1.1 10.101.1.1

Current state: ConnectedCurrently connected to PDP 10.100.1.1, port 0

COPS/RSVP entry. ACLs: 101PDPs: 10.102.1.1

Current state: In reconnect loop waitReconnect timer is 960 seconds

Router#show ip rsvp policy cops

COPS/RSVP settings:Generate reports for all decisions

Do not query PDP for error messagesCOPS/RSVP entry. ACLs: 100

PDPs: 10.100.1.1 10.101.1.1Current state: Connected

Currently connected to PDP 10.100.1.1, port 0

COPS/RSVP entry. ACLs: 101

PDPs: 10.102.1.1Current state: In reconnect loop wait

Reconnect timer is 960 seconds

Lists all policies

The show ip rsvp policy command shows the policy settings, whether the policy

is locally defined or policy decisions are offloaded to the COPS server. The output

shows associations between flow specifications and associated COPS servers,

which perform admission control for those flows. This command is used to verify

connectivity to COPS services and the associations between the local device and a

COPS server.


22/34





show cops serversshow cops servers

Router#

Router#show cops serversCOPS SERVER: Address: 10.100.1.1. Port: 3288. State: 0. Keepalive: 120 sec

Number of clients: 1. Number of sessions: 1.

COPS CLIENT: Client type: 1. State: 0.

Router#show cops serversCOPS SERVER: Address: 10.100.1.1. Port: 3288. State: 0. Keepalive: 120 sec

Number of clients: 1. Number of sessions: 1.

COPS CLIENT: Client type: 1. State: 0.

Lists all COPS servers

The show cops servers command displays the state of all configured COPS

servers.


23/34


Summary

n RSVP enables end-stations to signal QoS requirements to the network.

n RSVP does not provide any guarantees; router QoS mechanisms do.

n RSVP does not necessarily require an end-to-end RSVP-aware path.

n COPS provides scalable QoS provisioning.

Lesson Review

1. What is RSVP used for?

2. Does RSVP provide QoS guarantees?

3. What QoS mechanism should be used to provide QoS guarantees to RSVP

reservations?

4. What are the benefits of using COPS with RSVP?


24/34


Subnet Bandwidth Management

Overview

This section describes a mechanism that is used on shared media where more

complex reservation is required. SBM protocol is used between RSVP devices

reachable over the same subnet.

Objectives

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

n Describe Subnet Bandwidth Management (SBM).

n Configure SBM.

n Monitor and troubleshoot RSVP with SBM.


25/34



Subnet Bandwidth ManagementSubnet Bandwidth Management

RSVP manages unidirectional reservation ofresources

RSVP on shared media can result inoversubscription

SBM is an add-on to RSVP on shared mediato prevent oversubscription

RSVP is used to manage reservation of resources unidirectionally, between Layer-

3 hops. On a shared medium, many Layer-3 hops can be active between many

routers on the shared segment. The shared medium is shared between all routers,

therefore the routers need to keep track about all routers usage of the shared

medium, in order to maintain a consistent picture of available bandwidth on that

medium. If routers were independently reserving bandwidth over a shared medium,

oversubscription would occur if each router had full access to the medium

bandwidth.

Subnet Bandwidth Management (SBM) is an add-on to the RSVP protocol, which

provides arbitration of bandwidth allocation on a shared medium to prevent RSVP-

caused oversubscription. SBM specifies a signaling method and protocol for LAN-

based admission control for RSVP flows. SBM allows RSVP-enabled routers and

Layer 2 and Layer 3 devices to support reservation of LAN resources for RSVP-

enabled data flows. The SBM signaling method is similar to that of RSVP itself.


26/34



Without SBMWithout SBM

Both routers are within the 75% reservable limit

Total reserved bandwidth is 13 Mbps (above Ethernet bandwidth)

Ethernet should be treated carefully because it is impossible toachieve 100% utilization (collisions; depending on implementation)

Ethernet

Ethernet bandwidth 10Mbps

7.5 Mbps is reservable

Reserve6

Mbps

Reserve7Mbps

Reserve 6 Mbps

Reserve 7 Mbps

0 Mbps booked7.5 Mbps free



7 Mbps booked512 kbps free

The figure shows a possible scenario of RSVP oversubscription on a shared

segment. Both right-hand routers think of the Ethernet segment as a link with a

bandwidth of 10 Mbps. Based on the 75% rule, by default 7.5 Mbps of that

bandwidth is reservable. The upper router reserves 6 Mbps of the reservable

bandwidth, and the bottom router reserves 7 Mbps of the reservable bandwidth.

Obviously, the combined reserved bandwidth exceeds the Ethernet media

bandwidth and results in an unwanted oversubscription.


27/34



With SBMWith SBM

Reserve 6 Mbps

Reserve 7 Mbps




7 Mbps booked512 kbps free

Reserve 6 Mbps Reserve6M

bps

Reserve6Mbps

One of the routers on thesegment is elected to be the

Designated SubnetBandwidth Manager (DSBM)

The shared media is

effectively transformed into astar of point-to-point links

Error



SBMs solution to the problem is to introduce a Designated Subnet Bandwidth

Manager (DSBM) router, which tracks all reservations over a shared segment.

The DSBM is one of the existing subnet routers, designated to be the DSBM via

an election process on the subnet. When a DSBM is used, the shared medium is

effectively transformed into a virtual mesh of point-to-point links.

When a DSBM client sends or forwards an RSVP PATH message over an

interface attached to a managed segment, it sends the PATH message to the

segments DSBM instead of to the RSVP session destination address, as is done inconventional RSVP processing. As part of its message processing procedure, the

DSBM builds and maintains a PATH state for the session and notes the previous

Layer 2/Layer 3 hop from which it received the PATH message. After processing

the PATH message, the DSBM forwards it toward its destination address.

n The DSBM receives the RSVP reservation request (RSVP RESV) message

and processes it in a manner similar to the way RSVP itself handles

reservation request processing, basing the outcome on available bandwidth.

The procedure is as follows:

n If it cannot grant the request because of lack of resources, the DSBM returns

a RESVERR message to the requester.n If sufficient resources are available and the DSBM can grant the reservation

request, it forwards the RESV message toward the PHOP(s) using the local

PATH state for the session.


28/34



DSBM ElectionDSBM Election

DSBM is elected based on the DSBM priority

Each DSBM candidate advertises its priorityin the range from 64 to 128

The candidate with the highest priority iselected to be the DSBM

RSVP enabled devices can participate inSubnet Bandwidth Management withoutbeing DSBM candidates

On a LAN segment configured for SBM, a DSBM is elected based on each

routers DSBM-candidate priority. All RSVP messages of participating routers are

sent to the DSBM to adjudicate the reservation requests. Such a LAN segment is

called a managed segment in SBM terms.

Of all SBM-enabled routers on a segment, some or all routers are DSBM

candidates; that is, not all routers need to be configured as DSBM candidates to

perform SBM-assisted RSVP. A DSBM is chosen among the candidates based on

the configured DSBM priority, which ranges from 64 to 128, the latter being thehighest priority.


29/34



Configuring DSBMConfiguring DSBM

ip rsvp dsbm candidatepriorityip rsvp dsbm candidatepriority

Router(config-if)#

Configures the router to bid in the election of the DSBM Default priority is 64

ip rsvp dsbm non-resv-send-limit {burst | max-unit | min-

unit | peak | rate} value

ip rsvp dsbm non-resv-send-limit {burst | max-unit | min-

unit | peak | rate} value

Router(config)#

The NonResvSendLimit object specifies how much traffic can be

sent onto a managed segment without a valid RSVP reservation

All values are unlimited by default

The ip rsvp dsbm candidate interface command specifies this router as a

DSBM candidate on the attached LAN network. A priority used in the DSBM

election process is assigned, the default being the lowest priority of 64.

The ip rsvp dsbm non-resv-send-limit command limits the amount of traffic,

which can be sent to a managed segment without an RSVP reservation. By

default, any amount of traffic can be sent to the segment. This command should be

used in a network, where RSVP is predominantly used for signaling to allow some

non-RSVP traffic to transit shared LAN segments.


30/34



SBMExample

SBMExample

interface Ethernet0/0

ip address 10.1.1.1 255.255.255.0ip rsvp bandwidth 7500 7500

ip rsvp dsbm candidate 100

ip rsvp dsbm non-resv-send-limit rate 100

ip rsvp dsbm non-resv-send-limit burst 1000

ip rsvp dsbm non-resv-send-limit peak 100

!

interface Ethernet0/0

ip address 10.1.1.1 255.255.255.0ip rsvp bandwidth 7500 7500

ip rsvp dsbm candidate 100

ip rsvp dsbm non-resv-send-limit rate 100

ip rsvp dsbm non-resv-send-limit burst 1000

ip rsvp dsbm non-resv-send-limit peak 100

!

The figure shows an interface configuration example, where SBM is used to signal

RSVP across a shared LAN segment. The local router is configured as a DSBM

candidate, and RSVP with SBM is enabled using the ip rsvp bandwidth

command. In this example, non-reserved traffic is limited to a mere 100 Kbps, with

one-megabyte bursts allowed. Such an example configuration could be used in a

fully RSVP-enabled network, where some bandwidth needs to be provisioned for

network control (routing protocols, time management, and so forth).


31/34



Monitoring and TroubleshootingSBM

Monitoring and TroubleshootingSBM

show ip sbm [detail]show ip sbm [detail]

Router#

Lists interfaces where SBM is active The detailed option displays detailed information about local

configuration and the DSBM configuration

Router#show ip rsvp sbm

Interface DSBM Addr DSBM Priority DSBM Candidate My PriorityEt0/0 10.1.1.1 100 yes 100

Et0/1 10.1.2.1 100 yes 100Router#show ip rsvp sbm detail

Interface:Ethernet0/0

Local Configuration Current DSBMIP Address:10.1.1.1 IP Address:10.1.1.1

DSBM candidate:yes I Am DSBM:yesPriority:100 Priority:100

Non Resv Send Limit Non Resv Send LimitRate:100 Kbytes/sec Rate:100 Kbytes/sec

Burst:1000 Kbytes Burst:1000 Kbytes

Peak:100 Kbytes/sec Peak:100 Kbytes/secMin Unit:unlimited Min Unit:unlimited

Max Unit:unlimited Max Unit:unlimited

Router#show ip rsvp sbmInterface DSBM Addr DSBM Priority DSBM Candidate My Priority

Et0/0 10.1.1.1 100 yes 100Et0/1 10.1.2.1 100 yes 100

Router#show ip rsvp sbm detail

Interface:Ethernet0/0Local Configuration Current DSBM

IP Address:10.1.1.1 IP Address:10.1.1.1DSBM candidate:yes I Am DSBM:yes

Priority:100 Priority:100

Non Resv Send Limit Non Resv Send LimitRate:100 Kbytes/sec Rate:100 Kbytes/sec

Burst:1000 Kbytes Burst:1000 KbytesPeak:100 Kbytes/sec Peak:100 Kbytes/sec

Min Unit:unlimited Min Unit:unlimitedMax Unit:unlimited Max Unit:unlimited

The show ip sbm command shows per-interface SBM parameters, displaying

other SBM-enabled routers on the attached segment. The show ip sbm detail

command also shows the non-reserved sending limits of discovered neighbors.

In this output, all routers on the segment have the same DSBM priority. In that

case, the tiebreaker is a routers IP address on that segment, and the router with

the highest IP address will win the election.


32/34


Summary

n SBM enables RSVP to run over shared LAN segments.

n DSBM routers provide shared LAN adjudication of RSVP-reservations.

n SBM can limit the amount of non-RSVP traffic sent into a network.

Lesson Review

1. What is the purpose of Subnet Bandwidth Management?

2. How do routers on a common subnet communicate reservation requests?

3. What is a DSBM?

4. How do routers elect a DSBM?


33/34


Summary

n RSVP enables end-stations to signal QoS requirements to the network

n RSVP does not provide any guarantees; router QoS mechanisms do.

n SBM enables RSVP to run over shared LAN segments.


34/34

Review Questions and Answers

Resource Reservation Protocol (RSVP)

Question: What is RSVP used for?

Answer: RSVP is used by applications to signal their QoS requirements to the

network and to set up reservations along the application path.Question: Does RSVP provide QoS guarantees?

Answer: No, RSVP is only used for signaling. Per-hop mechanisms, such as

WFQ, are used to guarantee a service level to a RSVP-enabled application.

Question: What QoS mechanism should be used to provide QoS guarantees to

RSVP reservations?

Answer: Usually, WFQ and CB-WFQ are used to provide per-hop guarantees.

Question: What are the benefits of using COPS with RSVP?

Answer: Using COPS-compliant policy management software enables scaling of

RSVP-enabled networks by offloading part of the admission control functions to

a centralized database.

Subnet Bandwidth Management

Question: What is the purpose of Subnet Bandwidth Management?

Answer: The purpose of SBM is to prevent oversubscription of a shared segment

by introducing an arbiter, which keeps tracks of all reservations over a shared

segment.

Question: How do routers on a common subnet communicate reservationrequests?

Answer: Routers communicate reservation requests by forwarding all RSVP

messages to the arbiter (the DSBM).

Question: What is a DSBM?

Answer: The DSBM (Designated Subnet Bandwidth Manager) is an elected layer-

3 device on a shared segment, which keeps tracks of all reservations.

Question: How do routers elect a DSBM?

Answer: Routers elect a DSBM with a priority-based election system. Router IP

address is the final tiebreaker.

s07 - ip qos - signaling mechnisms.pdf

Documents