Re: FRTS with MQC

Hi,

with LLQ the entrance criteria to a class can be as granular as you like
because you define it by an ACL. You are not limited, as with IP RTP
priority, to a simple UDP port range. If the port range feature did not get
changed, it is probable that every future voice application would take
advantage of it.

Some voice QOS Design Considerations Notes:

General Considerations

   - Do not use VoIP on a FR PVC that also carries VoFR
   - Prioritize the PVC if it carries only voice traffic
   - Don't mark voice packets as DE
   - Set IP Precedence = 5 on the dial peer
   - Don't use WRED for voice queues
   - Turn on DTMF-relay for low bit-rate codecs (8k and below)
   - Set echo, loss/gain parameters as specified by the network loss plan.
   - Measure/calculate network packet delay - the goal is 150 to 200ms
   one-way.
   - If TCP delays affect DTMF-relay performance use Cisco-rtp for
   DTMF-relay

Queuing Considerations

   - LLQ - classify voice in a priority class
   - Use ip rtp priority if LLQ is not available
   - Set the bandwidth on the priority statement in the LLQ configuration
   (or in the ip rtp priority statement) to the aggregate number of calls per
   interface/PVC
   - Create ACLs that prioritize both voice media and signaling

Fragmentation Considerations (speeds less than 1.5Mbps

   - Fragment to a 10ms delay to optimize size for backbone packet/cell
   sizes and network delay characteristics
   - Set fragments size so that voice packets are not fragmented
   - Set the ppp multilink fragment-delay command on leased line interfaces
   - Set the frame-relay fragment command in the FR map class
   - Fragment all PVCs carrying data on the interface if at least one PVC
   carries voice

Traffic Shaping Considerations

   - Set Be to 0
   - Set Bc to 10ms (1/100 of CIR) for mixed voice/data PVCs
   - Set mincir greater than or equal to bandwidth needed for voice
   - Set FRTS on the interface
   - Shape traffic strictly to the CIR on the PVC carrying voice
   - Shape both sides of the VC to the slower link speed to prevent egress
   blocking

CAC Considerations

   - Limit voice calls to prevent oversubscription of the bandwidth

*Video QoS Design Considerations*

   - For bidirectional and/or low speed video use priority queuing and
   allocate 384Kbps for bandwidth
   - For one-way video traffic use a CBWFQ mechanism

LLQ Considerations

   - Large video MTUs placed in the LLQ's priority queue with voice traffic
   will bypass the fragmentation engine and cause delays for the voice traffic.

CAC Considerations

   - In a single-zone WAN model limit the number of video terminals
   - In a multizone WAN model use Gatekeeper CAC. However, Gatekeeper CAC
   is only available in a hub-and-spoke network.

On Fri, Jun 12, 2009 at 10:25 PM, mohmmad imran <imran_mohmmad_at_yahoo.com>wrote:

> Hi Experts,
>
> I am kinda confused when to use MQC LLQ in FRTS or to use IP RTP priority
> for
> VOICE Traffic prioritization.
>
> Task 1:-
>
> configure the FRTS on the router Frame-relay link with 256Kbps CIR, TC 10ms
> and to decrease the serialization delay on the circuit a single packet
> cannot
> take more than one interval to be transmitted
>
> Answer: -
>
> map-class frame-relay
> frame-relay cir 256000
> frame-relay bc 2560
> frame-relay fragment 320
>
> Task 2:-
> now says that configure your router so that 200Kbps of VOIP traffic is
> always
> de-queue first when it is sent over this frame-relay link.
>
> Answer: -
> As per my understanding I would do this with the frame-relay ip rtp
> priority
> like
>
> map-class frame-relay
> frame-relay cir 256000
> frame-relay bc 2560
> frame-relay fragment 320
> frame-relay ip rtp priority 16384 16383 200
>
> but in solution it uses the MQC LLQ and then called that service policy in
> class-map.
>
> Can anyone please explain when to use IP RTP priority and when to use MQC
> LLQ
> with FRTS?
>
> ---Imran
>
>
> Blogs and organic groups at http://www.ccie.net
>
> _______________________________________________________________________
> Subscription information may be found at:
> http://www.groupstudy.com/list/CCIELab.html
>
>
>
>
>
>
>
>

-- 
Victor Cappuccio
CCIE R/S# 20657
CCSI# 30452
www.anetworkerblog.com
www.linkedin.com/in/vcappuccio
Blogs and organic groups at http://www.ccie.net