IPPM Multicast metrics measurement

We supply infrastructure for retail service providers = to=20 deliver services to end user customers. This includes over one

hundred channels of video over multicast IP. This = amount of=20 multicast is far more traffic than our edge connections can

handle. Our network lives and dies on layer 2 = multicast=20 containment. Full containment is essential.

It appears to me that there are some scenarios where = the=20 *default* behavior specified in the IGMP snooping draft does not

scale adequately to provide sufficient flood protection= for=20 our application. While the draft does allow an option to contain

multicast traffic when leaves and joins (membership = reports)=20 have not been received, many vendors apply only the snooping

draft=92s *default* behavior.

My apologies in advance if I am incorrect and have = wasted=20 anyone=92s time with this very long post. Also, I am having a devil of a = time with=20 the formatting on this document. If it is difficult to read, I am = happy to=20 email a copy to anyone who so desires.

Please use Diagram 1 for all examples.

Issue #1:
When a snooping interface receives = packets for=20 which no IGMP leave or join has been received, the packet will be = flooded=20

automatically. This presents a problem when snooping=20= infrastructure is located between multicast routers using a flood and=20

prune protocol. If Router A and B are communicating = using a=20 flood and prune protocol, and we assume the 600Mbps of multicast

traffic, the houses (connected at 10Mbps) will most = likely=20 lose their ability to communicate with the network every time the =

Mcast routing protocol floods.

Issue #2:
I see the logic behind the default flood behavior. = But it=20 doesn=92t seem to offer us full protection against version

mismatches. The recommendation of setting the multicast router to = version 2=20 is not always an option for us because we are a carrier

supplying layer 2 VLANs to connect service providers with their = customers.=20 We do not have control over what equipment will be

deployed at end points of our network VLANs.

If switch B = is=20 IGMP version 2 snooping capable and receives an IGMP version 2 join for = channel=20 1 from house A, then receives

a version 3 join for channel 1 from house B, house B will not receive = the=20 requested channel.

Issue #3
The default implementation does not work for=20 multicast hosts directly connected to the layer 2 snooping domain. If a = customer=20

were to connect a multicast source to our network the *default* = flooding=20 behavior causes some strange things to occur.

Issue #4:
Also, with the default flood behavior we see = problems when=20 abnormal network events occur. With our application, receiving

unsolicited traffic causes major problems because core multicast = traffic=20 exceeds the bandwidth capacity of our edge devices.
(please see = diagram=20 1):
For this example each =93channel=94 refers to a ~4Mbps MPEG2 video = stream.=20 Assume house connections are 10Mbps and all others are

100Mbps.

1) Houses A,B and C are watching channels 2,3 and 4 respectively.= =20
2) Switch B resets due to momentary power failure and boots up = with no=20 IGMP snooping state.
3) When switch B comes back up it will still = be=20 receiving channels 2,3 and 4 from Switch A, but will have no IGMP

membership information.
4) Switch B will flood all 3 = channels to=20 houses A,B and C.
5) Channels 2,3 and 4 are ~4Mbps MPEG2 streams, = and=20 the houses connect to the network at 10Mbps. These 3 channels

represent more traffic than the house links can handle. This will = send more=20 data to these 3 houses than their network

connection can handle, possibly eliminating the hosts ability to = receive or=20 reply to the IGMP general query issued by Switch

A when it senses the =91link up=92 topology change, breaking their = network=20 connection until Router A times out the streams or

Switch A receives a leave for channels 2,3 and 4 from some other=20 port.

This behavior can probably be fixed if it is specified that the = switch MUST=20 refrain from flooding until it receives replies

to the general query issued after the =91link up=92 topology change = was=20 detected by switch A. The default contain and query

method outlined below seems to solve this also.

In an effort to address these issues I would like to propose one = possible=20 solution. Rather than flooding by default, using a

=91contain and query=92 method seems to solve some of these issues. = To achieve=20 this I would Change Section 8 from:

8) If a switch receives a *non* IGMP multicast packet without=20 having
first processed Membership Reports for the group address, it = MUST=20 for-
ward the packet on all ports. In other words, the switch = must=20 allow for the possibility that connected hosts and routers

have been upgraded to support future versions or extensions of IGMP = that=20 the switch does not yet recognize. A switch MAY have

a configuration option that suppresses this operation, but default = behavior=20 MUST be to allow flooding of unregistered

packets.

to read:

8) If a switch receives a *non* IGMP multicast stream without=20 having
first processed Membership Reports for the group address, it = MUST NOT=20 forward the packet on any port not attached to a

