Subject: mrouted/DVMRP and IPv6

From: [email-masked] (Bill Fink)
Date: Fri, 11 Apr 1997 19:12:57 -0400 (EDT)

Can the existing deployed mrouted and DVMRP protocol be used to
distribute IPv6 routing prefixes?  If not, how much work would
be required to allow them to do so?

I'm thinking of the following application.  In the ATM world,
using MARS to handle the IP multicast forwarding for a particular
set of IPv4 subnets (cluster) that is part of the ATM infrastructure,
the MARS server would basically coalesce all the constituent members
of the cluster into a single IPv6 routing prefix that was logically
associated with the cluster.  An mrouted affiliated with the MARS
server would then distribute the multicast route for the IPv6 routing
prefix as just another subnet, albeit a slightly different kind,
that participates in the normal IP multicast routing and forwarding.
A member of the cluster that joined a multicast group would effectively
be joining within the IPv6 subnet, and would receive multicast traffic
for that group by having it forwarded normally to the IPv6 subnet,
at which point the MARS server would distribute it to any members
of the cluster which had joined the group.  This would help in the
scaling of IPv4 over ATM multicast, and might even be useful for
non-ATM situations as well.

This is part of a larger effort I've been investigating of finding
better ways for creating an effective synergy between the technological
capabilities of the IP(v4/v6) Internet and a global ATM infrastructure.
By recognizing the commonality of functionality and requirements between
the IP and ATM universes, and avoiding unnecessary duplication of effort,
it should allow each technology to take maximal advantage of the strengths
of the other with a minimum of effort.

						-Bill

---

From: Dino Farinacci <[email-masked]>
Date: Fri, 11 Apr 1997 22:01:53 -0700 (PDT)

>> be required to allow them to do so?

    No, because the mask encoding is 3 bytes and the network number encoding
    is 4 bytes in length.

>> non-ATM situations as well.

    Why, why, why? What are you trying to solve with this complex solution?

>> of the other with a minimum of effort.

    Take a look at our web page at ftp://ftpeng.cisco.com/ipmulticast.html
    for possible solutions to running IP multicast over ATM.

Dino

---

From: Petri Helenius <[email-masked]>
Date: Sat, 12 Apr 1997 10:06:55 +0300 (EEST)

> of the other with a minimum of effort.
I think this is best accomplished by applying PIM point-to-multipoint
with ATM<-->IP address mapping for neighbor addressing discovery.

Pete

---

From: [email-masked] (Bill Fink)
Date: Mon, 14 Apr 1997 23:21:16 -0400 (EDT)

>     No, because the mask encoding is 3 bytes and the network number encoding

I was afraid that was the case.

>     Why, why, why? What are you trying to solve with this complex solution?

There's nothing particularly complex about it.  The multicast cluster
can be thought of as being somewhat analogous to an OSPF area, i.e. some
set of IP regions specified by a route prefix and associated mask.  The
IPv6 subnet prefix/mask would act as a multicast cluster ID, analogous
to an OSPF area ID.  I'm just suggesting that instead of advertising
many IPv4 subnet prefixes/masks for a given multicast cluster, that only
a single IPv6 subnet prefix/mask be advertised instead.  Also, since
IPv6 addresses have an extensive hierarchical structure, multiple such
IPv6 subnet prefixes/masks could potentially be aggregated even further
at higher levels of the hierarchy.  In the global Internet, it could mean
that instead of having to carry around 50,000 or more multicast routes,
only a fairly small number of multicast routes would be needed in the
default free zone.

Since the current mrouted/DVMRP doesn't support IPv6, one workaround
would be to use an IPv4 multicast cluster ID.  This would have the
advantage of working with the current mrouted/DVMRP, and still only
require a single multicast route to be advertised for the multicast
cluster, but unlike the IPv6 option, the opportunity to do further
route aggregation would be greatly reduced.

>     for possible solutions to running IP multicast over ATM.

