Subject: Re: [multimob] Fwd: New Version Notification for draft-ietf-multimob-pmipv6-base-solution-05

From: "Seil Jeon" <[email-masked]>
Date: Mon, 2 Aug 2010 13:07:26 +0900

Hi Thomas,

Yes, a LMA doesn't need MN-specific multicast operations.

(MN1, MN2 are registered to LMA1, LM2 respectively through standard PMIP
procedure.)

Even in this scenario, a MAG sends aggregated MLD report message to only
LMA?

Abstolutely No.. in combined case

If you say 'Yes', I think it is 'dedicated' LMA case.

My understanding about combined case is very clear.

Multicasting service for MN1, MN2 should be provided by  LMA1, LM2 that
have BCE for each MN.

IMHO, please let me know am I wrong?

Your regards

Seil Jeon

-----Original Message-----
From: Thomas C. Schmidt [mailto:[email-masked]] 
Sent: Saturday, July 31, 2010 5:29 PM
To: [email-masked]
Cc: 'Behcet Sarikaya'; [email-masked]
Subject: Re: [multimob] Fwd: New Version Notification fordraft-ietf-
multimob-pmipv6-base-solution-05

Hi Seil,

I'm not exactly sure about understanding you correctly.

However, it appears to me that you do not consider the point-to-point link
model currently in use by PMIPv6: An MLD message arrives at such a ptp
link. Even though the MLD has no identification record of the MN (after
address configuration it of course contains a source address), each message
can be associated with the MN via the link (downstream interface of the MLD
proxy at MAG).

At the LMA, you don't need MN-specific multicast operations: LMA learns
about multicast forwarding from aggregated reports obtained via the MLD
proxy at the MAG. The latter seems perfectly fine, as multicast data is
meant not to reach a single MN alone. Ideally, Mcast data is received by a
(possibly large) group of receivers.

In case you are looking for individual accounting of mcast data for each
MN, the PMIP protocol would need extensions. An example could be, that AAA
returns an admission record to the MAG so that an extended MLD proxy
instance could decide on whether to include MN's downlink in operation or
not.

However, this is beyond the scope of the current charter, but could be an
interesting extension - even though it is not clear to me, whether
operators would want to do accounting on an individual basis instead of
just offering multicast as a flat rate service.

Best regards,

Thomas