multicast router, but MUST issue an IGMP general query on all ports = except=20 the port receiving the stream. In other words, the

switch must allow for the possibility that connected hosts and = routers have=20 been upgraded to support future versions or

extensions of IGMP that the switch does not yet recognize, and must = ensure=20 that any router or host will recognize that there

is an older version of IGMP in use.

This appears to solve these issues:
1. Prune and flood = behavior=20 does not clog the links of edge hosts that cannot handle all multicast = channels=20 present in

the core.
2. When switch B resets, the streams are blocked = by=20 default until the hosts re-issue group membership reports in reply

to Switch B=92s general query.
3. House B will receive a = version 2=20 query from the switch and will begin using IGMP V2 to communicate. Even if = a=20 version

3 router is connected to the segment, the responses from house B = will=20 become version 2 (due to backwards compatibility

design) and the router will begin using version 2 on the interfaces=20= attached to our IGMP snooping segments, but still be able

to use version 3 on other segments.
4. Servers can be = attached=20 directly to layer 2 snooping infrastructure.

Of course the law of unforeseen consequences says that there are new = issues=20 with this method that I am not seeing =85

Diagram 1.

           =             &nb= sp;            =            =20 +-----------------+
        &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;=20 |     Router A    =20 |
           &nbs= p;            &= nbsp;           &nbs= p;          =20 +--------+--------+
        &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;         =20 |
           &nbs= p;          =20 +---------+          &nbs= p;  =20 +-------------------+         = =20 +-------------+
         &n= bsp;            = ;=20 | Host S1|--------------|     Switch=20 A      |-----------| Router B  =20= |
           &nbs= p;          =20 +---------+          &nbs= p;  =20 +-------------------+         = =20 +-------------+
         &n= bsp;            = ;            &n= bsp;            = ;  =20 |    |     |   =20 |
           &nbs= p;         =20 +---------------------------+    |    = =20 |   =20 +-----------------------------+
      &nbs= p;            &= nbsp; =20 |            &n= bsp;            = ; =20 +----+    =20 +----+           &nb= sp;            =     =20 |
           &nbs= p;      =20 |            &n= bsp;            = ;    =20 |            &n= bsp; =20 |            &n= bsp;            = ;   =20 |
         =20 +----------+          &nb= sp;        =20 +----------+      =20 +----------+          &nb= sp;         =20 +----------+
          | = Switch=20 B=20 |            &n= bsp;      =20 |Switch C |       |Switch D =20 |            &n= bsp;       =20 |Switch E |
         = =20 +----------+          &nb= sp;        =20 +----------+      =20 +----------+          &nb= sp;         =20 +----------+
         =20 |    |    =20 |            &n= bsp;      =20 |    |    =20 |       |   =20 |    =20 |            &n= bsp;       =20 |    |     |
Houses   = =20 A    B    =20 C            &n= bsp;      =20 D    E    =20 F       G   =20 H    =20 I            &n= bsp;       =20 J    K     L

Ben Carter
Network Analyst
Douglas County PUD
1151 Valley = Mall=20 Parkway
E. Wenatchee WA
98802
Voice: (509) 881-2486
Fax: = (509)=20 884-0553

--=_4A17A121.1879100B-- _______________________________________________ magma mailing list magma@ietf.org https://www1.ietf.org/mailman/listinfo/magma From magma-admin@ietf.org Mon May 13 05:35:00 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA01347 for ; Mon, 13 May 2002 05:35:00 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA18798; Mon, 13 May 2002 05:01:44 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA18783 for ; Mon, 13 May 2002 05:01:40 -0400 (EDT) Received: from p-mail2.rd.francetelecom.com (p-mail2.rd.francetelecom.com [193.49.124.32]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA01011 for ; Mon, 13 May 2002 05:01:28 -0400 (EDT) Received: by p-voyageur.rd.francetelecom.fr with Internet Mail Service (5.5.2655.55) id ; Mon, 13 May 2002 11:00:56 +0200 Message-ID: From: STEPHAN Emile FTRD/DAC/LAN To: Brian Haberman , MAGMA Mailing List Subject: RE: [magma] Agenda items? Date: Mon, 13 May 2002 11:00:43 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: multipart/mixed; boundary="----=_NextPartTM-000-7b1086aa-65be-11d6-b1eb-00508b69ab48" Sender: magma-admin@ietf.org Errors-To: magma-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Multicast and Anycast Group Membership X-BeenThere: magma@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------=_NextPartTM-000-7b1086aa-65be-11d6-b1eb-00508b69ab48 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1FA5C.A982CB46" ------_=_NextPart_001_01C1FA5C.A982CB46 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi all, Is there an interest to have a quick presentation of the framework of = the measurement of multicast metrics defined in the draft draft-stephan-ippm-multicast-metrics ? regards Emile -----Message d'origine----- De : Brian Haberman [mailto:bkhabs@nc.rr.com] Envoy=E9 : mercredi 8 mai 2002 23:19 =C0 : MAGMA Mailing List Objet : [magma] Agenda items? All, Please direct any agenda items for Yokohama to the chairs or the mailing list. Thanks, Brian & Bill _______________________________________________ magma mailing list magma@ietf.org https://www1.ietf.org/mailman/listinfo/magma ------_=_NextPart_001_01C1FA5C.A982CB46 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [magma] Agenda items?

