Subject: multicasting on a loaded link

From: Dimitri Sidelnikov <[email-masked]>
Date: Fri, 18 Oct 1996 20:01:10 +0400

I wonder if it is possible to reserve for multicasting a known part of
the full bandwidth on a heavily loaded link.

For native multicast it seems to be possible by doing the following:

interface Serial0
 bandwidth 144
 ip multicast rate-limit out 128
 priority-group 1
!
priority-list 1 protocol ip high tcp bgp
priority-list 1 protocol ip high tcp domain
priority-list 1 protocol ip high udp domain
priority-list 1 protocol ip medium list 131
priority-list 1 protocol ip normal tcp ftp
priority-list 1 protocol ip normal tcp telnet
priority-list 1 protocol ip normal tcp www
priority-list 1 protocol ip normal fragments
priority-list 1 protocol ip normal tcp nntp
priority-list 1 default low
!
access-list 131 permit ip any 224.0.0.0 15.255.255.255

Have anybody tried that? Does it work?

How can I achieve the goal if I'm encapsulating native multicast in a
DVMRP tunnel? I don't know how the analogue of acl 131 would look like
in this case.

Thank you.
---
D. Sidelnikov

---

From: Joseph Porrovecchio <[email-masked]>
Date: Wed, 23 Oct 1996 16:22:38 -0400

Greetings Dimitri,

my aplogies for relpying so late to your email:)

> Have anybody tried that? Does it work?

I haven not implememnted this nor do I have an idea if it is goping to work.

However, there is a utility on the proteon rbx200 router called BRS
(Bandwidth Reservation Utility). With BRS one can set a cap on the traffic on 
alink.
This is used so as to not exceed 100% of the bandwith on heavily traversed 
links.
A feature of this BRS is that you can  reserve bandwith on a protocol basis.
In our case one could set, for example, 50% multicast traffic.
    
> DVMRP tunnel? I don't know how the analogue of acl 131 would look like

BRS peers into the datagram and identifies the packet.

I'm not quite sure if cisco routers offer this functionality.
> D. Sidelnikov

regards,

-- 
Joseph Porrovecchio

ONet Networking
Customer Support/Network Specialist
4 Bancroft Ave. Rm. 101
Toronto, Ontario M5S 1C1
Info: (416) 978-4589 Office: (416) 978-0188
http://enfm.utcc.utoronto.ca/~joseph

---

From: dave pratt <[email-masked]>
Date: Thu, 24 Oct 1996 09:00:31 +0100 (BST)

On Wed, 23 Oct 1996, Dimitri wrote:

->> I wonder if it is possible to reserve for multicasting a known part of
->> the full bandwidth on a heavily loaded link.
->> For native multicast it seems to be possible by doing the following:
->> 
->> interface Serial0
->>  bandwidth 144
->>  ip multicast rate-limit out 128
->>  priority-group 1
->> !
->> priority-list 1 protocol ip high tcp bgp
->> priority-list 1 protocol ip high tcp domain
->> priority-list 1 protocol ip high udp domain
->> priority-list 1 protocol ip medium list 131
->> priority-list 1 protocol ip normal tcp ftp
->> priority-list 1 protocol ip normal tcp telnet
->> priority-list 1 protocol ip normal tcp www
->> priority-list 1 protocol ip normal fragments
->> priority-list 1 protocol ip normal tcp nntp
->> priority-list 1 default low
->> !
->> access-list 131 permit ip any 224.0.0.0 15.255.255.255
->> 
->> Have anybody tried that? Does it work?
->> 
->> How can I achieve the goal if I'm encapsulating native multicast in a
->> DVMRP tunnel? I don't know how the analogue of acl 131 would look like
->> in this case.
->> 
->> Thank you.
->> ---
->> D. Sidelnikov

My guess at the appropriate access list would be:

access-list 131 permit ipinip host <source of tunnel> host <end of tunnel>

You may also wish to give a high priority to IGMP traffic on the link to
ensure good MBone control traffic priority. 
   
I haven't tried priority lists yet but I may on my MBoned ISDN connection to
home... (with 155M ATM links we have little need yet :) ). We do pass DVMRP
tunnels through a firewall though ;(

Cheers
--------
The views expressed here may or may not be anybodies.
WWW - doesn't that stand for "Wait a Week Word" ?
BEER - so much more than just a breakfast drink.
Dave Pratt      (tel: +44 1473 643840 )
[email-masked]