Agreed that the SGSN do not know how to multicast. If it were able to, as Ethernet switches do, then scaling would not be a problem. If the mobile-to-GGSN subnet is /127, as you are hinting, then all the mobiles either have the same IP or the GGSN has 100K IP interfaces.
My suggestions would be to not limit the L3 capability to what is available today in 3G L2 switches. Subrata -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of [EMAIL PROTECTED] Sent: Monday, May 27, 2002 3:11 AM To: [EMAIL PROTECTED] Subject: RE: MLD comments on cellular host drafts - seeking feedback Sorry, that isn't the correct model. 3GPP uses a "stratified" model. The link layer from the mobiles ends in the GGSN. There is also another link layer, between the SGSN and the GGSN, but that is in the lower stratum that is invisible to the mobiles. Always think about the mobile-GGSN link as a single hop. The difference is architecturally important. For example, the mobiles are *not* neighbors to each other, even when they are connected to the same Access Point (in 3GPP terminology). The links are only point-to-point, and nobody else is present. The reason is security. There can be 100k or more mobiles connected to a single AP. If they were all on the same link, any multicast operation could crash the GGSN, because it might have to replicate the packet 100k times. Also, any mobile could launch multicast-based DoS attacks against the GGSN or other mobiles. In brief, 3GPP networks cannot handle multicast (or DAD) in Ethernet manner. The numbers differ by severals orders of magnitude. -- Lassi > -----Original Message----- > From: ext Dr. Subrata Goswami [mailto:[EMAIL PROTECTED]] > Sent: Friday, May 24, 2002 9:58 PM > To: [EMAIL PROTECTED] > Subject: RE: MLD comments on cellular host drafts - seeking feedback > > > I do not think we can ignore the rest of the network. The > SGSN needs a > mechanism to populate its forwarding table with mcast addresses - > that is where MLD snooping comes in. > > Is the following a good representation of a cellular network ? > > > IPL1 IPR1 > Mobile 1--------(SGSN)------\ > (GGSN)--> > Mobile 2--------(SGSN)------/ > IPL2 IPR2 > > I am saying IPR1 = IPR2 , hence IPL1, IPL2, IPR1 all are on the same > link as SGSN are L2 devices. So if Mobile 1 subscribes to a > link-local > group and so does Mobile 2, then we need mcast forwarding between > them. Next question would be what are IPL1, IPL2, and IPRx - global, > site-scope,link-local unicat addresses ? > > Subrata. > > > -----Original Message----- > From: Hesham Soliman (ERA) [mailto:[EMAIL PROTECTED]] > Sent: Friday, May 24, 2002 11:28 AM > To: 'Dr. Subrata Goswami'; Hesham Soliman (ERA) > Subject: RE: MLD comments on cellular host drafts - seeking feedback > > > > > Are you sure that the BTS does not terminate the radio link > > - physically > > => Yes. I'm assuming you're still talking about WCDMA. > > > that looks like the spot for termination. Okay, if the IP > > stack sees a L3 > > p2p link, then the IP address on the GGSN interface is same > > for a number of > > mobile hosts - right ? So the GGSN has to know which of > the mobiles > > connected to it need mcast group traffic, right ? > > => But we're not talking about mcast addresses in general, > we're talking about link-local mcast addresses. For those > addresses you don't need to join on a p2p link. > > Similarly > > the SGSN also > > needs to know which links it needs to copy an mcast group > packet to. > > => No. The SGSN is not involved in any routing. The > _only_ node that does routing is the GGSN. We can > ignore the rest of the network as far as the IETF > is concerned. Or at least as far this WG is concerned. > > Hesham > > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to [EMAIL PROTECTED] > -------------------------------------------------------------------- > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to [EMAIL PROTECTED] -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to [EMAIL PROTECTED] --------------------------------------------------------------------
