Subject: [magma] MSNIP behavior in ad-hoc networks

From: Brian Haberman <[email-masked]>
Date: Mon, 13 Jan 2003 19:37:01 -0500

All,
      There is one open issue with the MSNIP specification.
The point was raised in Atlanta, that MSNIP does not provide
source control when there are no routers present on the link.
This occurs mainly in ad-hoc networks.

      The question for the group is whether there is consensus
to develop a mechanism to allow for source control in the
ad-hoc scenario.

      The current specification allows for the disabling of
MSNIP when no routers are present.  This removes the need for
any node on the network to assume the MSNIP router role.  But,
it does not provide the ability to constrol mcast transmits.

      I would like to hear arguments for or against adding
additional machinery to MSNIP to support the ad-hoc network.

Regards,
Brian

_______________________________________________
magma mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/magma

---

From: Toerless Eckert <[email-masked]>
Date: Mon, 13 Jan 2003 16:44:41 -0800

I would not want to delay MSNIP due to this particular functionality.

I am also not sure wether this actually should be a feature of MSNIP,
or wether this wouldn't rather be better solved by hosts listening
to other IGMP membership reports, and if those membership reports are
not sufficent to learn members in a non-router network, isn't it then
IGMP itself that should be improved toward that end ?

Cheers
	Toerless

---

From: Toerless Eckert <[email-masked]>
Date: Mon, 13 Jan 2003 16:44:41 -0800

Cheers
	Toerless

---

From: Haixiang He <[email-masked]>
Date: Tue, 14 Jan 2003 10:29:17 -0500

I am little confused. In the latest spec msnip-01.txt, section 4.2., we
have:

"Link without multicast routing:
     The IP system should use as the MSNIP managed range the default SSM

     range of 232/8 defined in [6]. This allows directly connected
     receivers to perform the router side of the MSNIP protocol and
     control the source transmission within the default SSM range."

Is this sufficient to provide source control in SSM range for ad-hoc
network environment?

Haixiang

---

From: Haixiang He <[email-masked]>
Date: Tue, 14 Jan 2003 10:29:17 -0500

Haixiang

---

From: Brian Haberman <[email-masked]>
Date: Tue, 14 Jan 2003 10:37:20 -0500

> Is this sufficient to provide source control in SSM range for ad-hoc

The issue is asking a host to perform router functions in this
scenario.  Using the default SSM range is fine.  But there are
security and functionality issues with asking a host to make an
arbitrary decision to start acting like a router.

If we ask hosts to add this feature, then we have to go all the
way and include: an election mechanism, an override mechanism
for when a router becomes active, and a full security assessment
of that model.

Brian

---

From: Brian Haberman <[email-masked]>
Date: Tue, 14 Jan 2003 10:37:20 -0500

Brian

---

From: Haixiang He <[email-masked]>
Date: Tue, 14 Jan 2003 11:15:11 -0500

> for when a router becomes active, and a full security assessment

Do you mean IGMP router part functions or MSNIP router part functions?
According to my understanding, in non-router environment, a receiver host only
needs to perform the router part of MSNIP, not the IGMP router part.

Actually in Atlanta IETF, I raise the issue related to the state information
maintained in the multicast source host (MSNIP host). I still think the
current state record format is not appropriate for non-router environment. So
I support the idea of disabling MSNIP in non-router environment.

Haixiang

---

From: Haixiang He <[email-masked]>
Date: Tue, 14 Jan 2003 11:15:11 -0500

Haixiang

---

From: Brian Haberman <[email-masked]>
Date: Tue, 14 Jan 2003 13:09:13 -0500

> Do you mean IGMP router part functions or MSNIP router part functions?

I am talking about the MSNIP router function.

> needs to perform the router part of MSNIP, not the IGMP router part.

All receivers?  One receiver?  If one, which one?

> I support the idea of disabling MSNIP in non-router environment.

Thanks for the input.

Brian

---

From: Brian Haberman <[email-masked]>
Date: Tue, 14 Jan 2003 13:09:13 -0500

Thanks for the input.

Brian

---

From: Haixiang He <[email-masked]>
Date: Tue, 14 Jan 2003 13:20:25 -0500

> All receivers?  One receiver?  If one, which one?

My understanding is that all receivers.

haixiang

---

From: Haixiang He <[email-masked]>
Date: Tue, 14 Jan 2003 13:20:25 -0500

haixiang

---

From: Isidor Kouvelas <[email-masked]>
Date: Tue, 14 Jan 2003 11:05:58 -0800

Brian,

I must have missed your last message so I am responsing to the one
from Haixiang.

MSNIP capable source hosts do explicit tracking of first-hop routers.
Therefore in an ad-hoc network they would explicitly track the
interest of each receiver and no election would be required.
BTW I do not think there is a state problem on the source host with
doing explicit tracking as the number of active groups from a source
times the number of first-hop boxes requesting the traffic for each
group should not be too large.

I had forgotten that the paragraph that Haixiang pointed at which
specifies the use of the default ssm-range in an ad-hoc net was in the
spec.  The implication is that MSNIP works in an ad-hoc network as
long as receiving hosts are updated to issue MSNIP Receiver Membership
Reports.  The *big* drawback is that in an ad-hoc network, for a group
in the default SSM range a legacy receiver will not be able to tell an
MSNIP capable source that it wants traffic.

