S07 - IP QoS - Signaling Mechnisms PDF

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 n n
Describe Resource Reservation Protocol (RSVP). Configure RSVP. Describe and configure RSVP on shared media using Subnet Bandwidth Management (SBM). Monitor and troubleshoot RSVP.
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 n n
Describe Resource Reservation Protocol (RSVP). Configure RSVP. Monitor and troubleshoot RSVP.
7-2
IP QoS Signaling Mechanism
Copyright 2001, Cisco Systems, Inc.
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, CBWFQ) must be used to implement guarantees according to RSVP reservations
2001, Cisco Systems, Inc.
IP QoS Signaling Mechanism-5
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 endnode. 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.
7-3
End-to-end RSVP
Local Admission Control request request Local Admission Control request Local Admission Control request
reserve
reserve
reserve
reserve
All network devices have to be enabled for RSVP Each network device determines whether it has enough resources
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. 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:
7-4
n n n
Connectionless behavior routers automatically adapt to route changes. Timeliness state changes propagate immediately, but only as far as needed. Robustness the method is self-correcting, because incorrect reservations will always time-out even in the most unexpected situations. Flexibility provides easy dynamic reservation changes.
The cost of this approach is that it requires ongoing refresh processing for established states by the endpoints.
7-5
Pass-through RSVP
Local Admission Control request request Local Admission Control request RSVP not enabled reserve request request Local Admission Control
reserve
reserve
reserve
reserve
Best-effort forwarding
Part of the network may not support RSVP Best-effort delivery is used in those parts
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 nonRSVP-enabled hops. The RESV messages are then interpreted only by the RSVPaware hops, discovered via the PATH message.
7-6
Pass-through RSVP with Class of Service

Local Admission Control request request Local Admission Control request RSVP not enabled reserve request request Local Admission Control
reserve
reserve
reserve
reserve
Mark RSVP flow with DSCP
Class-based guarantee
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
2001, Cisco Systems, Inc. IP QoS Signaling Mechanism-8
Another option may be to apply class-of-service based delivery on a non-RSVPenabled 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 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.
7-7
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:
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. 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 wellknown examples include Cisco IP telephones, Microsoft NetMeeting, and MPLS Traffic Engineering.
7-8
Configuring Simple RSVP

Router(config-if)#
ip rsvp rsvp bandwidth bandwidth [ total-BW [per-flow-BW]]
Set the amount of reservable bandwidth ( total-BW) and the maximum 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
Router(config-if)#
bandwidth bandwidth
Set the interface bandwidth in kbps This value should reflect the real bandwidth of the link
IP QoS Signaling Mechanism -10
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.
7-9
Configuring Proxy RSVP

Router(config)# ip ip rsvp rsvp sender sender session-IP sender-IP sender-IP protocol protocol dport dport sport sport src-hopsrc-hopIP IP src-intf bandwidth burst
Simulates a host sending a PATH message Generates a PATH message on behalf of a host or an application
Router(config)# ip ip rsvp reservation reservation session-IP sender-IP protocol dport sport next-hop-IP next-hop-intf {ff {ff | se | wf} {rate | load} bw burst
Simulates a host sending a RESV message Generates a RESV message on behalf of a host or an application
2001, Cisco Systems, Inc. IP QoS Signaling Mechanism -11
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.
7-10
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:

n
The router needs to determine whether there are currently available resources, which can be used to satisfy the reservation request. 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 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).
7-11
Common Open Policy Service

Local Admission Control request Remote Admission Control Policy Enforcement Point (PEP) request Local Admission Control request
request
reserve
reserve
reserve reply Policy Decision Point (PDP)
reserve
COPS allows a more centralized approach to building RSVP enabled networks (more scalable) COPS provides additional control over who can reserve what
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 realtime 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). The Policy Decision Point (PDP) is the device that stores policy information and makes it available to the PEP devices.
request
7-12
Configuring RSVP for COPS