Hi all,

Is there an interest to have a quick presentation of = the framework of the measurement of multicast metrics defined in the = draft draft-stephan-ippm-multicast-metrics ?

regards
Emile

-----Message d'origine-----
De : Brian Haberman [mailto:bkhabs@nc.rr.com]
Envoy=E9 : mercredi 8 mai 2002 23:19
=C0 : MAGMA Mailing List
Objet : [magma] Agenda items?

All,
Please direct any agenda items = for Yokohama to the chairs or
the mailing list.

Thanks,
Brian & Bill

_______________________________________________
magma mailing list
magma@ietf.org
https://www1.ietf.org/mailman/listinfo/magma

------_=_NextPart_001_01C1FA5C.A982CB46-- ------=_NextPartTM-000-7b1086aa-65be-11d6-b1eb-00508b69ab48-- _______________________________________________ magma mailing list magma@ietf.org https://www1.ietf.org/mailman/listinfo/magma From magma-admin@ietf.org Mon May 13 15:41:40 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA28791 for ; Mon, 13 May 2002 15:41:40 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA23416; Mon, 13 May 2002 06:33:05 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA23388 for ; Mon, 13 May 2002 06:33:00 -0400 (EDT) Received: from mail8.nc.rr.com (fe8.southeast.rr.com [24.93.67.55]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA02218 for ; Mon, 13 May 2002 06:32:48 -0400 (EDT) Received: from nc.rr.com ([24.162.252.183]) by mail8.nc.rr.com with Microsoft SMTPSVC(5.5.1877.757.75); Mon, 13 May 2002 06:32:59 -0400 Message-ID: <3CDF95A7.D580945A@nc.rr.com> Date: Mon, 13 May 2002 06:29:59 -0400 From: Brian Haberman X-Mailer: Mozilla 4.77 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: STEPHAN Emile FTRD/DAC/LAN CC: MAGMA Mailing List Subject: Re: [magma] Agenda items? References: Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Sender: magma-admin@ietf.org Errors-To: magma-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Multicast and Anycast Group Membership X-BeenThere: magma@ietf.org Content-Transfer-Encoding: 8bit Emile, I can add you to the agenda. How much time do you want? Regards, Brian > STEPHAN Emile FTRD/DAC/LAN wrote: > > Hi all, > > Is there an interest to have a quick presentation of the framework of > the measurement of multicast metrics defined in the draft > draft-stephan-ippm-multicast-metrics ? > > regards > Emile > > -----Message d'origine----- > De : Brian Haberman [mailto:bkhabs@nc.rr.com] > Envoy� : mercredi 8 mai 2002 23:19 > � : MAGMA Mailing List > Objet : [magma] Agenda items? > > All, > Please direct any agenda items for Yokohama to the chairs or > the mailing list. > > Thanks, > Brian & Bill > > _______________________________________________ > magma mailing list > magma@ietf.org > https://www1.ietf.org/mailman/listinfo/magma _______________________________________________ magma mailing list magma@ietf.org https://www1.ietf.org/mailman/listinfo/magma From magma-admin@ietf.org Mon May 13 15:42:42 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA28862 for ; Mon, 13 May 2002 15:42:42 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA28160; Mon, 13 May 2002 08:09:48 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA28118 for ; Mon, 13 May 2002 08:09:41 -0400 (EDT) Received: from p-mail2.rd.francetelecom.com (p-mail2.rd.francetelecom.com [193.49.124.32]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA05491 for ; Mon, 13 May 2002 08:09:26 -0400 (EDT) Received: by p-voyageur.rd.francetelecom.fr with Internet Mail Service (5.5.2655.55) id ; Mon, 13 May 2002 14:08:57 +0200 Message-ID: From: STEPHAN Emile FTRD/DAC/LAN To: Brian Haberman Cc: MAGMA Mailing List Subject: RE: [magma] Agenda items? Date: Mon, 13 May 2002 14:08:54 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: multipart/mixed; boundary="----=_NextPartTM-000-7b10974b-65be-11d6-b1eb-00508b69ab48" Sender: magma-admin@ietf.org Errors-To: magma-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Multicast and Anycast Group Membership X-BeenThere: magma@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------=_NextPartTM-000-7b10974b-65be-11d6-b1eb-00508b69ab48 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1FA76.F3B27BAA" ------_=_NextPart_001_01C1FA76.F3B27BAA Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Brian, I consider that 5 minutes presentations and 10 minutes discutions is suitable. The discutions may focus on the operational needs of standard metrics = for measuring the performance of the multicast services and on the security = and conformance aspects of measurement framework briefly described in the = draft. regards Emile -----Message d'origine----- De : Brian Haberman [mailto:bkhabs@nc.rr.com] Envoy=E9 : lundi 13 mai 2002 12:30 =C0 : STEPHAN Emile FTRD/DAC/LAN Cc : MAGMA Mailing List Objet : Re: [magma] Agenda items? Emile, I can add you to the agenda. How much time do you want? Regards, Brian > STEPHAN Emile FTRD/DAC/LAN wrote: >=20 > Hi all, >=20 > Is there an interest to have a quick presentation of the framework of > the measurement of multicast metrics defined in the draft > draft-stephan-ippm-multicast-metrics ? >=20 > regards > Emile >=20 > -----Message d'origine----- > De : Brian Haberman [mailto:bkhabs@nc.rr.com] > Envoy=E9 : mercredi 8 mai 2002 23:19 > =C0 : MAGMA Mailing List > Objet : [magma] Agenda items? >=20 > All, > Please direct any agenda items for Yokohama to the chairs or > the mailing list. >=20 > Thanks, > Brian & Bill >=20 > _______________________________________________ > magma mailing list > magma@ietf.org > https://www1.ietf.org/mailman/listinfo/magma ------_=_NextPart_001_01C1FA76.F3B27BAA Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [magma] Agenda items?