So the current version of the spec supports ad-hoc but compromises
compatibility in a very specific scenario. I can keep it this way or
change the ad-hoc SSM case to flooding depending on what people think
is best.

thanks
Isidor

---

From: Isidor Kouvelas <[email-masked]>
Date: Tue, 14 Jan 2003 11:05:58 -0800

Brian,

thanks
Isidor

---

From: Brian Haberman <[email-masked]>
Date: Tue, 14 Jan 2003 15:09:41 -0500

> change the ad-hoc SSM case to flooding depending on what people think

Speaking as a WG member, I prefer the option of flooding when the
source detects that there are no routers on the network.  When a
router does appear, the reception of IGMPv3 Queries and MSNIP
Receiver Reports will cause the sender to transmit HIS messages
and revert to be managed.

Regards,
Brian

---

From: Brian Haberman <[email-masked]>
Date: Tue, 14 Jan 2003 15:09:41 -0500

Regards,
Brian

---

From: Haixiang He <[email-masked]>
Date: Tue, 14 Jan 2003 15:51:33 -0500

> group should not be too large.

I still don't really buy this argument. Let's explore the argument from the IGMP
point of view and this is also where I am coming from. In terms of maintaining
state information, we can sort of say that IGMP router part equals MSNIP host part.
If your above argument is true, then IGMP router can also do explicit tracking per
interface. This can greatly simplify the IGMP protocol. (of course, people can
argue that a router has many interfaces.)

I am not old enough to know all the design rationale. I personally think
documenting the rationale is not a bad thing.

Regards

haixiang

---

From: Haixiang He <[email-masked]>
Date: Tue, 14 Jan 2003 15:51:33 -0500

Regards

haixiang

---

From: Enhui Liu <[email-masked]>
Date: Wed, 15 Jan 2003 17:13:30 +0800

Hi,

I have a problem. How to deploy IP multicast on an enterprise network built with L:2 switches as backbone and L3 switches / routers as egress? It means that transmitters and receivers all in a large LAN.

thanks,
Enhui Liu

---

From: Enhui Liu <[email-masked]>
Date: Wed, 15 Jan 2003 17:13:30 +0800

Hi,

thanks,
Enhui Liu

---

From: Marshall Eubanks <[email-masked]>
Date: Wed, 15 Jan 2003 06:35:10 -0500

1.) You should think about investing in IGMP snooping switches unless 
the multicasts are going to pretty much everyone on the
LAN.
2.) These sorts of questions are better handled on the IPMulticast 
mailing list, which we expect to host after this week

http://www.servicenetworks.com/SNEditorial/forums.asp#IPMulticast

Marshall

On Wednesday, January 15, 2003, at 04:13  AM, Enhui Liu wrote:

> Hi,
>
> I have a problem. How to deploy IP multicast on an enterprise network 
> built with L:2 switches as backbone and L3 switches / routers as 
> egress? It means that transmitters and receivers all in a large LAN.
>
> thanks,
> Enhui Liu
                                  Regards
                                  Marshall Eubanks

T.M. Eubanks
Multicast Technologies, Inc.
10301 Democracy Lane, Suite 410
Fairfax, Virginia 22030
Phone : 703-293-9624       Fax     : 703-293-9609
e-mail : [email-masked]
http://www.multicasttech.com

Test your network for multicast :
http://www.multicasttech.com/mt/
  Status of Multicast on the Web  :
  http://www.multicasttech.com/status/index.html

---

From: Marshall Eubanks <[email-masked]>
Date: Wed, 15 Jan 2003 06:35:10 -0500

Marshall

                                  Regards
                                  Marshall Eubanks

T.M. Eubanks

---

From: Marshall Eubanks <[email-masked]>
Date: Wed, 15 Jan 2003 06:35:10 -0500

Marshall

                                  Regards
                                  Marshall Eubanks

T.M. Eubanks

---

From: Marshall Eubanks <[email-masked]>
Date: Wed, 15 Jan 2003 06:35:10 -0500

Marshall

                                  Regards
                                  Marshall Eubanks

T.M. Eubanks

---

From: Bill Nickless <[email-masked]>
Date: Wed, 15 Jan 2003 15:23:10 -0600

At 05:13 PM 1/15/2003 +0800, Enhui Liu wrote:
>built with L:2 switches as backbone and L3 switches / routers as egress? 
>It means that transmitters and receivers all in a large LAN.

Enhui,

There are some options other than so-called "native" multicast that you 
might want to consider.

What is your application for multicast service?

How large is the L2 LAN?  How many hosts?  How many of those LAN hosts are 
expected to receive multicast traffic?  How many of those LAN hosts are 
expected to transmit multicast traffic?  How many LAN hosts are expected to 
receive traffic from a given multicast source/group?

===
Bill Nickless    http://www.mcs.anl.gov/people/nickless      +1 630 252 7390
PGP:0E 0F 16 80 C5 B1 69 52 E1 44 1A A5 0E 1B 74 F7     [email-masked]

---

From: Bill Nickless <[email-masked]>
Date: Wed, 15 Jan 2003 15:23:10 -0600

Enhui,

===