Subject: MLD comments on cellular host drafts - seeking feedback

From: "Hesham Soliman (ERA)" <[email-masked]>
Date: Thu, 23 May 2002 17:33:57 +0200

Hi, 

I've tried to summarise the current situation
with MLD and see how we can move forward with
the next revisions of the draft. 
Jari will send another emails for the rest of 
the issues discussed. 

First let me summarise the comments:

- MLD must be used for all multicast addresses
except the all nodes multicast address. This 
is what RFC2710 says. 

My understanding (please correct me if I'm wrong)
was that the need for using MLD for link-scope
addresses was to allow for the cases where L2
switches snoop MLD reports. 

As far as the cellular host is concerned, we 
are dealing with p2p links where the neighbour 
is a default router. So for link local traffic
in general the notion of multicast does not 
exist (even if, for example an RS is sent to the 
all routers multicast address, it is going to
one router). And there are no switches that will
need to snoop MLD traffic.

Sending MLD reports for link local addresses, 
will not only increase the use of BW on the 
links but is unnecessary for this p2p link. 
However, MLD will be necessary for multicast 
addresses with scopes larger than the link
scope. 

So based on the dicussion above, we have
a number of choices for the next update:

1. Suggest that MLD must be used even for link
local addresses in p2p links within cellular
networks (3GPP). 

pros: We follow RFC 2710.
cons: Waste of expensive BW unnecessarily

2. We suggest that for these p2p links, with
no switches snooping MLD traffic, MLD should 
only be used for multicast addresses with scopes
larger than link-local.

pros: We save expensive BW
cons: We don't follow RFC2710, but then again
      RFC2710 does not make a clear distinction 
      between these p2p links and other multicast links.

3. We suggest that this exception (of not using MLD for 
link-local multicast traffic) can be made, until
RFC2710 is updated to explain why the mandate 
was placed and whether there should be any exceptions
to that mandate. 

pros: We also minimise the scope of the exception 
      to 3GPP only.

cons: We still don't follow this particular part 
      of RFC2710  

I look forward to your choices from the above
selection :) or even new suggestions. 

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-masked]
--------------------------------------------------------------------

---

From: "Hesham Soliman (ERA)" <[email-masked]>
Date: Fri, 24 May 2002 20:15:53 +0200

> The L2 p2p link ends at the BTS (?) , but the L3 subnet 
  > ends at GGSN (?)

=>  Not quite. The 'link', as seen by the IP stack, is p2p
between the host and the GGSN.

  > which is a router. BTS supports multiple p2p links, any of 
  > them can have a
  > mcast listener. So the BTS needs a way to figure out to 
  > which L2 p2p link a
  > mcast packet needs to be forwarded. Without MLD support, 
  > how does the L2
  > switch know there is a mcast listener in the link so it can 
  > copy  a packet
  > to that link ?  The only other way would be to manually 
  > configure the L2
  > switch - not scalable.

=> The BTS (node B) is not a switch and doesn't
even terminate the radio link, so it can't route
traffic directly between hosts. The _only_ node
that can do that is the default router (GGSN). 
You can think of it as any p2p link used today.

Hesham

---

From: "Hesham Soliman (ERA)" <[email-masked]>
Date: Fri, 24 May 2002 20:17:40 +0200

> 
  > this was a good summary. So how about going for alternative 3?
  > 

=> I think either 2 or 3 are fine. So, yes, 3 is ok.

Hesham

---

From: "Dr. Subrata Goswami" <[email-masked]>
Date: Fri, 24 May 2002 11:57:44 -0700

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-masked]]
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

---

From: "Peter Hedman (EMP)" <[email-masked]>
Date: Wed, 29 May 2002 07:52:21 +0200

Hi,

I think it is worth looking into figure 2 in draft-ietf-ipv6-3gpp-recommend-02.txt.
Unless this figure gets corrupt in the mail you'll see that there are 2 different IP layers and the cellular host draft is talking about the IP layer between MS and GGSN.

/Peter

  ------
 |      |
 |  App |- - - - - - - - - - - - - - - - - - - - - - - - -(to app peer)
 |      |
 |------|                                              -------------
 |  IP  |- - - - - - - - - - - - - - - - - - - - - - -|      IP     |->
 | v4/6 |                                             |     v4/6    |
 |------|      -------------       -------------      |------       |
 |      |     |  \ Relay /  |     |  \ Relay /  |     |      |      |
 |      |     |   \     /   |     |   \     /   |     |      |      |
 |      |     |    \   /    |     |    \   /    |     |      |      |
 | PDCP |- - -| PDCP\ /GTP_U|- - -|GTP_U\ /GTP_U|- - -|GTP_U |      |
 |      |     |      |      |     |      |      |     |      |      |
 |------|     |------|------|     |------|------|     |------|      |
 |      |     |      |  UDP |- - -|  UDP |  UDP |- - -| UDP  |      |
 |      |     |      |------|     |------|------|     |------|      |
 |  RLC |- - -|  RLC |  IP  |- - -|  IP  |  IP  |- - -| IP   |      |
 |      |     |      | v4/6 |     | v4/6 | v4/6 |     |v4/6  |      |
 |------|     |------|------|     |------|------|     |------|------|
 |  MAC |     |  MAC | AAL5 |- - -| AAL5 |  L2  |- - -| L2   |  L2  |
 |------|     |------|------|     |------|------|     |------|------|
 |  L1  |- - -|  L1  |  ATM |- - -|  ATM |  L1  |- - -| L1   |  L1  |
  ------       -------------       -------------       -------------

    UE             UTRAN                SGSN                GGSN