On 31.07.2010 06:45, Seil Jeon wrote:
>
> Hi Behcet,
>
> Now, I assume that PBU/PBA procedure already done for unicasting
>
> so LMA #1 has BCE for MN #1, LMA #2 has BCE for MN #2.
>
>
> In dedicated case, it could be what you say because multicasting LMA 
> is designated.
>
> However, in combined case (WG document), it could be?
>
> Because AAA server should return the registered LMA #1 address 
> according to the MN  #1.
>
>
> How can AAA know MN's currently registered LMA?
>
> Because MLD report message has no MN-id information.
>
>
>
> Best Regards,
>
> Seil Jeon
>
>
>
>
> -----Original Message-----
> From: Behcet Sarikaya [mailto:[email-masked]]
> Sent: Saturday, July 31, 2010 4:58 AM
> To: [email-masked]; Thomas C. Schmidt
> Cc: [email-masked]
> Subject: Re: [multimob] Fwd: New Version Notification fordraft-ietf-
> multimob-pmipv6-base-solution-05
>
> Hi Seil,
>    The way it works is a bit complicated. In
> http://tools.ietf.org/html/draft-ietf-netlmm-lma-discovery-04
> MN goes thru access authentication possibly triggered by MLD Report 
> message. AAA server returns LMA address to the NAS which is colocated 
> with MAG.
>
> There are other ways though. In
> http://tools.ietf.org/id/draft-xia-netlmm-lma-discovery-02.txt
> stateless DHCP is used by MAG to request LMA address for this MN from 
> DHCP server.
>
> Also it could be DNS based, like in
> http://tools.ietf.org/id/draft-sarikaya-netlmm-lma-dnsdiscovery-03.txt
>
> MAG uses DNS service name to get LMA addresses and pick one for this MN.
>
> Hope this helps.
>
> Regards,
>
> Behcet
>
>
>
> ----- Original Message ----
>> From: Seil Jeon<[email-masked]>
>> To: Thomas C. Schmidt<[email-masked]>
>> Cc: [email-masked]
>> Sent: Fri, July 30, 2010 8:09:56 AM
>> Subject: Re: [multimob] Fwd: New Version Notification
>> fordraft-ietf-multimob-pmipv6-base-solution-05
>>
>>
>> Dear Schmidt,
>>
>> Now, I'm developing several PMIPv6 multicasting system  to compare 
>> performance.
>>
>> But I have a question in the case of multiple  MNs and multiple LMAs.
>>
>> There are LMA1, LMA2, MN1, MN2. These nodes are  connected at same MAG.
>>
>> The PMIPv6 tunnel of MAG-LMA1, MAG-LMA2 is  established.
>>
>> When MAG receives MLD report message from MN1, how can MAG  determine 
>> MN's LMA
>>
>> because there's no information in upstream  interface in MAG.
>>
>>
>>
>> Best Regards
>>
>> Seil  Jeon
>>
>>
>> -----Original Message-----
>> From: [email-masked] [mailto:[email-masked]]  
>> On Behalf Of Thomas C. Schmidt
>> Sent: Friday, July 30, 2010 1:27 AM
>> To: [email-masked]
>> Subject: [multimob]  Fwd: New Version Notification
>> fordraft-ietf-multimob-
>> pmipv6-base-solution-05
>>
>> Hi all,
>>
>> we have  now updated the draft to include the latest WG comments and
> reviews.
>>
>> The  new version should be available shortly  at
>> http://tools.ietf.org/html/draft-ietf-multimob-pmipv6-base-solution-0
>> 5
>>
>> Best  regards,
>>
>> Thomas
>>
>> -------- Original Message --------
>> Subject:  New Version Notification  for
>> draft-ietf-multimob-pmipv6-base-solution-05
>> Date: Thu, 29 Jul 2010  09:19:19 -0700 (PDT)
>> From: IETF I-D Submission Tool<[email-masked]>
>> To: [email-masked]
>> CC:
>> [email-masked],mw@link-
>> lab.net,[email-masked]
>>
>>
>> A  new version of I-D, 
>> draft-ietf-multimob-pmipv6-base-solution-05.txt
>> has been  successfully submitted by Thomas Schmidt and posted to the 
>> IETF repository.
>>
>> Filename:         draft-ietf-multimob-pmipv6-base-solution
>> Revision:         05
>> Title:           Base Deployment for Multicast  Listener Support in
PMIPv6
>> Domains
>> Creation_date:   2010-07-28
>> WG  ID:           multimob
>> Number_of_pages:  21
>>
>> Abstract:
>> This document describes deployment options for activating  multicast 
>> listener functions in Proxy Mobile IPv6 domains without  modifying 
>> mobility and multicast protocol standards.  Similar to Home  Agents 
>> in Mobile IPv6, Local Mobility Anchors of Proxy Mobile IPv6 serve  as 
>> multicast subscription anchor points, while Mobile Access  Gateways 
>> provide MLD proxy functions.  In this scenario, Mobile Nodes  remain 
>> agnostic of multicast mobility operations.  A support for  mobile 
>> multicast senders is outside the scope of this  document.
>>
>>
>>
>>
>> The IETF  Secretariat.
>>
>>
>> _______________________________________________
>> multimob  mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/multimob
>>
>>
>> _______________________________________________
>> multimob mailing  list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/multimob
>>
>
>
>
>
> _______________________________________________
> multimob mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/multimob

-- 

Prof. Dr. Thomas C. Schmidt
° Hamburg University of Applied Sciences                   Berliner Tor 7
°
° Dept. Informatik, Internet Technologies Group    20099 Hamburg, Germany
°
° http://www.haw-hamburg.de/inet                   Fon: +49-40-42875-8452
°
° http://www.informatik.haw-hamburg.de/~schmidt    Fax: +49-40-42875-8409
°

---

From: "Thomas C. Schmidt" <[email-masked]>
Date: Mon, 02 Aug 2010 12:17:09 +0200

Hi Seil,

sorry, but I still have some trouble understanding what you are pointing at.

It appears to me that you ask about the MAG <-> LMA relations for multicast.

This is a many-to-many relation for the following reasons:

  Each LMA can serve many MAGs (as in PMIP unicast).
  On the other hand, each MAG runs several MLD proxy instances, each
having its uplink to a different LMA. Thus, a MAG negotiates and
receives multicast by several LMAs, using the MN <-> LMA associations
harvested from unicast.

Best regards,

Thomas

-- 

Prof. Dr. Thomas C. Schmidt
° Hamburg University of Applied Sciences                   Berliner Tor 7 °
° Dept. Informatik, Internet Technologies Group    20099 Hamburg, Germany °
° http://www.haw-hamburg.de/inet                   Fon: +49-40-42875-8452 °
° http://www.informatik.haw-hamburg.de/~schmidt    Fax: +49-40-42875-8409 °

---

From: Behcet Sarikaya <[email-masked]>
Date: Mon, 2 Aug 2010 07:55:48 -0700 (PDT)

Hi Seil,

Sec. 6.1 of RFC 5213 says:

The identifier of the attached mobile node, MN-Identifier.  This
      identifier is acquired during the mobile node's attachment to the

      access link through mechanisms outside the scope of this document.
So MN-Id is not obtained from MLD messages.

Regards,

Behcet