ip rsvp policy local acl Process Locally? No Yes Reject? Yes Reject Message Send an error message to the source
ip rsvp policy local
No ip rsvp policy local local-override
Default Local Policy? No
Yes
Local Override? No
Yes
Process Remotely? No
Ask PDP
Reject?
Yes
No Process Message Default Reject? No

Default Remote Policy? No

Yes
Yes
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. 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. If the local override flag is set for this entry, the message is immediately accepted with the specified policy operators. Otherwise, policy processing continues.
7-13
Configuring RSVP for COPS (cont.)

Process Locally? No Yes Reject? Yes Reject Message Send an error message to the source
No
Default Local Policy? No ip rsvp policy cops acl servers Process Remotely? No ip rsvp policy cops servers Default Remote Policy? No
Yes
Local Override? No
Yes
Ask PDP
Reject?
Yes
No Process Message Default Reject? No Yes ip rsvp policy default-reject
Yes
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. 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. 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. 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. 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
7-14
before the PDP replies to the request, the PDP is assumed to be down and the request is given to the default policy.
7-15
RSVP Example
interface Serial0/0 bandwidth 128 ip address 10.10.3.33 255.255.255.252 encapsulation ppp fair-queue 64 256 10 ip rtp header-compression ip rsvp bandwidth 80
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
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.
7-16
RSVP with COPS Example

COPS (PEP) COPS (PDP)
interface Serial0/0 bandwidth 2048 ip address 10.1.1.1 255.255.255.252 encapsulation ppp fair-queue 64 256 100 ip rsvp bandwidth 512 ! ip rsvp policy cops 100 servers 10.100.1.1 10.101.1.1 ip rsvp policy default-reject ip rsvp policy cops minimal ip rsvp policy cops timeout 600 ip rsvp policy cops report-all ! access-list 100 permit udp any any
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.
7-17
Monitoring and Troubleshooting RSVP

Router#
show ip rsvp installed [detail]
Lists installed reservations per interface

Router#show Router#show ip ip rsvp rsvp installed installed RSVP:Ethernet2/1 RSVP:Ethernet2/1 BPS To From Protoc BPS To From Protoc Conversation Conversation 44K 145.20.0.202 145.10.0.201 UDP 44K 145.20.0.202 145.10.0.201 44K 145.20.0.202 145.10.0.201 UDP 44K 145.20.0.202 145.10.0.201 98K 145.20.0.202 145.10.0.201 UDP 98K 145.20.0.202 145.10.0.201 UDP 1K 145.20.0.202 145.10.0.201 UDP 1K 145.20.0.202 145.10.0.201 UDP RSVP:Serial3/0 RSVP:Serial3/0 has has no no installed installed reservations reservations DPort DPort Sport Sport 1000 1001 1001 1002 1002 10 10 1000 1001 1001 1002 1002 10 10 Weight 0 13 13 6 6 0 0 264 264 266 266 265 265 264 264
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).
7-18

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