All of the options listed there for doing IP multicast over ATM seem
to require static configuration of the ATM multipoint receivers.  I
want an option that supports dynamic leaf initiated joins, shortcut
routing across LIS boundaries, supports both ATM hosts and routers,
minimizes latency and protocol overhead, and is simple, manageable,
and scalable.  I believe an integrated IP(v4/v6) and ATM addressing
and routing scheme, based on the ideas presented in the IRA Model I-D
(http://www.nasa.atd.net/draft-fink-ipatm-ira-00.html), can effectively
accomplish all of this in a very simple and easily implementable manner.
I do need to update the IRA Model I-D to add a section on multicast
support and to reflect input I received on the original I-D, such as
using an ATMARP/MARS server instead of having the ATM hosts directly
doing the mapping between IP and ATM addresses.

						-Bill

---

From: [email-masked] (Bill Fink)
Date: Mon, 14 Apr 1997 23:34:53 -0400 (EDT)

> with ATM<-->IP address mapping for neighbor addressing discovery.

Pete,

I think we're in agreement.  My IRA Model does ATM<-->IP address mapping
for shortcut IP/ATM routing, and you could probably use PIM
point-to-multipoint to handle the router-to-router IP multicast
forwarding.  I'm just suggesting that you then use MARS to handle
the router to ATM host(s) multicast distribution.

						-Bill

---

From: Petri Helenius <[email-masked]>
Date: Tue, 15 Apr 1997 08:59:49 +0300 (EEST)

> the router to ATM host(s) multicast distribution.
I've always been in the opinion that MARS is kind of overcomplicated
for quite a basic task. So I would say that since the hosts need to be
changed anyway, why not implement p2mp PIM on them. It does require
only sending IGMP messages upstream and accepting the leaf of VC
that's offered to you. Rooting VC's at workstations is not really
neccessary.

Pete

---

From: [email-masked] (Bill Fink)
Date: Tue, 15 Apr 1997 03:28:57 -0400 (EDT)

> that's offered to you. Rooting VC's at workstations is not really

My revised version of the IRA Model (which I need to write up) doesn't
require any changes to hosts (it's all hidden inside the ATMARP/MARS
server).  I don't think I want to hardcode a particular multicast routing
protocol in the hosts (even though I happen to like PIM), especially
since a standard intra-domain IP multicast routing protocol hasn't been
selected yet, such as OSPF in the unicast arena.

						-Bill

---

From: Petri Helenius <[email-masked]>
Date: Tue, 15 Apr 1997 11:59:18 +0300 (EEST)

> selected yet, such as OSPF in the unicast arena.
Sending IGMP packets over the p2p VC to the nearest router (ARP
server) does not get a classification of 'hardcoded routing protocol'
in my vocabulary.
It just leaves a lot of doors open for different implementations and
requires minimal changes to the host software.

Pete

---

From: Jon Crowcroft <[email-masked]>
Date: Tue, 15 Apr 1997 12:11:57 +0100

make arp and igmp messages fit in 1 cell, use VCI/VPI 
number derived from the snap type field, and honour ttl, and then you
could do naive mode IP on ATM 'casting :-)

could even use fast leave and join to do SMART style mpt-mpt tree
sharing whwere people don't have RM cells.....

 >that's offered to you. Rooting VC's at workstations is not really

 jon

---

From: [email-masked] (Bill Fink)
Date: Tue, 15 Apr 1997 18:56:18 -0400 (EDT)

> requires minimal changes to the host software.

OK, that doesn't sound unreasonable.  When you initially spoke of
implementing p2mp PIM on the hosts, I thought that meant they would
have to know the details of PIM operation.  IGMP over a p2p VC to
the nearest mc router (ARP server) seems fine.

I gather that when the mc router receives the IGMP join message,
it would add the host as a new leaf on the p2mp VC for the mc group,
so that the router itself wouldn't have to replicate the packets.
That would mean that all p2mp VCs are rooted at the mc router.  I
don't think that's a major consideration, but there could be some
implications on scaling and performance issues.

How is the sending side handled?  Do you basically just have a
default multicast route via the mc router?

						-Bill

---

From: Petri Helenius <[email-masked]>
Date: Wed, 16 Apr 1997 14:30:05 +0300 (EEST)

> the nearest mc router (ARP server) seems fine.

Exactly my point.
 > it would add the host as a new leaf on the p2mp VC for the mc group,

Yes.

 > That would mean that all p2mp VCs are rooted at the mc router.  I

Correct again.

 > implications on scaling and performance issues.

I would rather say that doing the replication in the router would have
major effect in scaling and performance.
 > default multicast route via the mc router?
Yes. You either root your own VCs (complicated) or send data over your
p2p VC to the first hop router which takes care of forwarding to other
clients in the same LIS and to external destinations.

Pete

---

From: [email-masked] (Bill Fink)
Date: Thu, 17 Apr 1997 21:44:51 -0400 (EDT)

> major effect in scaling and performance.

I would agree that the router having to do the replication would have
a major effect on scaling and performance, but there is still an issue,
although admittedly a somewhat lesser one, on making all multicast
traffic pass through the router's ATM link, which has a limited
capacity.  For example, with the scheme you propose, even purely
local multicast sessions, which in principle shouldn't need to bother
the router at all, would require their traffic to compete for resources
with all other local and non-local multicast sessions at least at that
ATM link to the router.

						-Bill

---

From: Petri Helenius <[email-masked]>
Date: Fri, 18 Apr 1997 08:00:57 +0300 (EEST)

> with all other local and non-local multicast sessions at least at that
True. But since the router has to listen to the local multicast
traffic anyway, sending it back on another VC is usually non-issue.

Pete