Добавил:
Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз: Предмет: Файл:
DQOS Exam Certification Guide - Cisco press.pdf
Скачиваний:
72
Добавлен:
24.05.2014
Размер:
12.7 Mб
Скачать

616 Chapter 8: Call Admission Control and QoS Signaling

Figure 8-33 RSVP Packet-Classification Criteria

 

 

 

 

 

Egress Interface / PVC

 

 

 

 

 

 

Queueing (LLQ)

 

 

 

Voice Conforming, Admitted Flows

 

 

 

 

 

 

 

 

 

 

 

 

 

Priority

 

 

 

 

 

 

 

 

Unclassified

 

 

 

 

Queue

 

 

 

 

 

 

 

Flows

 

Non-Voice Conforming, Admitted Flows

 

 

 

RSVP

 

Reserved

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Queues

 

 

 

Classification

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Class 1

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Class 2

 

 

 

 

Non-Admitted Flows, Voice Signaling

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Traffic, PATH and RESV Messages

 

Default

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Queue

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

It is important to note that RSVP classifies only voice bearer traffic, not signaling traffic. Another classification mechanism such as an ACL or DiffServ code point (DSCP) / IP precedence must still be used to classify the voice-signaling traffic if any treatment better than best effort is desired for signaling traffic.

Bandwidth per Codec

Both LLQ and RSVP see the Layer 3 IP packet. Layer 2 encapsulations (FR, MLPPP, and so on) are added after queuing, so the bandwidth allocated by both LLQ and RSVP for a call is based on the Layer 3 bandwidth of the packets. This number is slightly different from the actual bandwidth used on the interface after Layer 2 headers and trailers have been incorporated. RSVP bandwidth reserved for a call also excludes both cRTP and VAD. Table 8-21 summarizes the bandwidth RSVP allocates for calls using different Cisco IOS gateway codecs.

Table 8-21 RSVP Bandwidth Reservations for Voice Codecs

Codec

Bandwidth Reserved per Call in LLQ

 

 

G.711 (A-law and µ-law)

80 kbps

 

 

G.723.1 and G.723.1A (5.3 kbps)

22 kbps

 

 

Resource-Based CAC 617

Table 8-21 RSVP Bandwidth Reservations for Voice Codecs (Continued)

Codec

Bandwidth Reserved per Call in LLQ

 

 

G.723.1 and G.723.1A (6.3 kbps)

23 kbps

 

 

 

G.726

(16 kbps)

32 kbps

 

 

 

G.726

(24 kbps)

40 kbps

 

 

 

G.726

(32 kbps)

48 kbps

 

 

 

G.728

 

32 kbps

 

 

 

G.729

(all versions)

24 kbps

 

 

 

Subnet Bandwidth Management

Subnet bandwidth management (SBM) specifies a signaling method and protocol for LANbased CAC for RSVP flows. SBM allows RSVP-enabled Layer 2 and Layer 3 devices to support reservation of LAN resources for RSVP-enabled data flows.

SBM uses the concept of a designated entity elected to control the reservations for devices on the managed LAN. The elected candidate is called the designated subnetwork bandwidth manager (DSBM). It is the DSBM’s responsibility to exercise admission control over requests for resource reservations on a managed segment. A managed segment includes a Layer 2 physical segment shared by one or more senders, such as a shared Ethernet network. The presence of a DSBM makes the segment a managed one. One or more SBMs may exist on a managed segment, but there can be only one DSBM on each managed segment. A router interface can be configured to participate in the DSBM election process. The contender configured with the highest priority becomes the DSBM for the managed segment.

Figure 8-34 shows a managed segment in a Layer 2 domain that interconnects a group of routers.

Figure 8-34 DSBM Managed Subnet

DSBM Client

DSBM

DSBM Client

Ethernet

DSBM Client

DSBM Client

618 Chapter 8: Call Admission Control and QoS Signaling

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 DSBM of the segment rather than 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 or Layer 3 hop from which it received the path message. After processing the path message, the DSBM forwards it toward its destination address.

The DSBM receives the RSVP resv message and processes it in a manner similar to how RSVP 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 resverror message to the requester.

If sufficient resources are available and the DSBM can grant the reservation request, it forwards the resv message toward the previous hops using the local path state for the session.

RSVP Configuration

The following three tasks are performed on a gateway to originate or terminate voice traffic using RSVP:

1Turn on the synchronization feature between RSVP and H.323. This is a global command and is turned on by default when Cisco IOS Release 12.1(5)T or later is loaded.

2Configure RSVP on both the originating and terminating sides of the VoIP dial peers. Configure both the requested QoS (req-qos) and the acceptable QoS (acc-qos) commands. The guaranteed-delay option must be chosen for RSVP to act as a CAC mechanism. Other combinations of parameters may lead to a reservation, but not offer CAC.