Router#show Router#show ip ip rsvp rsvp installed installed detail detail RSVP:Ethernet2/1 RSVP:Ethernet2/1 has has the the following following installed installed reservations reservations RSVP RSVP Reservation. Reservation. Destination Destination is is 145.20.0.202, 145.20.0.202, Source Source is is 145.10.0.201, 145.10.0.201, Protocol Protocol is is UDP, UDP, Destination Destination port port is is 1000, 1000, Source Source port port is is 1000 1000 Reserved Reserved bandwidth:44K bandwidth:44K bits/sec, bits/sec, Maximum Maximum burst:1K burst:1K bytes, bytes, Peak Peak rate: rate: 44K 44K bits/sec bits/sec QoS 0 (PQ) QoS provider provider for for this this flow:WFQ. flow:WFQ. Conversation Conversation number:264. number:264. Weight: Weight:0 (PQ) Conversation supports 1 reservations Conversation supports 1 reservations Data Data given given reserved reserved service:316 service:316 packets packets (15800 (15800 bytes) bytes) Data Data given given best-effort best-effort service:0 service:0 packets packets (0 (0 bytes) bytes) Reserved Reserved traffic traffic classified classified for for 104 104 seconds seconds Long-term Long-term average average bitrate bitrate (bits/sec):1212 (bits/sec):1212 reserved, reserved, 0M 0M best-effort best-effort RSVP Reservation. Destination is 145.20.0.202, RSVP Reservation. Destination is 145.20.0.202, Source Source is is 145.10.0.201, 145.10.0.201, Protocol Protocol is is UDP, UDP, Destination Destination port port is is 1001, 1001, Source Source port port is is 1001 1001 Reserved Reserved bandwidth:44K bandwidth:44K bits/sec, bits/sec, Maximum Maximum burst:3K burst:3K bytes, bytes, Peak Peak rate: rate: 44K 44K bits/sec bits/sec QoS 13 QoS provider provider for for this this flow:WFQ. flow:WFQ. Conversation Conversation number:266. number:266. Weight: Weight:13 Conversation Conversation supports 1 reservations Data Data given given reserved reserved service:9 service:9 packets packets (450 (450 bytes) bytes) Data Data given given best-effort best-effort service:0 service:0 packets packets (0 (0 bytes) bytes) Reserved Reserved traffic traffic classified classified for for 107 107 seconds seconds Long-term Long-term average average bitrate bitrate (bits/sec):33 (bits/sec):33 reserved, reserved, 0M 0M best-effort best-effort ... ...
The show ip rsvp installed detail command shows detailed information about active conversations currently installe d in the RSVP reservation table. Detailed timing and accounting for every conversation is displayed, together with the QoS mechanism used to provide service guarantees.
7-19

Router(config)#
show ip rsvp reservation [detail]
List RSVP reservations
Router(config)#
show ip rsvp request [detail]
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.
7-20
Monitoring and Troubleshooting RSVP with COPS

Router#
show ip rsvp policy [{cops | local} [acl]]
Lists all policies

Router#show Router#show ip ip rsvp rsvp policy policy cops cops COPS/RSVP COPS/RSVP settings: settings: Generate Generate reports for all decisions Do Do not not query query PDP PDP for for error error messages messages COPS/RSVP COPS/RSVP entry. entry. ACLs: ACLs: 100 100 PDPs: 10.100.1.1 10.101.1.1 PDPs: 10.100.1.1 10.101.1.1 Current Current state: state: Connected Connected Currently Currently connected connected to to PDP PDP 10.100.1.1, 10.100.1.1, port port 0 0 COPS/RSVP COPS/RSVP entry. entry. ACLs: ACLs: 101 101 PDPs: PDPs: 10.102.1.1 10.102.1.1 Current Current state: state: In In reconnect reconnect loop loop wait wait Reconnect Reconnect timer timer is is 960 960 seconds seconds
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.
7-21
Monitoring and Troubleshooting RSVP with COPS

Router#
show cops servers
Lists all COPS servers

Router#show Router#show cops cops servers servers COPS COPS SERVER: SERVER: Address: Address: 10.100.1.1. 10.100.1.1 . Port: Port: 3288. 3288. State: 0. Keepalive: 120 sec Number Number of of clients: clients: 1. 1. Number Number of of sessions: sessions: 1. 1. COPS COPS CLIENT: CLIENT: Client Client type: type: 1. 1. State: State: 0. 0.
The show cops servers command displays the state of all configured COPS servers.
7-22
Summary
n n n n
RSVP enables end-stations to signal QoS requirements to the network. RSVP does not provide any guarantees; router QoS mechanisms do. RSVP does not necessarily require an end-to-end RSVP-aware path. 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?
7-23
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 n n
Describe Subnet Bandwidth Management (SBM). Configure SBM. Monitor and troubleshoot RSVP with SBM.
7-24