Brian,

I consider that 5 minutes presentations and 10 = minutes discutions is suitable.

The discutions may focus on the operational needs of = standard metrics for measuring the performance of the multicast = services and on the security and conformance aspects of measurement = framework briefly described in the draft.

regards
Emile

-----Message d'origine-----
De : Brian Haberman [mailto:bkhabs@nc.rr.com]
Envoy=E9 : lundi 13 mai 2002 12:30
=C0 : STEPHAN Emile FTRD/DAC/LAN
Cc : MAGMA Mailing List
Objet : Re: [magma] Agenda items?

Emile,
I can add you to the = agenda. How much time do you want?

Regards,
Brian

> STEPHAN Emile FTRD/DAC/LAN wrote:
>
> Hi all,
>
> Is there an interest to have a quick = presentation of the framework of
> the measurement of multicast metrics defined in = the draft
> draft-stephan-ippm-multicast-metrics ?
>
> regards
> Emile
>
> -----Message d'origine-----
> De : Brian Haberman [mailto:bkhabs@nc.rr.com]
> Envoy=E9 : mercredi 8 mai 2002 23:19
> =C0 : MAGMA Mailing List
> Objet : [magma] Agenda items?
>
> All,
> Please direct any = agenda items for Yokohama to the chairs or
> the mailing list.
>
> Thanks,
> Brian & Bill
>
> = _______________________________________________
> magma mailing list
> magma@ietf.org
> https://www1.ietf.org/mailman/listinfo/magma

