multicast TTL settings
nickless at mcs.anl.gov
Mon Jun 28 14:19:00 CDT 1999
At 01:45 PM 6/28/99 -0500, Robert Olson wrote:
>What if the required TTL turns out to be something like 127 that is
>equivalent to full Mbone span? As I understand things, the admin scoping is
>the new preferred mechanism for doing things like this... or is the state
>of mrouting now such that one can push out several Mbps of multicast
>traffic on a relatively high ttl and not get lots of people pissed off.
>(I guess this is something we may learn empirically soon :-)
I would argue that sites and/or networks should use lower TTL settings for
MBONE links that have better connectivity. To require 127 to just get off
site seems a relatively unsophisticated policy. As I've mentioned,
Argonne's get-offsite-to-well-connected-peers-like-vBNS-and-ESNet TTL is 32.
Recall that the problem with large bandwidth multicast flows is that the
traditional DVMRP-based routing does flood-first-then-prune. Newer
multicast-BGP in cooperation with PIM sparse-dense mode is considerably
more sophisticated and forgiving. The Introduction to RFC 2365 discusses
the problems with DVMRP clearly.
Here are a couple of quotations from RFC 2365 (which defines administrative
In order to support administratively scoped IP multicast, a router
should support the configuration of per-interface scoped IP multicast
boundaries. Such a router, called a boundary router, does not forward
packets matching an interface's boundary definition in either direction
(the bi-directional check prevents problems with multi-access
networks). In addition, a boundary router always prunes the boundary
for dense-mode groups [PIMDM], and doesn't accept joins for sparse-mode
groups [PIMSM] in the administratively scoped range.
An administratively scoped IP multicast region is defined to be a
topological region in which there are one or more boundary routers
with common boundary definitions. Such a router is said to be a
boundary for scoped addresses in the range defined in its
Note that the very definition of administrative scope configuration is at
the router *interface* level. To define an administrative scope for
access-grid activities would require all networks carrying access-grid
traffic to classify their router interfaces either ACCESS_GRID_OK and
NOT_ACCESS_GRID_OK and assign administrative scope appropriately.
Implementing such a scope would require unprecedented cooperation across
all possible participating networks. EVERY multicast router interface at
the boundary of EVERY network participating in AG activities would have to
be evaluated and configured. This flies in the face of the effort to make
multicast routing ubiquitous everywhere.
Administrative scope makes sense where the boundaries of the multicast
session traffic match the boundaries of a network. In contrast, Access
Grid traffic uses many networks across many organizations. I believe that
it is, by definition, a high-bandwidth full MBONE application. If problems
with bandwidth overutilization are discovered, these should be treated as
drivers for MBONE re-engineering (especially site connection TTL policy
changes) as appropriate.
Bill Nickless http://www.mcs.anl.gov/people/nickless +1 630 252 7390
PGP:0E 0F 16 80 C5 B1 69 52 E1 44 1A A5 0E 1B 74 F7 nickless at mcs.anl.gov
More information about the ag-tech