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

From: "Thomas C. Schmidt" <[email-masked]>
Date: Thu, 29 Jul 2010 18:26:48 +0200

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-05

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],[email-masked],[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.

---

From: "Seil Jeon" <[email-masked]>
Date: Fri, 30 Jul 2010 22:09:56 +0900

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.

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]

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:

The IETF Secretariat.

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

---

From: Behcet Sarikaya <[email-masked]>
Date: Fri, 30 Jul 2010 12:57:43 -0700 (PDT)

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,
>

---

From: "Seil Jeon" <[email-masked]>
Date: Sat, 31 Jul 2010 13:45:59 +0900

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.

Hope this helps.

Regards,

Behcet

----- Original Message ----
> When MAG receives MLD report message from MN1, how can MAG  determine 
> MN's LMA
> 
reviews.
> has been  successfully submitted by Thomas Schmidt and posted to the  
> IETF repository.
>

---

From: "Thomas C. Schmidt" <[email-masked]>
Date: Sat, 31 Jul 2010 10:29:13 +0200

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:
>> From: Seil Jeon<[email-masked]>
>> To: Thomas C. Schmidt<[email-masked]>
>> Cc: [email-masked]
>> From: IETF I-D Submission Tool<[email-masked]>

-- 

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 °