------_=_NextPart_001_01C1FA76.F3B27BAA-- ------=_NextPartTM-000-7b10974b-65be-11d6-b1eb-00508b69ab48-- _______________________________________________ magma mailing list magma@ietf.org https://www1.ietf.org/mailman/listinfo/magma From magma-admin@ietf.org Mon May 13 20:12:55 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA10562 for ; Mon, 13 May 2002 20:12:55 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA05621; Mon, 13 May 2002 20:11:36 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA05601 for ; Mon, 13 May 2002 20:11:33 -0400 (EDT) Received: from mail-blue.research.att.com (mail-blue.research.att.com [135.207.30.102]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA10464 for ; Mon, 13 May 2002 20:11:19 -0400 (EDT) Received: from alliance.research.att.com (alliance.research.att.com [135.207.26.26]) by mail-blue.research.att.com (Postfix) with ESMTP id 40EA14CEDC; Mon, 13 May 2002 20:11:32 -0400 (EDT) Received: from windsor.research.att.com (windsor.research.att.com [135.207.26.46]) by alliance.research.att.com (8.8.7/8.8.7) with ESMTP id UAA09669; Mon, 13 May 2002 20:11:31 -0400 (EDT) From: Bill Fenner Received: (from fenner@localhost) by windsor.research.att.com (8.8.8+Sun/8.8.5) id RAA24200; Mon, 13 May 2002 17:11:31 -0700 (PDT) Message-Id: <200205140011.RAA24200@windsor.research.att.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII To: bcarter@dcpud.org Subject: Re: [magma] A issues for the IGMP snooping draft Cc: magma@ietf.org Date: Mon, 13 May 2002 17:11:30 -0700 Versions: dmail (solaris) 2.4/makemail 2.9b Sender: magma-admin@ietf.org Errors-To: magma-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Multicast and Anycast Group Membership X-BeenThere: magma@ietf.org Ben, The default in the draft was selected to favor forwards compatability. It does leave an out, as you quote: >8) If a switch receives a *non* IGMP multicast packet without having >first processed Membership Reports for the group address, it MUST forward >the packet on all ports. ... >... A switch MAY have a configuration option that suppresses >this operation, but default behavior >MUST be to allow flooding of unregistered This configuration option is there to ensure that in configurations like yours, traffic is limited to ports that explicitly requested it. Your suggestion of having the switch send explicit Queries seems like it opens up a huge can of worms; instead of that I'd suggest making the switch an IGMP Proxy router, so that it can be Querier on each port and make the upstream point to the router. Bill _______________________________________________ magma mailing list magma@ietf.org https://www1.ietf.org/mailman/listinfo/magma From magma-admin@ietf.org Tue May 14 15:24:38 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01994 for ; Tue, 14 May 2002 15:24:38 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA13608; Tue, 14 May 2002 15:23:54 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA13588 for ; Tue, 14 May 2002 15:23:53 -0400 (EDT) Received: from hotmail.com (f125.law12.hotmail.com [64.4.19.125]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01955 for ; Tue, 14 May 2002 15:23:39 -0400 (EDT) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Tue, 14 May 2002 12:23:21 -0700 Received: from 216.18.63.130 by lw12fd.law12.hotmail.msn.com with HTTP; Tue, 14 May 2002 19:23:21 GMT X-Originating-IP: [216.18.63.130] From: "rehan khan" To: magma@ietf.org Date: Tue, 14 May 2002 19:23:21 +0000 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 14 May 2002 19:23:21.0835 (UTC) FILETIME=[CF7803B0:01C1FB7C] Subject: [magma] (no subject) Sender: magma-admin@ietf.org Errors-To: magma-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Multicast and Anycast Group Membership X-BeenThere: magma@ietf.org Hi All, In an SSM environment what are the unique IP V4 multicast addresses. and, in a non ssm environment how many we have.. If there is a link that you could point me to, i would really appreicate that. Thanks _________________________________________________________________ Chat with friends online, try MSN Messenger: http://messenger.msn.com _______________________________________________ magma mailing list magma@ietf.org https://www1.ietf.org/mailman/listinfo/magma From magma-admin@ietf.org Fri May 17 00:20:24 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA21841 for ; Fri, 17 May 2002 00:20:24 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id AAA03443; Fri, 17 May 2002 00:20:08 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id AAA03418 for ; Fri, 17 May 2002 00:20:07 -0400 (EDT) Received: from webmail19.rediffmail.com (webmail19.rediffmail.com [203.199.83.29] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA21830 for ; Fri, 17 May 2002 00:19:50 -0400 (EDT) Received: (qmail 18842 invoked by uid 510); 17 May 2002 04:13:02 -0000 Date: 17 May 2002 04:13:02 -0000 Message-ID: <20020517041302.18841.qmail@webmail19.rediffmail.com> Received: from unknown (202.88.158.4) by rediffmail.com via HTTP; 17 May 2002 04:13:02 -0000 MIME-Version: 1.0 From: "Raja Reddy" Reply-To: "Raja Reddy" To: magma@ietf.org Content-type: text/plain; format=flowed Content-Disposition: inline Subject: [magma] Joining in MBone Sender: magma-admin@ietf.org Errors-To: magma-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Multicast and Anycast Group Membership X-BeenThere: magma@ietf.org Hello, I want to join in MBone. My Linux system running with mrouted. I know some multicast router ip addresses. Is it usefull for me ? please tell me that. If i create a tunnel with Multicast Router's IP address as tunnel end-point, can i get multicast packets ? Is remote router accepts my tunnel ? Please help me to join in MBone. From, P.Raja Reddy, Bangalore, India. _________________________________________________________ Click below to visit monsterindia.com and review jobs in India or Abroad http://monsterindia.rediff.com/jobs _______________________________________________ magma mailing list magma@ietf.org https://www1.ietf.org/mailman/listinfo/magma From magma-admin@ietf.org Fri May 31 07:32:43 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA11913 for ; Fri, 31 May 2002 07:32:43 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA25183; Fri, 31 May 2002 07:32:02 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA25158 for ; Fri, 31 May 2002 07:32:01 -0400 (EDT) Received: from ns1.thmulti.com (ns1.thmulti.com [141.11.234.67]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA11852 for ; Fri, 31 May 2002 07:31:33 -0400 (EDT) Received: from smtprelay2.thmulti.com (smtprelay2 [141.11.195.242]) by ns1.thmulti.com (8.9.3/8.9.1) with ESMTP id NAA25660 for ; Fri, 31 May 2002 13:31:28 +0200 (MET DST) Received: from parexch9.paris.thmulti.com (localhost [127.0.0.1]) by smtprelay2.thmulti.com (8.9.3/8.9.1) with ESMTP id NAA04360 for ; Fri, 31 May 2002 13:31:28 +0200 (MET DST) Received: by outlook.paris.thmulti.com with Internet Mail Service (5.5.2653.19) id <259HVYBF>; Fri, 31 May 2002 13:31:32 +0200 Message-ID: <421CB3B9B2D2F645B548D213C0A90E55187D47@edgmsmsg01.eu.thmulti.com> From: Dumet Sylvain To: "'magma@ietf.org'" Date: Fri, 31 May 2002 13:20:21 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [magma] IGMP v3 and Proxying Sender: magma-admin@ietf.org Errors-To: magma-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Multicast and Anycast Group Membership X-BeenThere: magma@ietf.org Hi, I have some issues with implementing IGMP proying with IGMP v3. Assume the following scenario 1- Host1 joins Stream A, specifying source A_1 2- Proxy device processes the request and joins Stream A specifying source A 3- Host2 joins Stream A, specifying source A_2 4- Proxy device combines the sources and reports Stream A, source A_1 and A_2? When the stream comes from a source (A_1 or A_2), the proxy device can forward it to both hosts but Host1 wants that stream from source A_1 only, same for Host2 that requires stream from source A_2 only. What will happen? I did not find any related topic in IGMPv3 draft and IGMP proxy draft. Did anyone already encounter that issue? How did you fix it? Regards, Sylvain _______________________________________________ magma mailing list magma@ietf.org https://www1.ietf.org/mailman/listinfo/magma From magma-admin@ietf.org Fri May 31 07:50:02 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA12387 for ; Fri, 31 May 2002 07:50:02 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA25853; Fri, 31 May 2002 07:48:24 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA25835 for ; Fri, 31 May 2002 07:48:23 -0400 (EDT) Received: from multicasttech.com (IDENT:root@lennon.multicasttech.com [63.105.122.7]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA12343 for ; Fri, 31 May 2002 07:47:55 -0400 (EDT) Received: from [68.100.2.42] (account ) by multicasttech.com (CommuniGate Pro WebUser 3.4.8) with HTTP id 1366160; Fri, 31 May 2002 07:48:22 -0400 From: "Marshall Eubanks" Subject: Re: [magma] IGMP v3 and Proxying To: Dumet Sylvain , "'magma@ietf.org'" X-Mailer: CommuniGate Pro Web Mailer v.3.4.8 Date: Fri, 31 May 2002 07:48:22 -0400 Message-ID: In-Reply-To: <421CB3B9B2D2F645B548D213C0A90E55187D47@edgmsmsg01.eu.thmulti.com> MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Sender: magma-admin@ietf.org Errors-To: magma-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Multicast and Anycast Group Membership X-BeenThere: magma@ietf.org Content-Transfer-Encoding: 8bit On Fri, 31 May 2002 13:20:21 +0200 Dumet Sylvain wrote: > Hi, > > I have some issues with implementing IGMP proying with IGMP v3. > > Assume the following scenario I am not sure I understand this. By IGMPv3 do you mean SSM ? If so, Stream "A" from source A_1 could be totally separate from Stream "A" from source A_2, and I know of no way to ensure that this is not the case. If you mean ASM, then I do not see why IGMPv3 is different from v2. If Host 1 and Host 2 are on the same LAN, they will both get both (S,G)'s at the NIC card and both (if the channels use the same "G" == your Stream "A" above) will process both sets of packets, only to reject the unwanted ones somewhere in the kernel / application stack. Because of the limits of the multicast MAC address, this is also true for a set of other G's that map to the same MAC address. Regards Marshall Eubanks > 1- Host1 joins Stream A, specifying source A_1 > 2- Proxy device processes the request and joins Stream A specifying > source A > 3- Host2 joins Stream A, specifying source A_2 > 4- Proxy device combines the sources and reports Stream A, source > A_1 and A_2? > > When the stream comes from a source (A_1 or A_2), the proxy device can > forward it to both hosts but Host1 wants that stream from source A_1 only, > same for Host2 that requires stream from source A_2 only. What will happen? > > I did not find any related topic in IGMPv3 draft and IGMP proxy draft. > > Did anyone already encounter that issue? How did you fix it? > > Regards, > Sylvain > > _______________________________________________ > magma mailing list > magma@ietf.org > https://www1.ietf.org/mailman/listinfo/magma _______________________________________________ magma mailing list magma@ietf.org https://www1.ietf.org/mailman/listinfo/magma From magma-admin@ietf.org Fri May 31 08:04:55 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA12818 for ; Fri, 31 May 2002 08:04:55 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA27124; Fri, 31 May 2002 08:03:48 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA27098 for ; Fri, 31 May 2002 08:03:47 -0400 (EDT) Received: from sophia.inria.fr (sophia.inria.fr [138.96.64.20]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA12785 for ; Fri, 31 May 2002 08:03:19 -0400 (EDT) Received: from localhost (odie.inria.fr [138.96.88.52]) by sophia.inria.fr (8.11.6/8.11.6) with ESMTP id g4VC3Dd10399; Fri, 31 May 2002 14:03:13 +0200 X-Authentication-Warning: sophia.inria.fr: Host odie.inria.fr [138.96.88.52] claimed to be localhost Date: Fri, 31 May 2002 14:03:13 +0200 (MEST) Message-Id: <20020531.140313.56567492.Hitoshi.Asaeda@sophia.inria.fr> To: DumetS@thmulti.com Cc: magma@ietf.org Subject: Re: [magma] IGMP v3 and Proxying From: Hitoshi Asaeda In-Reply-To: <421CB3B9B2D2F645B548D213C0A90E55187D47@edgmsmsg01.eu.thmulti.com> References: <421CB3B9B2D2F645B548D213C0A90E55187D47@edgmsmsg01.eu.thmulti.com> X-Mailer: Mew version 2.2rc1 on Emacs 21.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: magma-admin@ietf.org Errors-To: magma-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Multicast and Anycast Group Membership X-BeenThere: magma@ietf.org Content-Transfer-Encoding: 7bit > Assume the following scenario > > 1- Host1 joins Stream A, specifying source A_1 > 2- Proxy device processes the request and joins Stream A specifying > source A > 3- Host2 joins Stream A, specifying source A_2 > 4- Proxy device combines the sources and reports Stream A, source > A_1 and A_2? > > When the stream comes from a source (A_1 or A_2), the proxy device can > forward it to both hosts but Host1 wants that stream from source A_1 only, > same for Host2 that requires stream from source A_2 only. What will happen? It doesn't depend on "proxy" or "IGMPv3 capable router". On your condition, Host1 only receives A_1's data and Host2 only receives A_2's data, even proxy or upstream router forwards A_1's and A_2's data. In both nodes, Stream A is received by physical link layer and transfered to IP layer, but unneeded packet (i.e. non-joined (S,G) data) is just dropped by UDP layer. This behavior can be implemented by the IGMPv3 capable kernel of each host. > I did not find any related topic in IGMPv3 draft and IGMP proxy draft. It may be unclear. But INCLUDE/EXCLUDE mode defines "source filter". This implies above behavior. > Did anyone already encounter that issue? How did you fix it? Nothing would be fixed, I think. -- Hitoshi Asaeda _______________________________________________ magma mailing list magma@ietf.org https://www1.ietf.org/mailman/listinfo/magma From magma-admin@ietf.org Fri May 31 12:20:12 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA21306 for ; Fri, 31 May 2002 12:20:07 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA18647; Fri, 31 May 2002 12:13:55 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA18599 for ; Fri, 31 May 2002 12:13:48 -0400 (EDT) Received: from dcpud.org (proxy.dcpud.org [208.8.202.67]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA21083 for ; Fri, 31 May 2002 12:13:22 -0400 (EDT) Received: from DCPUD_MAIL-Message_Server by dcpud.org with Novell_GroupWise; Fri, 31 May 2002 09:13:22 -0700 Message-Id: X-Mailer: Novell GroupWise Internet Agent 5.5.5.1 Date: Fri, 31 May 2002 09:13:15 -0700 From: "Ben Carter" To: , Subject: Re: [magma] A issues for the IGMP snooping draft Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=_306DF632.D0B1D803" Sender: magma-admin@ietf.org Errors-To: magma-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Multicast and Anycast Group Membership X-BeenThere: magma@ietf.org This is a MIME message. If you are reading this text, you may want to consider changing to a mail reader or gateway that understands how to properly handle MIME multipart messages. --=_306DF632.D0B1D803 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Bill, Thanks for the reply. The query idea does seem to be an overly complex method. I am convinced, = however, that the default flood behavior has major issues. While I can see what the draft was trying to achieve with the default = flood behavior, I don't think these goals have been achieved. It doesn't = provide adequate flood protection and isn't very future proof. (IMHO) My example #2 shows how a host running a 'new' IGMP version will be = ignored if it is connected to the same snoopy switch as a 'current' = version host subscribing to the same group. Also, there is no protection = from unsolicited multicast (from a multicast router running an older flood = and prune protocol for example).=20 To me it seems unwise to give up backward compatibility in an effort to = guess what requirements will achieve forward compatibility. Thanks Ben Ben Carter Network Analyst Douglas County PUD 1151 Valley Mall Parkway E. Wenatchee WA 98802 Voice: (509) 881-2486 Fax: (509) 884-0553 >>> Bill Fenner 05/13/02 05:11PM >>> Ben, The default in the draft was selected to favor forwards compatability. It does leave an out, as you quote: >8) If a switch receives a *non* IGMP multicast packet without having >first processed Membership Reports for the group address, it MUST forward >the packet on all ports. ... >... A switch MAY have a configuration option that suppresses >this operation, but default behavior >MUST be to allow flooding of unregistered =20 This configuration option is there to ensure that in configurations like yours, traffic is limited to ports that explicitly requested it. Your suggestion of having the switch send explicit Queries seems like it opens up a huge can of worms; instead of that I'd suggest making the switch an IGMP Proxy router, so that it can be Querier on each port and make the upstream point to the router. Bill _______________________________________________ magma mailing list magma@ietf.org https://www1.ietf.org/mailman/listinfo/magma --=_306DF632.D0B1D803 Content-Type: text/html; charset=ISO-8859-1 Content-Description: HTML Content-Transfer-Encoding: quoted-printable

