Subject: can ssm and non-ssm colide ?

From: "Dany Shterman" <[email-masked]>
Date: Thu, 23 Nov 2000 16:39:42 -0000

Hi.
I understand that a router can have 2 types of multicast forwarding rules:

1. (S,D) : i.e do multicast to a packet that arrives with IP destination   
"d" and IP source "s" iff S=="s" and D=="d". 2. (*,D) : i.e do multicast to 
a packet that arrives with IP destination   "d" iff D=="d".

Questions:
a. is it true ?
b. is it possible that a router will have 2 contradicting forwarding   rules 
: (S,D) and (*,D) that direct traffic to 2 different ports,   for the same 
IP destination address D ?
c. If the answer to the previous question is true, then to what port   
should the router forward ?

ThankX.
Dan

_____________________________________________________________________________________
Get more from the Web.  FREE MSN Explorer download : http://explorer.msn.com

---

From: Marshall Eubanks <[email-masked]>
Date: Thu, 23 Nov 2000 13:33:55 -0500

> should the router forward ?

Sorry - this was sent too soon - here is the final

Dear Dan;

What exactly do you mean ? Is D the multicast class D address ? This
is generally called "G", for the group. It is NOT a destination.

Remember, SSM and ISM address ranges are supposed to be disjoint - 
(S,G) is allowed in a SSM range, but (*,G) is supposed to be
filtered out. So this cannot occur in a proper SSM implementation. If  you
tried to do ISM in the SSM address space, it wouldn't work.

In PIM-SM ISM, 
a (*,G) JOIN and an (S,G) join certainly could have different directions -
generally, they would. It also is always possible to have the same
data arriving at a router from two directions - this is also supposed
to be detected and pruned.(SSM could have this too.)

In general, these situations are supposed to be detected and pruned
off as soon as possible.

From 
http://www.ietf.org/internet-drafts/draft-ietf-pim-sm-v2-new-00.txt

  At the end of phase 2, traffic will be flowing natively from S along a
  source-specific tree to the RP, and from there along the shared tree to
  the receivers.  Where the two trees intersect, traffic may transfer from
  the source-specific tree to the RP tree, and so avoid taking a long
  detour via the RP.

and 

  All of these problems are caused by there being more than one upstream
  router with join state for the group or source-group pair.  PIM does not
  prevent such duplicate joins from occurring - instead when duplicate
  data packets appear on the LAN from different routers, these routers
  notice this, and then elect a single forwarder.  This election is
  performed using PIM Assert messages, which resolve the problem in favor
  of the upstream router which has (S,G) state, or if neither or both
  router has (S,G) state, then in favor of the router with the best metric
  to the RP for RP trees, or the best metric to the source to source-
  specific trees.

I BELIEVE that if there is both (S,G) and (*,G) forwarding state,
that the (S,G) list is searched first and then the (*,G) is used only if
there is no (S,G) match, but I cannot (as I wait for the turkey to cook)
find any documentation that confirms this.

                                   Regards
                                   Marshall Eubanks

   Multicast Technologies, Inc.
   10301 Democracy Lane, Suite 201
   Fairfax, Virginia 22030
   Phone : 703-293-9624          Fax     : 703-293-9609     
   e-mail : [email-masked]     http://www.on-the-i.com

---

From: Marshall Eubanks <[email-masked]>
Date: Thu, 23 Nov 2000 13:13:19 -0500

In PIM-SM ISM, 
a (*,G) JOIN and an (S,G) join certainly could have different directions -
generally, they would. You could, for instance, be sending
encapsulated multicasts to the RP, and then having them multicasted
back to a receiver on the same LAN as you, so that the same data flow
along the pipe in both directions.

From 

                                   Regards
                                   Marshall Eubanks

---

From: Mark Handley <[email-masked]>
Date: Thu, 23 Nov 2000 11:40:30 -0800

>find any documentation that confirms this.

It's in the "Data Packet Forwarding Rules" in Section 4.2.