RSVP manages unidirectional reservation of resources RSVP on shared media can result in oversubscription SBM is an add-on to RSVP on shared media to prevent oversubscription
RSVP is used to manage reservation of resources unidirectionally, between Layer3 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 RSVPcaused oversubscription. SBM specifies a signaling method and protocol for LANbased admission control for RSVP flows. SBM allows RSVP-enabled routers and Layer 2 and Layer 3 devices to support reservation of LAN resources for RSVPenabled data flows. The SBM signaling method is similar to that of RSVP itself.
7-25
Without SBM
Ethernet bandwidth 10Mbps 7.5 Mbps is reservable
Mbps rve 6 e s e R
6 Mbps booked 0 7.5 Mbps free 1.5
Reserve 6 Mbps
Ethernet Reserv e 7 Mb ps
7 Mbps booked 0 7.5 Mbps 512 kbps free
Reserve 7 Mbps
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 to achieve 100% utilization (collisions; depending on implementation)
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.
7-26
With SBM
Reserve 6 Mbps
Reserve 6 Mbps
e erv Res bps 6M
6 Mbps booked 0 7.5 Mbps free 1.5 6 Mbps booked 0 7.5 Mbps free 1.5 One of the routers on the segment is elected to be the Designated Subnet Bandwidth Manager (DSBM) The shared media is effectively transformed into a star of point-to-point links
Re ser ve 6
Erro r
Mb ps
Reserve 7 Mbps
7 Mbps booked 0 7.5 Mbps 512 kbps free
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 in conventional 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: If it cannot grant the request because of lack of resources, the DSBM returns a RESVERR message to the requester. 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.
7-27
DSBM Election
DSBM is elected based on the DSBM priority Each DSBM candidate advertises its priority in the range from 64 to 128 The candidate with the highest priority is elected to be the DSBM RSVP enabled devices can participate in Subnet Bandwidth Management without being 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 the highest priority.
7-28
Configuring DSBM
Router(config-if)#
ip rsvp dsbm candidate priority
Configures the router to bid in the election of the DSBM Default priority is 64
Router(config)#
ip rsvp rsvp dsbm dsbm non-resv-send-limit {burst | max-unit | minunit | peak | rate} value
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.
7-29
SBM Example
interface interface Ethernet0/0 Ethernet0/0 ip ip address address 10.1.1.1 10.1.1.1 255.255.255.0 255.255.255.0 ip ip rsvp rsvp bandwidth bandwidth 7500 7500 7500 7500 ip ip rsvp rsvp dsbm dsbm candidate 100 ip ip rsvp rsvp dsbm dsbm non-resv-send-limit rate 100 ip ip rsvp rsvp dsbm dsbm non-resv-send-limit non-resv-send-limit burst burst 1000 1000 ip ip rsvp rsvp dsbm 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).
7-30
Monitoring and Troubleshooting SBM

Router#
show ip sbm [detail]