Bill,

Thanks for the reply.

The query idea does seem to be an overly complex method. I am = convinced,=20 however, that the default flood behavior has major issues.

While I can see what the draft was trying to achieve with the default = flood=20 behavior, I don't think these goals have been achieved. It doesn't = provide=20 adequate flood protection and isn't very future proof. (IMHO)

My example #2 shows how a host running a 'new' IGMP version will = be=20 ignored if it is connected to the same snoopy switch as a 'current'=20= version host subscribing to the same group. Also, there is no = protection=20 from unsolicited multicast (from a multicast router running an older f= lood=20 and prune protocol for example).

To me it seems unwise to give up backward compatibility in an effort = to=20 guess what requirements will achieve forward compatibility.

Thanks

Ben

Ben Carter
Network Analyst
Douglas County PUD
1151 Valley = Mall=20 Parkway
E. Wenatchee WA
98802
Voice: (509) 881-2486
Fax: = (509)=20 884-0553

>>> Bill Fenner <fenner@research.att.com>=20= 05/13/02 05:11PM >>>

Ben,

The default in the = draft=20 was selected to favor forwards compatability.
It does leave an out, as = you=20 quote:

>8) If a switch receives a *non* IGMP multicast packet = without=20 having
>first processed Membership Reports for the group address, it = MUST=20 forward
>the packet on all ports. ...
>... A switch MAY = have a=20 configuration option that suppresses
>this operation, but default=20 behavior
>MUST be to allow flooding of unregistered

Thi= s=20 configuration option is there to ensure that in configurations
like = yours,=20 traffic is limited to ports that explicitly requested it.

Your = suggestion=20 of having the switch send explicit Queries seems like
it opens up a = huge can=20 of worms; instead of that I'd suggest making
the switch an IGMP Proxy = router,=20 so that it can be Querier on each port
and make the upstream point to = the=20 router.

=20 Bill

_______________________________________________
magma = mailing=20 list
magma@ietf.org
https://www1.ietf.org= /mailman/listinfo/magma

--=_306DF632.D0B1D803-- _______________________________________________ magma mailing list magma@ietf.org https://www1.ietf.org/mailman/listinfo/magma