|
Home > Archive > Voice over IP Cisco > May 2007 > QOS for MPLS
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
|
|
| Jonathan Charles 2007-05-26, 7:12 pm |
| I have always understood that QOS settings need to match on both ends
of a circuit... so, if you allocate 800k on one side, you need to do
the same on the other.
I am now working on an MPLS circuit that has DS3s on some sides, DS1s
on others... do I still need to match QOS settings?
Customer wants 800k on the T1s and 2500k on the DS3s... I don't think
it will matter as I am matching these bw limits on the locations...
but how do I throttle calls from a DS3-side location to a DS1
location?
For example... main site is in Chicago, they have a DS3, one remote
site is in Wichita and has a T1... so, I put 800k for Wichita and
2500k for Chicago... what is to stop Chicago from flooding Wichita
with 2.5MB of calls?
Jonathan
| |
| Clouse, Chris 2007-05-26, 7:12 pm |
| Use CallManager locations to perform Call Admission Control.
Christopher Clouse, CCNP CCDP CCVP MCP Network+
-----Original Message-----
From: cisco-voip-bounces@puck.nether.net
[mailto:cisco-voip-bounces@puck.nether.net] On Behalf Of Jonathan
Charles
Sent: Saturday, May 26, 2007 11:35 AM
To: ciscovoip
Subject: [cisco-voip] QOS for MPLS
I have always understood that QOS settings need to match on both ends
of a circuit... so, if you allocate 800k on one side, you need to do
the same on the other.
I am now working on an MPLS circuit that has DS3s on some sides, DS1s
on others... do I still need to match QOS settings?
Customer wants 800k on the T1s and 2500k on the DS3s... I don't think
it will matter as I am matching these bw limits on the locations...
but how do I throttle calls from a DS3-side location to a DS1
location?
For example... main site is in Chicago, they have a DS3, one remote
site is in Wichita and has a T1... so, I put 800k for Wichita and
2500k for Chicago... what is to stop Chicago from flooding Wichita
with 2.5MB of calls?
Jonathan
________________________________________
_______
cisco-voip mailing list
cisco-voip@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-voip
| |
| Paul Choi 2007-05-26, 7:12 pm |
| He's talking about QoS for MPLS, not CAC.
--- "Clouse, Chris" <chris.clouse@berbee.com> wrote:
> Use CallManager locations to perform Call Admission
> Control.
>
> Christopher Clouse, CCNP CCDP CCVP MCP Network+
>
>
> -----Original Message-----
> From: cisco-voip-bounces@puck.nether.net
> [mailto:cisco-voip-bounces@puck.nether.net] On
> Behalf Of Jonathan
> Charles
> Sent: Saturday, May 26, 2007 11:35 AM
> To: ciscovoip
> Subject: [cisco-voip] QOS for MPLS
>
> I have always understood that QOS settings need to
> match on both ends
> of a circuit... so, if you allocate 800k on one
> side, you need to do
> the same on the other.
>
> I am now working on an MPLS circuit that has DS3s on
> some sides, DS1s
> on others... do I still need to match QOS settings?
>
> Customer wants 800k on the T1s and 2500k on the
> DS3s... I don't think
> it will matter as I am matching these bw limits on
> the locations...
> but how do I throttle calls from a DS3-side location
> to a DS1
> location?
>
> For example... main site is in Chicago, they have a
> DS3, one remote
> site is in Wichita and has a T1... so, I put 800k
> for Wichita and
> 2500k for Chicago... what is to stop Chicago from
> flooding Wichita
> with 2.5MB of calls?
>
>
>
> Jonathan
________________________________________
________________________________________
____Building a website is a piece of cake. Yahoo! Small Business gives you all the tools to get online.
http://smallbusiness.yahoo.com/webhosting
| |
| keli@carocomp.ro 2007-05-27, 7:11 am |
| As long as it is about "calls", CAC is the sensitive way to go about
limiting the calls in the first place. Do QoS "As close to the source,
as possible", remember? 
If you do not have a CCM, but other set-up, you should still look in
this direction first - to limit the calls to a reasonable amount in
the given directions, before they are hitting your MPLS router.
regards,
Zoltan
Quoting Paul Choi <asobihoudai@yahoo.com>:
> He's talking about QoS for MPLS, not CAC.
>
> --- "Clouse, Chris" <chris.clouse@berbee.com> wrote:
>
>
>
>
>
>
> ________________________________________
________________________________________
____Building a website is a piece of cake. Yahoo! Small Business gives you all the tools to get
> online.
> http://smallbusiness.yahoo.com/webhosting
> ________________________________________
_______
> cisco-voip mailing list
> cisco-voip@puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-voip
>
----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.
| |
| Jonathan Charles 2007-05-27, 7:11 pm |
| My thinking is that I need to set the QOS to be the same as the
maximum number of calls to/from each site.
Jonathan
On 5/27/07, keli@carocomp.ro <keli@carocomp.ro> wrote:
> As long as it is about "calls", CAC is the sensitive way to go about
> limiting the calls in the first place. Do QoS "As close to the source,
> as possible", remember?
>
> If you do not have a CCM, but other set-up, you should still look in
> this direction first - to limit the calls to a reasonable amount in
> the given directions, before they are hitting your MPLS router.
>
> regards,
> Zoltan
>
> Quoting Paul Choi <asobihoudai@yahoo.com>:
>
>
>
>
> ----------------------------------------------------------------
> This message was sent using IMP, the Internet Messaging Program.
>
> ________________________________________
_______
> cisco-voip mailing list
> cisco-voip@puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-voip
>
| |
| keli@carocomp.ro 2007-05-27, 7:11 pm |
| That is correct (although you should take some overhead into account
as well). However, if you do not perform Call Admission Control
beforehand (you do not limit the maximum number of possible
simultaneous calls) you've done nothing, or worse.
The classic example being when you have a line that supports 4 calls,
when the fifth call enters the line, all calls will suffer packet loss
and delay, not only the fifth one.
I'm not too versed in MPLS QoS, but the idea is always the same.
Prioritize voice traffic, but don't let it kill your bandwidth, nor
itself. Thus the need for CAC, then something like CBWFQ/PQ. If
possible, voice traffic should be beneath shaping/policing limits, so
that neither would affect it.
regards,
Zoltan
Quoting Jonathan Charles <jonvoip@gmail.com>:
[vbcol=seagreen]
> My thinking is that I need to set the QOS to be the same as the
> maximum number of calls to/from each site.
>
>
> Jonathan
>
> On 5/27/07, keli@carocomp.ro <keli@carocomp.ro> wrote:
----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.
| |
| Erick Bergquist 2007-05-27, 7:11 pm |
| I've seen one or two setups where the MPLS was fully meshed (all sites could talk to any other site), which makes QoS even trickier.
----- Original Message ----
From: "keli@carocomp.ro" <keli@carocomp.ro>
To: Jonathan Charles <jonvoip@gmail.com>
Cc: cisco-voip@puck.nether.net
Sent: Sunday, May 27, 2007 3:50:17 PM
Subject: Re: [cisco-voip] QOS for MPLS
That is correct (although you should take some overhead into account
as well). However, if you do not perform Call Admission Control
beforehand (you do not limit the maximum number of possible
simultaneous calls) you've done nothing, or worse.
The classic example being when you have a line that supports 4 calls,
when the fifth call enters the line, all calls will suffer packet loss
and delay, not only the fifth one.
I'm not too versed in MPLS QoS, but the idea is always the same.
Prioritize voice traffic, but don't let it kill your bandwidth, nor
itself. Thus the need for CAC, then something like CBWFQ/PQ. If
possible, voice traffic should be beneath shaping/policing limits, so
that neither would affect it.
regards,
Zoltan
Quoting Jonathan Charles <jonvoip@gmail.com>:
[vbcol=seagreen]
> My thinking is that I need to set the QOS to be the same as the
> maximum number of calls to/from each site.
>
>
> Jonathan
>
> On 5/27/07, keli@carocomp.ro <keli@carocomp.ro> wrote:
----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.
________________________________________
_______
cisco-voip mailing list
cisco-voip@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-voip
________________________________________
________________________________________
____
We won't tell. Get more on shows you hate to love
(and love to hate): Yahoo! TV's Guilty Pleasures list.
http://tv.yahoo.com/collections/265
| |
| Jorge Evangelista 2007-05-27, 7:11 pm |
| There are a list of EXP [*] values for MPLS that you could use for
marking. I have read that it marks MPLS and IP tunnel packets by
default during some encapsulation operations.
Cisco says "The set mpls experimental topmost command on an input
policy always marks MPLS packets before the node performs all label
forwarding operations (push, swap, or pop). "
There is a book with some examples
Cisco.Press.QoS.for.IP.MPLS.Networks.Jun.2006.chm
Regards,
On 5/27/07, keli@carocomp.ro <keli@carocomp.ro> wrote:
> That is correct (although you should take some overhead into account
> as well). However, if you do not perform Call Admission Control
> beforehand (you do not limit the maximum number of possible
> simultaneous calls) you've done nothing, or worse.
>
> The classic example being when you have a line that supports 4 calls,
> when the fifth call enters the line, all calls will suffer packet loss
> and delay, not only the fifth one.
>
> I'm not too versed in MPLS QoS, but the idea is always the same.
> Prioritize voice traffic, but don't let it kill your bandwidth, nor
> itself. Thus the need for CAC, then something like CBWFQ/PQ. If
> possible, voice traffic should be beneath shaping/policing limits, so
> that neither would affect it.
>
> regards,
> Zoltan
>
> Quoting Jonathan Charles <jonvoip@gmail.com>:
>
>
>
>
> ----------------------------------------------------------------
> This message was sent using IMP, the Internet Messaging Program.
>
> ________________________________________
_______
> cisco-voip mailing list
> cisco-voip@puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-voip
>
--
"The network is the computer"
| |
| Jonathan Charles 2007-05-27, 7:11 pm |
| Which is the definition of MPLS, any-to-any communication. All
circuits are point to point into the MPLS cloud and then routing in
the cloud to each site.
Jonathan
On 5/27/07, Erick Bergquist <erickbe@yahoo.com> wrote:
> I've seen one or two setups where the MPLS was fully meshed (all sites could talk to any other site), which makes QoS even trickier.
>
> ----- Original Message ----
> From: "keli@carocomp.ro" <keli@carocomp.ro>
> To: Jonathan Charles <jonvoip@gmail.com>
> Cc: cisco-voip@puck.nether.net
> Sent: Sunday, May 27, 2007 3:50:17 PM
> Subject: Re: [cisco-voip] QOS for MPLS
>
> That is correct (although you should take some overhead into account
> as well). However, if you do not perform Call Admission Control
> beforehand (you do not limit the maximum number of possible
> simultaneous calls) you've done nothing, or worse.
>
> The classic example being when you have a line that supports 4 calls,
> when the fifth call enters the line, all calls will suffer packet loss
> and delay, not only the fifth one.
>
> I'm not too versed in MPLS QoS, but the idea is always the same.
> Prioritize voice traffic, but don't let it kill your bandwidth, nor
> itself. Thus the need for CAC, then something like CBWFQ/PQ. If
> possible, voice traffic should be beneath shaping/policing limits, so
> that neither would affect it.
>
> regards,
> Zoltan
>
> Quoting Jonathan Charles <jonvoip@gmail.com>:
>
>
>
>
> ----------------------------------------------------------------
> This message was sent using IMP, the Internet Messaging Program.
>
> ________________________________________
_______
> cisco-voip mailing list
> cisco-voip@puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-voip
>
>
>
>
>
>
> ________________________________________
________________________________________
____
> We won't tell. Get more on shows you hate to love
> (and love to hate): Yahoo! TV's Guilty Pleasures list.
> http://tv.yahoo.com/collections/265
>
| |
| Carter, Bill 2007-05-29, 7:11 pm |
| With MPLS and sites with different bandwidths, you should set the QoS
based on the site bandwidth. So it is ok to have 800k on the T1's and
2500k on the DS3's. Locations would prevent HQ from flooding a
particular site.
Because of the mesh possibilities of MPLS, I would set the HQ Location
bandwidth to unlimited and the remote at ~800kb.
If this is Unified CM 5.X you could use RSVP. CM locations are more
designed for a Hub and Spoke network. RSVP accommodates a meshed
topology.
-----Original Message-----
From: cisco-voip-bounces@puck.nether.net
[mailto:cisco-voip-bounces@puck.nether.net] On Behalf Of Jonathan
Charles
Sent: Sunday, May 27, 2007 4:54 PM
To: Erick Bergquist
Cc: cisco-voip@puck.nether.net
Subject: Re: [cisco-voip] QOS for MPLS
Which is the definition of MPLS, any-to-any communication. All circuits
are point to point into the MPLS cloud and then routing in the cloud to
each site.
Jonathan
On 5/27/07, Erick Bergquist <erickbe@yahoo.com> wrote:
> I've seen one or two setups where the MPLS was fully meshed (all sites
could talk to any other site), which makes QoS even trickier.
>
> ----- Original Message ----
> From: "keli@carocomp.ro" <keli@carocomp.ro>
> To: Jonathan Charles <jonvoip@gmail.com>
> Cc: cisco-voip@puck.nether.net
> Sent: Sunday, May 27, 2007 3:50:17 PM
> Subject: Re: [cisco-voip] QOS for MPLS
>
> That is correct (although you should take some overhead into account
> as well). However, if you do not perform Call Admission Control
> beforehand (you do not limit the maximum number of possible
> simultaneous calls) you've done nothing, or worse.
>
> The classic example being when you have a line that supports 4 calls,
> when the fifth call enters the line, all calls will suffer packet loss
> and delay, not only the fifth one.
>
> I'm not too versed in MPLS QoS, but the idea is always the same.
> Prioritize voice traffic, but don't let it kill your bandwidth, nor
> itself. Thus the need for CAC, then something like CBWFQ/PQ. If
> possible, voice traffic should be beneath shaping/policing limits, so
> that neither would affect it.
>
> regards,
> Zoltan
>
> Quoting Jonathan Charles <jonvoip@gmail.com>:
>
[vbcol=seagreen]
[vbcol=seagreen]
>
>
>
> ----------------------------------------------------------------
> This message was sent using IMP, the Internet Messaging Program.
>
> ________________________________________
_______
> cisco-voip mailing list
> cisco-voip@puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-voip
>
>
>
>
>
>
> ________________________________________
______________________________
> ______________ We won't tell. Get more on shows you hate to love (and
> love to hate): Yahoo! TV's Guilty Pleasures list.
> http://tv.yahoo.com/collections/265
>
________________________________________
_______
cisco-voip mailing list
cisco-voip@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-voip
| |
| Carter, Bill 2007-05-30, 1:11 am |
| What about traffic shaping at the head end?
-----Original Message-----
From: cisco-voip-bounces@puck.nether.net
[mailto:cisco-voip-bounces@puck.nether.net] On Behalf Of Carter, Bill
Sent: Tuesday, May 29, 2007 1:43 PM
To: Jonathan Charles; Erick Bergquist
Cc: cisco-voip@puck.nether.net
Subject: Re: [cisco-voip] QOS for MPLS
With MPLS and sites with different bandwidths, you should set the QoS
based on the site bandwidth. So it is ok to have 800k on the T1's and
2500k on the DS3's. Locations would prevent HQ from flooding a
particular site.
Because of the mesh possibilities of MPLS, I would set the HQ Location
bandwidth to unlimited and the remote at ~800kb.
If this is Unified CM 5.X you could use RSVP. CM locations are more
designed for a Hub and Spoke network. RSVP accommodates a meshed
topology.
-----Original Message-----
From: cisco-voip-bounces@puck.nether.net
[mailto:cisco-voip-bounces@puck.nether.net] On Behalf Of Jonathan
Charles
Sent: Sunday, May 27, 2007 4:54 PM
To: Erick Bergquist
Cc: cisco-voip@puck.nether.net
Subject: Re: [cisco-voip] QOS for MPLS
Which is the definition of MPLS, any-to-any communication. All circuits
are point to point into the MPLS cloud and then routing in the cloud to
each site.
Jonathan
On 5/27/07, Erick Bergquist <erickbe@yahoo.com> wrote:
> I've seen one or two setups where the MPLS was fully meshed (all sites
could talk to any other site), which makes QoS even trickier.
>
> ----- Original Message ----
> From: "keli@carocomp.ro" <keli@carocomp.ro>
> To: Jonathan Charles <jonvoip@gmail.com>
> Cc: cisco-voip@puck.nether.net
> Sent: Sunday, May 27, 2007 3:50:17 PM
> Subject: Re: [cisco-voip] QOS for MPLS
>
> That is correct (although you should take some overhead into account
> as well). However, if you do not perform Call Admission Control
> beforehand (you do not limit the maximum number of possible
> simultaneous calls) you've done nothing, or worse.
>
> The classic example being when you have a line that supports 4 calls,
> when the fifth call enters the line, all calls will suffer packet loss
> and delay, not only the fifth one.
>
> I'm not too versed in MPLS QoS, but the idea is always the same.
> Prioritize voice traffic, but don't let it kill your bandwidth, nor
> itself. Thus the need for CAC, then something like CBWFQ/PQ. If
> possible, voice traffic should be beneath shaping/policing limits, so
> that neither would affect it.
>
> regards,
> Zoltan
>
> Quoting Jonathan Charles <jonvoip@gmail.com>:
>
[vbcol=seagreen]
[vbcol=seagreen]
>
>
>
> ----------------------------------------------------------------
> This message was sent using IMP, the Internet Messaging Program.
>
> ________________________________________
_______
> cisco-voip mailing list
> cisco-voip@puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-voip
>
>
>
>
>
>
> ________________________________________
______________________________
> ______________ We won't tell. Get more on shows you hate to love (and
> love to hate): Yahoo! TV's Guilty Pleasures list.
> http://tv.yahoo.com/collections/265
>
________________________________________
_______
cisco-voip mailing list
cisco-voip@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-voip
________________________________________
_______
cisco-voip mailing list
cisco-voip@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-voip
|
|
|
|
|