Lists interfaces where SBM is active The detailed option displays detailed information about local configuration and the DSBM configuration
Router#show Router#show ip ip rsvp rsvp sbm sbm Interface DSBM DSBM Interface DSBM DSBM Addr Addr DSBM Priority Priority DSBM Candidate Candidate Et0/0 10.1.1.1 100 yes Et0/0 10.1.1.1 100 yes Et0/1 10.1.2.1 100 yes Et0/1 10.1.2.1 100 yes Router#show Router#show ip ip rsvp rsvp sbm sbm detail detail Interface:Ethernet 0/0 Interface:Ethernet0/0 Local Configuration Current Local Configuration Current DSBM DSBM IP IP IP Address:10.1.1.1 Address:10.1.1.1 IP Address:10.1.1.1 Address:10.1.1.1 DSBM I DSBM candidate:yes candidate:yes I Am Am DSBM:yes DSBM:yes Priority:100 Priority: 100 Priority:100 Priority:100 Non Non Non Resv Resv Send Send Limit Limit Non Resv Resv Send Send Limit Limit Rate:100 Kbytes/sec Rate:100 Rate:100 Kbytes/sec Rate:100 Kbytes/sec Kbytes/sec Burst:1000 Burst:1000 Burst:1000 Kbytes Burst:1000 Kbytes Kbytes Peak:100 Peak:100 Peak:100 Kbytes/sec Kbytes/sec Peak:100 Kbytes/sec Kbytes/sec Min Min Min Unit:unlimited Unit:unlimited Min Unit:unlimited Unit:unlimited Max Max Max Unit:unlimited Unit:unlimited Max Unit:unlimited Unit:unlimited
My My Priority Priority 100 100 100 100
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.
7-31
Summary
n n n
SBM enables RSVP to run over shared LAN segments. DSBM routers provide shared LAN adjudication of RSVP-reservations. 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?
7-32
Summary
n n n
RSVP enables end-stations to signal QoS requirements to the network RSVP does not provide any guarantees; router QoS mechanisms do. SBM enables RSVP to run over shared LAN segments.
7-33
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.
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 reservation

requests? 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 layer3 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.
7-34

S07 - IP QoS - Signaling Mechnisms PDF

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

S07 - IP QoS - Signaling Mechnisms PDF

Uploaded by

Copyright:

Available Formats

7

Resource Reservation Protocol (RSVP)

IP QoS Signaling Mechanism

Copyright 2001, Cisco Systems, Inc.

Resource Reservation Protocol

2001, Cisco Systems, Inc.

IP QoS Signaling Mechanism-5

Copyright 2001, Cisco Systems, Inc.

IP QoS Signaling Mechanism

2001, Cisco Systems, Inc.

IP QoS Signaling Mechanism-6

IP QoS Signaling Mechanism

Copyright 2001, Cisco Systems, Inc.

Copyright 2001, Cisco Systems, Inc.

IP QoS Signaling Mechanism

2001, Cisco Systems, Inc.

IP QoS Signaling Mechanism-7

IP QoS Signaling Mechanism

Copyright 2001, Cisco Systems, Inc.

Pass-through RSVP with Class of Service

Mark RSVP flow with DSCP

Copyright 2001, Cisco Systems, Inc.

IP QoS Signaling Mechanism

2001, Cisco Systems, Inc.

IP QoS Signaling Mechanism-9

IP QoS Signaling Mechanism

Copyright 2001, Cisco Systems, Inc.

Configuring Simple RSVP

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

2001, Cisco Systems, Inc.

IP QoS Signaling Mechanism -10

Copyright 2001, Cisco Systems, Inc.

IP QoS Signaling Mechanism

Configuring Proxy RSVP

IP QoS Signaling Mechanism

Copyright 2001, Cisco Systems, Inc.

RSVP Admission Control

2001, Cisco Systems, Inc.

IP QoS Signaling Mechanism -12

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

Copyright 2001, Cisco Systems, Inc.

IP QoS Signaling Mechanism

Common Open Policy Service

reserve reply Policy Decision Point (PDP)

IP QoS Signaling Mechanism

Copyright 2001, Cisco Systems, Inc.

Configuring RSVP for COPS

ip rsvp policy local

No ip rsvp policy local local-override

Default Local Policy? No

No Process Message Default Reject? No

Default Remote Policy? No

Copyright 2001, Cisco Systems, Inc.

IP QoS Signaling Mechanism

Configuring RSVP for COPS (cont.)

No Process Message Default Reject? No Yes ip rsvp policy default-reject

IP QoS Signaling Mechanism -15

IP QoS Signaling Mechanism

Copyright 2001, Cisco Systems, Inc.

Copyright 2001, Cisco Systems, Inc.

IP QoS Signaling Mechanism

2001, Cisco Systems, Inc.

IP QoS Signaling Mechanism -15