Subject: Re: New draft on embedding the RP address in IPv6 multicast address

From: Brian Haberman <[email-masked]>
Date: Thu, 10 Oct 2002 13:56:16 -0400

Mike O'Connor wrote:
> Hi Brian,
> 
> I don't understand how the reciever's RP receives the "owning RP"
> address for a given multicast group. How are the "owning RP" addresses
> distributed between domains without PIM flooding?

The RP address is embedded in the multicast address.  The key is in the
assignment of multicast addresses in a domain and the configuration of
RP addresses.

So, if a domain uses prefix 3ffe:1:2::/48.  It places an RP in the
network and gives it an address of 3ffe:1:2:3::5.  Now, this RP can
be the RP for the multicast address range FF7x:0540:3ffe:1:2:3::/96.
The key is that the IID portion of the RP's address is set to a value
that can be encode in the RPad field of the multicast address.  The
mcast groups are distinguished by the lower 32 bits of the address.

Now, a receiver's RP can examine the multicast address when it is
creating state and reconstruct the owning RP's address by extracting
the network prefix value and appending the RPad field.

Brian

---

From: "Mike O'Connor" <[email-masked]>
Date: Thu, 10 Oct 2002 10:40:59 -0700

[ post by non-subscriber.  with the massive amount of spam, it is easy to
  miss and therefore delete mis-posts.  so fix subscription addresses! ]

Hi Brian,

> This is actually what is expected to happen.  The steps look like:
>
>      1. A receiver finds out a group address from some means
>         (e.g. SDR or a web page)
>      2. The receiver issues an MLD Report Joining the group
>      3. The receiver's DR will initiate the PIM Join process
>      4. The Join message flows up to the receivers RP
>      5. The RP recognizes the embedded RP format and extracts
>         the owning RP address
>      6. The receiver's RP issues an SPT join to the owning RP
>         and creates forwarding state

--
Mike O'Connor,                  E-mail: [email-masked]
Network Engineer                Energy Sciences Network (ESnet)
East coast: +1 631 344-7410     West coast: +1 510 486-7421
Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab)

-----Original Message-----
From: Brian Haberman [mailto:[email-masked]] 
Sent: Thursday, October 10, 2002 1:30 PM
To: Marshall Eubanks
Cc: Mike O'Connor; Pekka Savola; [email-masked];
[email-masked]; [email-masked]
Subject: Re: New draft on embedding the RP address in IPv6 multicast
address

Marshall Eubanks wrote:
> Yes, I think so, this requires interdomain flooding, just like
> interdomain MSDP in IPv4.

Actually, I don't think it does.  See comments below.

> 
> However, you might be able to make ASM "SSM like" in that, if you find

> the group address by some means out of band, you can join to the RP 
> and either send or receive.

This is actually what is expected to happen.  The steps look like:

      1. A receiver finds out a group address from some means
         (e.g. SDR or a web page)
      2. The receiver issues an MLD Report Joining the group
      3. The receiver's DR will initiate the PIM Join process
      4. The Join message flows up to the receivers RP
      5. The RP recognizes the embedded RP format and extracts
         the owning RP address
      6. The receiver's RP issues an SPT join to the owning RP
         and creates forwarding state

One possible optimization is that the receiver's DR could issue the SPT
to the owning RP.

The sender side has two cases.

      1. A sender in the owning domain.  Nothing should be different
         here.

      2. A sender in a foreign domain.  This is the case that I
         have to do some work on.  In order for a receiver in
         another domain to know about this sender, information will
         have to flow to the owning RP.

> 
> It is also not clear to me how this would work in, say, a
> teleconference. Doesn't it limit the group to only _one_ RP? What 
> functionality does it give that either SSM or MSDP doesn't ?

One big advantage is the removal of inter-domain MSDP state.  And the
use of one RP is a downside of this approach.

Brian