A couple of provisos modify what you said above:

 - if there's (S,G) state, then the packet will be forwarding using a
   combination of both (S,G) and (*,G) state if it arrived on the
   correct interface to have come from S.

 - if the packet arrived on the correct interface to have come from
   the RP (and not from S), then it will only be forwarded using
   purely (*,G) state if the SPTbit for (S,G) is false (indicating the
   the (S,G) forwarding state is not yet active).

Cheers,
	Mark

---

From: Jaiwant Mulik <[email-masked]>
Date: Thu, 23 Nov 2000 15:18:41 -0500 (EST)

Hi,

What again is ISM (I know SSM) ?

bye,

>    e-mail : [email-masked]     http://www.on-the-i.com

Jaiwant Mulik                            
-----------------------------------------------------------------------
Email        : [email-masked] (preferred), [email-masked]
Home page    : http://unix.temple.edu/~jmulik
Office hours : Mon: 10:30-12:30, Tue: 2:00-4:00, Wed: 2:40-4:40
Location     : Room 1043/1044, Wachman Hall.       
Phones       : (215) 204-3197 (o), (215) 777-4828 (r)
-----------------------------------------------------------------------
Lekin woh zindagi he kya, jisme koi namumkin sapna na ho ?

"Lets look at this from a logical point of view" - Prof. in class.

---

From: Ross Finlayson <[email-masked]>
Date: Thu, 23 Nov 2000 16:26:44 -0800

>What again is ISM (I know SSM) ?

The term "ISM" ("Internet Standard Multicast") describes the current IP 
multicast model, in which joins are done to multicast group addresses only, 
and packets are received regardless of the sender.

By the way, I have to say that I dislike the term "ISM".  It's misleading, 
because SSM is likely to also be a standard someday.

Instead, I'd like to suggest the term "Source-Independent Multicast" 
("SIM").  This is not only more descriptive, but also more contrasts better 
with "Source-Specific Multicast".

         Ross.

---

From: Hugh Holbrook <[email-masked]>
Date: Fri, 24 Nov 2000 03:03:35 -0800 (PST)

> From: Ross Finlayson <[email-masked]>
>

We used the term ISM in the first version of the SSM architecture
document.  Susequently, Brad and I both agreed that we didn't like it
very much for the reasons you mention.  We got a handful of
consultations and then we switched to Any-Source Multicast (ASM) to
describe the RFC1112 multicast model.  I like SIM well enough, but ASM
is pretty similar to SIM, to my thinking, and it appears now i
draft-holbrook-ssm-arch-00.txt.  I'm not inclined to change the name
again unless there is strong sentiment to do so.  Is there?

-Hugh

---

From: "Michael Luby" <[email-masked]>
Date: Fri, 24 Nov 2000 10:16:28 -0800

Ross,
I feel and have felt for some time the same way about the naming of ISM.  It
isn't symmetric with the naming of SSM, and does give the impression that
one is a standard and the other is something else.  I like your suggestion
of calling the original model of multicast SIM instead of ISM, it seems to
be the perfect name!
Mike

-----Original Message-----
From: Ross Finlayson [mailto:[email-masked]]
Sent: Thursday, November 23, 2000 4:27 PM
To: Jaiwant Mulik
Cc: [email-masked]
Subject: Re: can ssm and non-ssm colide ?

         Ross.

---

From: "Lee, Jiwoong" <[email-masked]>
Date: Sat, 25 Nov 2000 09:25:07 +0900

Good points.
Well-categorized names will be good.
BTW ISM(or whatever) and SSM belong to explicit multicast and explicit
multicast
is just one (efficient) way to realize multicast. Therefore, number of soure
might not
be a good discriminant in a wide view.

The name ISM surely is misleadeing.

"Generic multicast" was a my alternative to call *ISM*, though I don't
recommend to use it.

Jiwoong

----- Original Message -----
From: "Michael Luby" <[email-masked]>
To: "Ross Finlayson" <[email-masked]>; "Jaiwant Mulik"
<[email-masked]>
Cc: <[email-masked]>
Sent: Saturday, November 25, 2000 3:16 AM
Subject: RE: can ssm and non-ssm colide ?