Basically, with frame-relay you will want to do a few things:
1.) Insure a layer 3 QoS method
Since you are going to use both video and voice, you will want to use LLQ.
LLQ is basically CBWFQ + a priority queue. With LLQ you make policy maps
and class maps. The policy consists of being able to assign bandwith
queuing types for traffic classified by an access-list. For example, say
you have data, voice, and video on a lower speed frame-relay PVC. You can
create a policy map and within that policy map have different class maps.
The class maps define what traffic is "interesting." This is done with
ACLs. The policy map take each class map and defines potential queueing
types, bandwidth allotment, and potentially priority queue assignment.
2.) Insure a layer 2 QoS method
With frame relay, you will be subject to serialization delay. Since
frame-relay has a variable packet size, even if you are using a good layer 3
QoS mechanism, you will be prone to jitter and delay without link
fragmentation and interleaving (LFI). LFI is the basis which you can
fragment packets to be then placed on the link to insure that one large
packet does not cause the others to suffer a delay. With frame relay FRF.12
is the recommended LFI mechanism.
3.) Traffic shape to the CIR
Lastly, frame-relay is a packet based service. Since it is as such, it is
subject to network oversubscription and packet discard. The carrier that
you get your frame relay service from will give you a CIR. The CIR will be
your guaranteed traffic rate. Anything above the CIR will be discard
eligible. To insure that you do not exceed your CIR with voice, you must
use frame relay traffic shaping.
These are all IOS features that enable you to adequately classify,
prioritize, queue, shape, and send your voice, video, and data.
Here is a good link on CCO....
http://www.cisco.com/univercd/cc/td/doc/product/voice/ip_tele/network/dgqos.
htm
You can also do searches on LLQ, CBWFQ, FRF.12, frame-relay traffic shaping,
etc...
Good luck.
Cory Cipra
[EMAIL PROTECTED]
-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of
John Neiberger
Sent: Saturday, December 02, 2000 12:15 AM
To: [EMAIL PROTECTED]
Subject: QoS Confusion!
[Warning: I should have broken this up into several separate questions, but
it's late and I'm feeling lazy.]
We are currently implementing video over IP over frame relay. Our video
conferencing units have the capability to set the IP precedence of their
traffic. I initially thought that we'd have to configure custom queueing to
adequately address any congestion problems, but I've now decided to use
simple WFQ since it takes IP precedence into account.
This is working, but I wish I could find more documentation about the
different queueing mechanisms and the details of their operation and
configuration. I've scoured CCO and can't find any understandable
explanations of custom queueing.
I'm also confused about when these queueing mechanims activate. Take WFQ,
for instance. I can tell by typing "show queue s0/0" that there are no
conversations in queue, and I understand this to mean that the link is so
far from being congested that we're not really queueing anything and doing
FIFO instead. Now, from time to time, I see a few conversations in the
queue and notice that the video packets are marked correctly and do not get
dropped, at the expense of some other less important traffic.
At what point does queueing actually begin? At full link congestion? That
would be a little late, in my opinion.
To those of you with experience in such things: do you feel that WFQ is
adequate in this situation? It appears to be working great so far, but our
links are generally not very congested...yet.
Now, the kicker. In the not-so-distant-future we are moving to voice over
IP, as well, except this is over our entire network instead of just 3 or 4
locations. The phone system we use sets the IP precedence of the voice
packets before they enter the network. Would WFQ be enough for all of our
traffic? We've got a lot of different traffic types on our links, and
though they are not currently overtaxed (unlike me) I am worried about
congestion.
Should I consider custom or priority queueing when we implement VoIP? And
what are the implications of trying to configure any type of queueuing on
frame relay interfaces that have several subinterfaces?
This could turn into one big hairy mess!
Okay, I'm done raving for the time being. Any advice from the battle-worn
veterans would be greatly appreciated.
Thanks!
John
_______________________________________________________
Tired of slow Internet? Get @Home Broadband Internet
http://www.home.com/xinbox/signup.html
_________________________________
FAQ, list archives, and subscription info:
http://www.groupstudy.com/list/cisco.html
Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
_________________________________
FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html
Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
