Subject: Question about Hosts sending in SM.

From: Shahzad Ali <[email-masked]>
Date: Thu, 7 Jan 1999 08:45:37 -0500 (EST)

Hi,

I have a question about hosts sending in PIM-SM.

Consider this topology:

         (DR)
RP-----RTA---------RTB------Source
  1   2	  1   |   2   1
	      |
	      |
	    Recv

Note:  The numbers are the interface numbers.

1. Recv Joins.  As RTA is the DR and not RTB, the states are as follows.

	RTA: (*, G), iif=2, oif={1}
	RTB: None (The source is not sending yet).
	RP : (*, G), iif=register, oif={1}

2.  Source starts sending.  The traffic starts off as register traffic.

	RTA: (*, G), iif=2, oif={1}
	RTB: (S, G), iif=1, oif={register_encap_to_rp}
	RP : (*, G), iif=register, oif={1}

3.  Now lets assume that the RP tries to switch to native instead of
registers.  That is where I cant understand how things are supposed to
happen. 

	RP : (*, G), iif=register, oif={1}
	     (S, G), iif=1, oif={NULL}

With this state, how can the RP send a join towards RTA for (S, G)?  Or is
it that there is no need for a join.  

Note, I am just talking about the source switching to native packets
till the RP and not till the receiver.

Thanks.

-Shahzad Ali
EE Grad University of Delaware.
Software Engineer, Torrent Networking Tech.

---

From: Timothy T Graefe <[email-masked]>
Date: Thu, 07 Jan 1999 11:58:36 -0500

> it that there is no need for a join.

The RP will still send a join towards RTA. The fact that the oif listis NULL
for a particular (S,G) does not create a problem.  RTA will
receive the join and create state for (S,G), and propagate the join.
When RTB receives the join it copies the current oif list for (*,G)
(oif={}) to the new (S,G) entry, and then adds the new interface
(interface 2) to the list (oif={2}).

The route entries then become:

RP:  (*,G), iif={},  oif={1}
     (S,G), iif={1}, oif={}
RTA: (*,G), iif={2}, oif={1}
     (S,G), iif={1}, oif={2}
RTB: (S,G), iif={1}, oif={2}

RTB continues to send Registers towards RP, but it also forwards native
multicast on interface 2.  The native multicast packets will find their
way to RP, which will send RegisterStops back to RTB.  RP now receives
native multicast for (S,G).  Even though it's oif list is NULL, it does
not send a prune towards RTB, because it is an RP.

An interesting aspect of this example is that the receiver (Recv) is
switched to the shortest path tree, even though it's last-hop router
towards the source (RTB) did not make the request.  This happens
with PIM-SM in other topologies as well.

Cheers,
Tim Graefe

---

From: Shahzad Ali <[email-masked]>
Date: Thu, 7 Jan 1999 14:19:01 -0500 (EST)

> for a particular (S,G) does not create a problem.  RTA will

That is what I thought the answer should be.  But according to the spec, I
could not find a case where an RP will send a join, even though the entry
has a NULL oif.  The only such case is when there is a local receiver on
the incoming interface and the router is a DR on the interface.

The steps that are taken after this initial join can be found in the spec
as well.

-Shahzad

---

From: Pavlin Ivanov Radoslavov <[email-masked]>
Date: Thu, 07 Jan 1999 12:34:23 -0800

> the incoming interface and the router is a DR on the interface.

In the example above, the RP will create the (S,G) entry (with
oifs=NULL), but will never send Join/Prune message toward S (see
last line in section 3.3.2). Thus, the switch to the SPT will never
be completed, because no native mcast packets will be received by
RP.
The register messages from RTB will still be accepted
and forwarded on the (*,G) entry (this forwarding rule is covered in
bullet 3 in section 3.4).

In this particular example (i.e. I am the RP with (*,G) oifs !=
NULL; (S,G) oifs = NULL), the RP could send the (S,G) Join toward S,
but this is not in the spec, and IMHO should be done at the
discretion of the implementor :)

Pavlin

---

From: Shahzad Ali <[email-masked]>
Date: Thu, 7 Jan 1999 15:59:45 -0500 (EST)

> be completed, because no native mcast packets will be received by

Thanks Pavlin,

That means that the switch will never be accomplished.  So the (*, G)
forwarding entry will be used for ever.  Is there a way in which this
(S,G) entry can be removed in any way or will it stick around.  

And if this is the case, then I think, there is no need for a join also. A
join will just mean native traffic for the RP which the RP doesnt need in
the first place.

-Shahzad Ali

---

From: Timothy T Graefe <[email-masked]>
Date: Thu, 07 Jan 1999 16:11:21 -0500

> be completed, because no native mcast packets will be received by

I had thought that the last line in sec. 3.3.2 applied to periodicjoin/prunes, and
that the triggered join/prune would still be
sent when the (S,G) entry was created (see next to last line in
3.3.2).  However, I suppose it doesn't make much sense to
join a tree if you don't have any downstream interfaces.

Thanks,
Tim Graefe

---

From: Pavlin Ivanov Radoslavov <[email-masked]>
Date: Thu, 07 Jan 1999 13:41:26 -0800

> sent when the (S,G) entry was created (see next to last line in

My interpretation was that this rule always applies (someone who
wrote the spec can be the judge :)

> join a tree if you don't have any downstream interfaces.

Right. Pulling down the mcast traffic natively is just an
optimization which you may do (to avoid traffic duplication overhead
and decapsulation overhead), but it is questionable whether it
worths the additional complexity.

Pavlin

---

From: Pavlin Ivanov Radoslavov <[email-masked]>
Date: Thu, 07 Jan 1999 13:28:29 -0800

> (S,G) entry can be removed in any way or will it stick around.  

(To be more specific, the (S,G) will be deleted after no data has
forwarded on it after some amount of time, but if the datarate is
keeps being high, it will be periodically recreated)

You can get rid of that (S,G) with the additional explicit rule that
the RP doesn't initate switch to the SPT if the oifs of the
eventually created (S,G) will be NULL.

> join will just mean native traffic for the RP which the RP doesnt need in

If the multicast traffic doesn't come to RP natively, it must come
as Registers. If the RP pulls down natively the mcast traffic from
Source, it will avoid the decapsulation overhead AND duplicating it
over links RP-RTA and RTA-RTB (first as Register, and second
natively).

Pavlin