3Enable RSVP and specify the maximum bandwidth on the interfaces that the call will traverse.

Table 8-22 lists the commands used to define and enable RSVP.

Table 8-22 RSVP Profile, req-qos and acc-qos Commands

Command

Mode and Function

 

 

ip rsvp bandwidth total-bandwidth

Interface configuration mode; defines the cumulative total,

per-reservation-bandwidth

and per-reservation, bandwidth limits

 

 

call rsvp-sync

Global configuration mode; enables H.323 RSVP

 

synchronization

 

 

ip rsvp pq-profile

Global configuration mode; specifies the criteria for

 

determining which flows go into the priority queue

 

 

Resource-Based CAC 619

Table 8-22 RSVP Profile, req-qos and acc-qos Commands (Continued)

Command

Mode and Function

 

 

req-qos {best-effort | controlled-load |

Dial-peer configuration mode; specifies the desired quality

guaranteed-delay}

of services requested to be used in reaching a specified VoIP

 

dial peer

 

 

acc-qos {best-effort | controlled-load |

Dial-peer configuration mode; specifies the acceptable

guaranteed-delay}

quality of service for any inbound and outbound call on a

 

VoIP dial peer

 

 

fair-queue [congestive-discard-

Interface configuration mode; enables WFQ on an interface,

threshold [dynamic-queues

with the last parameter defining the number of RSVP-

[reservable-queues]]]

created queues

 

 

Example 8-17 demonstrates the configuration required to enable RSVP with LLQ.

Example 8-17 Enabling RSVP with LLQ

!Global command enabling RSVP as CAC, turned on by default.

!

!RSVP classification default profile for Cisco VoIP packets ip rsvp pq-profile voice-like

ip rsvp bandwidth 200 25

!

interface serial 0/0 service-policy output LLQ-policy

!

voice-port 1/0:0

!

dial-peer voice 100 pots destination-pattern 2......

port 1/0:0

!

dial-peer voice 300 voip destination-pattern 3......

session target ipv4:10.10.2.2

!Configures RSVP CAC for voice calls using the dial peer. req-qos guaranteed-delay

acc-qos guaranteed-delay

In the example, the call rsvp-sync command enables synchronization of H.323 and RSVP, which allows new call requests to reserve bandwidth using RSPV. The ip rsvp pq-profile command tells IOS to classify voice packets into a low-latency queue priority queue, assuming LLQ is configured on the same interface as RSVP. On interface serial 0/0, a service-policy command enables a policy map that defines LLQ, and the ip rsvp bandwidth command reserves a total of 200 kbps, with a per-reservation limit of 25 kbps. The req-qos and acc-qos commands tell IOS to make RSVP reservation requests when new call requests have been made.

620 Chapter 8: Call Admission Control and QoS Signaling

Although RSVP does support reservations for voice traffic with H.323 sync, IOS does of course support RSVP independent of voice traffic. To support data traffic, LLQ may not even be needed. Example 8-18 demonstrates the configuration required to enable RSVP on a PPP interface, but with WFQ used rather than LLQ.

Example 8-18 Enabling RSVP on a PPP Interface

interface Serial0/1 bandwidth 1536

ip address 10.10.1.1 255.255.255.0 encapsulation ppp

!Enables WFQ as the basic queueing method. fair-queue 64 256 36

!Enables RSVP on the interface. ip rsvp bandwidth 1152 24

You can also configure RSVP along with traffic shaping. RSVP can reserve bandwidth inside shaping queues. In Example 8-19, the configuration shows RSVP enabled with Frame Relay traffic shaping (FRTS). The ip rsvp bandwidth command in this case is a subinterface subcommand, essentially reserving bandwidth inside the FRTS queues for each virtual circuit on that subinterface.

Example 8-19 Enabling RSVP on a Frame Relay Interface

interface Serial0/0 bandwidth 1536 encapsulation frame-relay no fair-queue

frame-relay traffic-shaping

!

interface Serial0/0.2 point-to-point ip address 10.10.2.2 255.255.255.0 frame-relay interface-dlci 17 class VoIPoFR

!Enables RSVP on the subinterface. ip rsvp bandwidth 64 24

map-class frame-relay VoIPoFR

no frame-relay adaptive-shaping frame-relay cir 128000 frame-relay bc 1280

frame-relay mincir 128000

!Enables WFQ as the basic queueing method. frame-relay fair-queue

frame-relay fragment 160

Finally, Example 8-20 shows RSVP and SBM enabled on Ethernet interface 2. After RSVP is enabled, the interface is configured as a DSBM and SBM candidate with a priority of 100. The configured SBM priority is higher than the default of 64, making the interface a good contender