Subject: PIM SM

From: "Frank P. Troy" <[email-masked]>
Date: Fri, 14 Nov 1997 10:10:29 +0000

Can anyone tell me why PIM Sparse Mode encapsuluates the initial 
datagrams to the RP in a register message as opposed to sending them
natively?

Thanks
--------------------------------------------
Frank P. Troy          Phone:   703-471-3694
Sr. Network Engineer   Fax:     703-471-1575
AT&T DISC Development  Page:    888-808-0593 
3001 Centreville Rd.   e-mail:  [email-masked]    
Herndon, VA 20171

---

From: "Matt Crawford" <[email-masked]>
Date: Fri, 14 Nov 1997 09:56:46 -0600

> datagrams to the RP in a register message as opposed to sending them

Yes.

You can't send a multicast packet *to* the RP if the RP hasn't joined
the group.  The register message prompts the RP to join.

---

From: Beau Williamson <[email-masked]>
Date: Fri, 14 Nov 1997 10:43:40 -0600

Frank,

I'm not sure what you mean by "sending them natively" in this context.
However, I'll try to explain why it works the way it does.

The reason the first hop router sends register messages initially is that
we want the RP to respond by "joining" the SPT (Shortest Path Tree) rooted
at the source to "pull" the packets down to the RP.  (In the mean time the
RP will de-encapsulate the packets in the register message and forward them
down the Shared tree.) 

Remember that in Sparse mode we are operating in an explict join model
where we "join" a tree (Shared or SPT) to "pull" the traffic down the tree.
 The key here is that traffic never flows "up" trees in PIM.  Therefore,
even if the first hop router had "joined" the Shared tree (rooted at the
RP) for the group, it can't send packets "up" the Shared tree.  This means
that some other mechanism must be employed to get the traffic to the RP so
that it can flow "down" the Shared tree.  

In summary, the Register messages serve two purposes, 1) to get the
"initial" multicast packets to the RP for forwarding down the shared tree
and 2) to trigger the RP to "join" the SPT for the source so packets can be
sent "natively" down the SPT to the RP.

Clear as mud, huh.  (Sometimes this stuff makes your brain hurt.)

Beau Williamson

---

From: [email-masked] (Deborah Estrin)
Date: Fri, 14 Nov 1997 09:17:11 -0800 (PST)

Delivery-Date: Fri, 14 Nov 1997 06:27:32 PST
   Comments: Authenticated sender is <[email-masked]>
   From: "Frank P. Troy" <[email-masked]>
   MIME-Version: 1.0
   Content-type: text/plain; charset=US-ASCII
   Content-transfer-encoding: 7BIT
   Priority: normal
   X-mailer: Pegasus Mail for Win32 (v2.53/R1)
   Precedence: bulk

   Thanks

PIM-SM uses a unidirectional shared tree...so that it can be very
careful about checking that packets are only accepted on the incoming
interface that points toward the root of the tree (ie toward teh RP).
SO a packet coming FROM a receiver does not go natively unless and
until the RP joins back to that specific source and so there is a
branch whose incoming interface checks in the nodes point back toward
the source.

For high data rate sources you alwasy set up source specific branches
. Forr low data rate sources you encapsulate packets ot eh RP and hten
they go natively. 

If you did not encapsulate you would have to mess with the forwardign
path of all packets which is a big performance hit, or set up a
bidirection tree, which might well be a good idea (we are taking this
approach for inter-domain BGMP) but conflicts with the ability to use
source specific trees/branches in some cases (it is a longer
story...see the BGMP I-D for some explanation)...So for PIM-SM we made
the design tradeoff decision to encapsulate initial packets to the
RP...

Maybe more than you wanted to knwo...but if less, ask me for relevant
papers :}

---

From: Dino Farinacci <[email-masked]>
Date: Fri, 14 Nov 1997 12:41:34 -0800 (PST)

>> datagrams to the RP in a register message as opposed to sending them

    Because the RP doesn't know ahead of time where the sources are. It only
    knows when they send by receiving Register messages. Then, the RP has the
    option to join back to the source to receive data natively.

    The RP stands for Rendezvous Point, which is the place where sources and
    receivers rendezvous. This is so existing sources can get data to newly 
    joined receivers and new sources can get data to existing receivers.

Dino