> From: Dr. Subrata Goswami [mailto:[email-masked]]
> Sent: den 28 maj 2002 19:19
> To: [email-masked]
> Hesham, SGSN "sees" the mobile's traffic - as it passes through it.
> SGSN being an L2 device for IP, it is capable of doing L2 
> switching (if
> the 3gpp spec does not prohibit and the vendor innovates).  The
> following is the protocol stack for the SGSN (user plane, from the TS
> 23.060 you referred, btw the 3GPP web-site needs better navigation). 
> 
> -------------              ---------------
> |SNDCP GTP-U|              |GTP-U   GTP-U |
> |LLC   UDP  |              |UDP/IP  UDP/IP|
> |BSSGP IP   |              |AAL5    L2    |
> |FR    L2   |              |ATM     L1    |
> |L1    L1   |              ---------------
> ------------
> GPRS-SGSN                  UMTS-SGSN
> 
> From the above, it is possible to make GPRS-SGSN to mcast as it
> detunnels the IP packets.
> 
> In case of UMTS, the same functionality can be in the UTRAN.
> 
> Subrata
> 
> 
> Sent: Tuesday, May 28, 2002 4:44 AM
> To: 'Dr. Subrata Goswami'; [email-masked];
> [email-masked]
>   > > Sorry, that isn't the correct model.
>   > 
>   > Then it is the correct model, if you read my email it was 
>   > mentioned that
>   > SGSN is an L2 device. Also as one SGSN supports multiple 
>   > mobiles - it needs
>   > to know somehow which mobiles are part of an mcast group 
>   > and that can be
>   > done by MLD.
> 
> => No. The model is not correct as we tried to 
> explain. The SGSN does not 'see' the mobile's
> traffic and does not do any 'L2 switching'. 
> So your conclusion is not correct.
> 
> For more information, please refer to 3GPP
> specs: TS 23.060 (any revision will explain
> this issue clearly).
> 
> Hesham
> 
> 
>

---

From: [email-masked]
Date: Wed, 29 May 2002 10:54:51 +0300

...but how about mobility?

The SGSN isn't an anchor point. It may change at any moment, when the mobile does an SGSN handover to another Routing Area. The new SGSN doesn't have a clue about what mcast groups the mobile has joined somewhere else.

The old SGSN might inform the new one about the groups, but that is architecturally messy. So far GPRS is pretty agnostic about what protocol the mobile uses - IPv4, IPv6, X.25(!), or even PPP. Integrating IPv6 mcast functions would violate the idea. It would also mean that the SGSN has an IP interface that the mobile can see. That violates the stratified model.

The feature would still need to be standardised as an extra parameter in GTP-C. Not all SGSNs in a network come from the same vendor. 3GPP does have an unwritten prohibition: disallow non-standard features that would lock an operator to a single vendor.

-- Lassi

> From: ext Dr. Subrata Goswami [mailto:[email-masked]]
> Sent: Tuesday, May 28, 2002 8:19 PM

---

From: "Hesham Soliman (ERA)" <[email-masked]>
Date: Wed, 29 May 2002 12:26:10 +0200

Lassi and Subrata, 

You are right of course, but I think we can get
into this endless loop of discussions because 
of a simple fact: We are not discussing 
the way 3GPP _can_ or might work. We are
discussing the facts as we have them today. 
So can we accept that this _is_ the way 3GPP
networks work (as described by Lassi and myself
in earlier emails) and go from there? 
If this simple fact can't be accepted then we're
not going to end up with a resolution. 

Hesham

  > From: [email-masked] 
  > [mailto:[email-masked]]
  > Sent: Wednesday, May 29, 2002 9:55 AM
  > The SGSN isn't an anchor point. It may change at any 
  > moment, when the mobile does an SGSN handover to another 
  > Routing Area. The new SGSN doesn't have a clue about what 
  > mcast groups the mobile has joined somewhere else.
  > 
  > The old SGSN might inform the new one about the groups, but 
  > that is architecturally messy. So far GPRS is pretty 
  > agnostic about what protocol the mobile uses - IPv4, IPv6, 
  > X.25(!), or even PPP. Integrating IPv6 mcast functions 
  > would violate the idea. It would also mean that the SGSN 
  > has an IP interface that the mobile can see. That violates 
  > the stratified model.
  > 
  > The feature would still need to be standardised as an extra 
  > parameter in GTP-C. Not all SGSNs in a network come from 
  > the same vendor. 3GPP does have an unwritten prohibition: 
  > disallow non-standard features that would lock an operator 
  > to a single vendor.
  > 
  > -- Lassi
  >

---

From: [email-masked]
Date: Thu, 30 May 2002 11:03:22 +0300

Hi all,

> not going to end up with a resolution. 

This document is not intending to describe new behavior
for IPv6 or 3GPP networks.  The focus is what is needed
on the cellular host so that the cellular host behaves
like a proper IPv6 node, when attached to a 3GPP network.
Doing anything more than this is simply out of scope
for this document.

John