----- Original Message ----
> From: Seil Jeon <[email-masked]>
> To: Behcet Sarikaya <[email-masked]>; Thomas C. Schmidt 
><[email-masked]>
> Cc: [email-masked]
> Sent: Fri, July 30, 2010 11:45:59 PM
> Subject: RE: [multimob] Fwd: New Version Notification 
> In dedicated case, it could be what you say because multicasting  LMA is
> designated.
> 
> Because AAA server should return the registered LMA #1 address  according to
> the MN  #1.
> 
> 
> message. AAA  server returns LMA address to the NAS which is colocated  with
> MAG.
> 
> stateless  DHCP is used by MAG to request LMA address for this MN from  DHCP
> server.
> 
> > From: Seil Jeon <[email-masked]>
> > To: Thomas  C. Schmidt <[email-masked]>
> >  Cc: [email-masked]
> > From: [email-masked] [mailto:[email-masked]]  On 
> > Behalf Of Thomas C. Schmidt
> >  http://tools.ietf.org/html/draft-ietf-multimob-pmipv6-base-solution-05
> > 
> > Best  regards,
> > 
> > Thomas
> > 
> > From: IETF I-D Submission Tool  <[email-masked]>
> > A  new version of I-D,  draft-ietf-multimob-pmipv6-base-solution-05.txt
> > Title:           Base Deployment for  Multicast  Listener Support in PMIPv6
> > Domains
> > mobility and multicast protocol  standards.  Similar to Home  Agents in 
> > Mobile IPv6, Local  Mobility Anchors of Proxy Mobile IPv6 serve  as

---

From: "Seil Jeon" <[email-masked]>
Date: Tue, 3 Aug 2010 12:59:22 +0900

Dear Thomas,

I got the point. As you said, I did not consider the ptp link model.

After MN's attachment, each message is associated with the MN via the link.

So, MLD report message could be delivered corresponding upstream interface.

Thanks for your description.

With your regards,

Seil Jeon

-----Original Message-----
From: Thomas C. Schmidt [mailto:[email-masked]] 
Sent: Saturday, July 31, 2010 5:29 PM
To: [email-masked]
Cc: 'Behcet Sarikaya'; [email-masked]
Subject: Re: [multimob] Fwd: New Version Notification fordraft-ietf-

Hi Seil,

Best regards,

Thomas

PMIPv6

--

---

From: "Seil Jeon" <[email-masked]>
Date: Tue, 3 Aug 2010 13:00:12 +0900

Dear Behcet,

Yes, I know. I didn't point out that.

I got the solution..and Thank you.

With your regards,

Seil Jeon

-----Original Message-----
From: Behcet Sarikaya [mailto:[email-masked]] 
Sent: Monday, August 02, 2010 11:56 PM
To: [email-masked]; Thomas C. Schmidt
Cc: [email-masked]
Subject: Re: [multimob] Fwd: New Version Notification fordraft-ietf-

Hi Seil,

Regards,

Behcet

----- Original Message ----
> > When MAG receives MLD report message from  MN1, how can MAG  
> > determine MN's LMA
> > 
PMIPv6
> > This document describes deployment options for  activating  
> > multicast listener functions in Proxy Mobile IPv6  domains without  
> > modifying mobility and multicast protocol  standards.  Similar to 
> > Home  Agents in Mobile IPv6, Local  Mobility Anchors of Proxy Mobile 
> > IPv6 serve  as multicast  subscription anchor points, while Mobile 
> > Access  Gateways provide  MLD proxy functions.  In this scenario, 
> > Mobile Nodes  remain  agnostic of multicast mobility operations.  A 
> > support for  mobile multicast senders is outside the scope of this
document.

---

From: Behcet Sarikaya <[email-masked]>
Date: Tue, 3 Aug 2010 09:51:25 -0700 (PDT)

> So, MLD report message could be delivered corresponding  upstream interface.

[behcet] This is how cellular links work. I am not sure if it is possible to 
implement this on a WiFi link which you considered. 

RAs can be unicast isolating each MN somehow but so-called attach procedure 
seems difficult to me to emulate on WiFi.

Regards,

Behcet

---

From: "Seil Jeon" <[email-masked]>
Date: Wed, 4 Aug 2010 12:07:46 +0900

I'm not sure.. but I'm trying to apply  PPPoE to linux-based MAG and MN.

Regards,

Seil Jeon

-----Original Message-----
From: Behcet Sarikaya [mailto:[email-masked]] 
Sent: Wednesday, August 04, 2010 1:51 AM
To: [email-masked]; Thomas C. Schmidt
Cc: [email-masked]
Subject: Re: [multimob] Fwd: New Version Notification fordraft-ietf-

> So, MLD report message could be delivered corresponding  upstream
interface.

[behcet] This is how cellular links work. I am not sure if it is possible
to implement this on a WiFi link which you considered. 

Regards,

Behcet