Subject: [multimob] [Fwd: New Version Notification for draft-schmidt-multimob-fmipv6-pfmipv6-multicast-01]

From: "Thomas C. Schmidt" <[email-masked]>
Date: Fri, 05 Mar 2010 16:16:20 +0100

Hi all,

following the focus of Dirk, we submitted a new draft on FMIPv6/PFMIPv6 
multicast extensions.

This work was actually initiated back in the last meeting of MobOpts and 
delayed due to the initial PMIP focus of Multimob.

Looking forward to your comments and to progressing the discussion!

Best regards,

Thomas

-------- Original Message --------
Subject: New Version Notification for 
draft-schmidt-multimob-fmipv6-pfmipv6-multicast-01
Date: Fri,  5 Mar 2010 07:08:30 -0800 (PST)
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-schmidt-multimob-fmipv6-pfmipv6-multicast-01.txt has been 
successfuly submitted by Thomas Schmidt and posted to the IETF repository.

Filename:	 draft-schmidt-multimob-fmipv6-pfmipv6-multicast
Revision:	 01
Title:		 Multicast Listener Extensions for MIPv6 and PMIPv6 Fast Handovers
Creation_date:	 2010-03-06
WG ID:		 Independent Submission
Number_of_pages: 21

Abstract:
Fast handover protocols for MIPv6 and PMIPv6 define mobility
management procedures that support unicast communication at reduced
handover latencies.  Fast handover base operations do not affect
multicast communication, and hence do not accelerate handover
management for native multicast listeners.  Many multicast
applications like IPTV or conferencing, though, are comprised of
delay-sensitive real-time traffic and could strongly benefit from
fast handover execution.  This document specifies extension of the
Mobile IPv6 Fast Handovers (FMIPv6) and the Fast Handovers for Proxy
Mobile IPv6 (PFMIPv6) protocols to include multicast traffic
management in fast handover operations.

The IETF Secretariat.

-- 

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: Min Hui <[email-masked]>
Date: Fri, 12 Mar 2010 14:35:22 +0800

Hi Thomas,

I have a draft to solve this multicast fast handover issue which was
proposed last year, and we have discussed this draft by mail before
last IETF meeting.
See my draft by the link:
http://tools.ietf.org/id/draft-hui-multimob-fast-handover-00.txt
The draft was on the Multimob agenda in the last IETF meeting, but
wasn't presented due to the lack of time.

I have a quick look about your new draft, it seems our drafts are
quite similar. We both extend the HI/HACK message to support multicast
context transfer, and setup the tunnel between pMAG and nMAG to ensure
multicast fast handover.

Regards,
Hui Min

2010/3/5 Thomas C. Schmidt <[email-masked]>:
> A new version of I-D, draft-schmidt-multimob-fmipv6-pfmipv6-multicast-01.txt
> has been successfuly submitted by Thomas Schmidt and posted to the IETF
> repository.
>
> _______________________________________________
> multimob mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/multimob
>

---

From: "Thomas C. Schmidt" <[email-masked]>
Date: Fri, 12 Mar 2010 10:41:28 +0100

Hi Hui,

> wasn't presented due to the lack of time.

Of course I know. In Hiroshima, we had a quick discussion with Hui Deng 
and Rajeev about the subject and the work we had already been doing on this.

> context transfer, and setup the tunnel between pMAG and nMAG to ensure

As mentioned in the Acknowledgements Section (and also in the problem 
statement), there has actually been a long history of proposals, papers 
& drafts on this issue, the first draft was 
draft-suh-mipshop-fmcast-mip6-00 already in July 2004. They are all 
similar on this very abstract level that context is transfered via 
HI/HACK messages. However, none of the proposals I have seen have really 
tried to work out the problem in sufficient detail. (Even though we have 
not completed the protocol details section, you already see from 
comparisons that there are quite a number of issues such an 
M-FMIPv6/M-PFMIPv6 protocol must resolve that haven't been addressed 
before).

So from this abstract point of view, not much had happened since 2004, 
why I was hesitant to present a longer list of references ...

... but the latter we might change.

Best wishes,

Thomas

--

---

From: Frank Xia <[email-masked]>
Date: Fri, 12 Mar 2010 10:21:45 -0600

Hi Thomas

Just I told you in another email, we had a draft
http://tools.ietf.org/id/draft-xia-mipshop-fmip-multicast-01.txt
which was presented at IETF 66, and Multimob BarBoF.

I was going to update the draft adopting the following principles:

1)Unifying multicast FMIP and PFMIP handover procedure, that is 
 FBU/FBack messages won't be touched. I would like to  view 
 multicast mobility is an application of unicast mobility. When
 a mobile node moves, it is also assumed that corresponding 
 multicast traffic should be handovered to NAR.

2)MLD query is used to collect multicast context, which is 
applicable not only to FMIP but also PFMIP. HI/HACK are
used for context transferring between PAR(PMAG)/NAR(NMAG)

3)Extending MLD/IGMP for Specific MLD Query. You use general MLD
 Query which is fine when point-to-point link model adopted,
 and PMIP "currently" is only for point-to-point link, but FMIP
 is for both shared-link and point-to-point link.

BR
Frank

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Thomas C. Schmidt
Sent: Friday, March 12, 2010 3:41 AM
To: Min Hui
Cc: [email-masked]
Subject: Re: [multimob] [Fwd: New Version Notification
fordraft-schmidt-multimob-fmipv6-pfmipv6-multicast-01]

Hi Hui,

Best wishes,

Thomas

>> CC: [email-masked],[email-masked],[email-masked]
draft-schmidt-multimob-fmipv6-pfmipv6-multicast-01.txt

--

---

From: Frank Xia <[email-masked]>
Date: Fri, 19 Mar 2010 15:48:25 -0500

Hi Thomas

I took a quick look at the draft.

A major observation is that your multicast 
handover solutions are deeply coupled with 
specific unicast handover solutions.

I would like to have a unified ( or general ) 
multicast handover solution which support
mobile IPv4 fast handover(RFC4988), mobile
IPv6 fast handover(RFC5568), and Fast Handovers for
Proxy Mobile IPv6(draft-ietf-mipshop-pfmipv6-12.txt).

Some specific comments are below:
1)section 5.1.
 M-bit in Proxy Router Advertisements (PrRtAdv) is for 
 AR multicast capability notification. However, there
 is no such mechanism for PMAG just because there is no
 proper signaling to carry this information.  Probably,
 we don't need this capability notification, and just
 assume that all multicast traffic need session continuity.

2)section 5.2 
  "the corresponding option is included within the mobility 
   option list of HI/HAck only (PFMIPv6), or of FBU/FBAck
   /HI/HAck (FMIPv6"
  IMHO, it is not necessary for FBU/FBack to carry this option.
  PMAG/PAR can collect MN's multicast membership information 
  MLD/IGMP(for dual stack)

3)figure 2 and figure 4
 Can we unify them?  PAR can treat FBU as a trigger, and then collects
 Multicast membership information of the mobile node using MLD/IGMP

4)IPv4 consideration.
  Can we consider a general solution which also support mobile IPv4 fast
  handover(RFC4988)?

We can discuss face to face at the meeting.

BR
Frank

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Frank Xia
Sent: Friday, March 12, 2010 10:22 AM
To: 'Thomas C. Schmidt'; 'Min Hui'
Cc: [email-masked]
Subject: Re: [multimob] [Fwd: New Version
Notificationfordraft-schmidt-multimob-fmipv6-pfmipv6-multicast-01]

Hi Thomas

BR
Frank

-----Original Message-----

Hi Hui,

Best wishes,

Thomas

--

---

From: "Thomas C. Schmidt" <[email-masked]>
Date: Fri, 19 Mar 2010 22:06:15 +0100

Hi Frank,

> specific unicast handover solutions.

I don't see what you are pointing at: this draft addresses multicast 
extensions for FMIPv6 and PMIPv6. The core parts are identical, specific 
details of the unicast handover protocols, however, need to be taken 
into account.

> Proxy Mobile IPv6(draft-ietf-mipshop-pfmipv6-12.txt).

I don't think there is room for a uniform behavior - multicast message 
exchange (context transfer), however, in our draft is independent of the 
specific unicast protocol.

>  assume that all multicast traffic need session continuity.

Yes, of course there is not - P(f)MIPv6 has no handover message exchange 
with the mobile node, as MNs are mobility-agnostic in PMIP.

>   PMAG/PAR can collect MN's multicast membership information 

This means explicit tracking at the PAR/PMAG. We commented on it - but 
as it is not the default standard behavior, we cannot assume explicit 
tracking.

Also: initiating the mobility option, that is passed between FMIPv6 ARs, 
at the mobile client is not a particularly bad thing.

>  Multicast membership information of the mobile node using MLD/IGMP

I don't think so: FMIPv6 and PFMIPv6 are not totally alike ... even the 
base unicast HI/HACK are not identical.

>   Can we consider a general solution which also support mobile IPv4 fast

Yes, this should be a point to think about: there should be no general 
problem, I suppose.

> We can discuss face to face at the meeting.

Yes, L.A. sunset will be inspiring :-)

Best,

Thomas

--

---

From: Frank Xia <[email-masked]>
Date: Fri, 19 Mar 2010 16:29:29 -0500

Hi Thomas

Please check my comments...

BR
Frank

-----Original Message-----
From: Thomas C. Schmidt [mailto:[email-masked]] 
Sent: Friday, March 19, 2010 4:06 PM
To: Frank Xia
Cc: 'Min Hui'; [email-masked]
Subject: Re: [multimob] [Fwd: New
VersionNotificationfordraft-schmidt-multimob-fmipv6-pfmipv6-multicast-01]

Hi Frank,

I don't see what you are pointing at: this draft addresses multicast 
extensions for FMIPv6 and PMIPv6. The core parts are identical, specific 
details of the unicast handover protocols, however, need to be taken 
into account.
Frank=>What about FMIPv4?

I don't think there is room for a uniform behavior - multicast message 
exchange (context transfer), however, in our draft is independent of the 
specific unicast protocol
Frank=> The uniform behavior could be using MLD/IGMP to collect
multicast group information, using HI/Hack to transfer this context from
PAR(PMAG) to NAR(PMAG), and IP4/IP6/GRE tunneling multicast traffic from
PAR(PMAG) to NAR(PMAG)．　You modified PrRtAdv, FBU/FBAck which are specific
protocol　for FMIPv6.
.

Yes, of course there is not - P(f)MIPv6 has no handover message exchange 
with the mobile node, as MNs are mobility-agnostic in PMIP.
Frank=>Probably we do not need this extra consideration for FMIP.

I don't think so: FMIPv6 and PFMIPv6 are not totally alike ... even the 
base unicast HI/HACK are not identical.
Frank=>It depends on how we look at FMIP and PFMIP.  IMHO, they are alike in
main idea. Let me reword my question. Can PAR use MLD inquiry not FBU to
have 
multicast group information of a mobile node?  

Yes, this should be a point to think about: there should be no general 
problem, I suppose.
Frank=>Unified solution does not mean to be identical. Of course, there
are some variations in details, such as triggers.

Best,

Thomas

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

-- 

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: Fri, 19 Mar 2010 22:37:50 +0100

Hi again Frank,

please see inline:

> Frank=>What about FMIPv4?

Thomas => This I commented on earlier: this should not be a big go.

> PAR(PMAG) to NAR(PMAG)．　You modified PrRtAdv, FBU/FBAck which are specific

Thomas => Yes, but if this step is omitted, an FMIP MN has no option to
take actions. But pure FMIP is still - even though assisted by ARs -
tied to the end-to-end paradigm. I tend to respect this ... as it
sustains the option for proactive operations at the MN (e.g., taking a
choice on where to subscribe what -> see RFC 5757 for more detail).

> Frank=>Probably we do not need this extra consideration for FMIP.

Thomas => see above.

> multicast group information of a mobile node?  

Thomas => It could query - but this causes delays and may be misleading
with respect to the MN (that may have multiple attachments).

--

---

From: Frank Xia <[email-masked]>
Date: Mon, 22 Mar 2010 12:31:44 -0500

-----Original Message-----
From: Frank Xia [mailto:[email-masked]] 
Sent: Monday, March 22, 2010 12:23 PM
To: 'Thomas C. Schmidt'
Cc: [email-masked]'
Subject: RE: [multimob] [Fwd:
NewVersionNotificationfordraft-schmidt-multimob-fmipv6-pfmipv6-multicast-01]

Hi Thomas

Please also check my inline comments...

BR
Frank

-----Original Message-----
From: Thomas C. Schmidt [mailto:[email-masked]] 
Sent: Friday, March 19, 2010 4:38 PM
To: Frank Xia
Cc: [email-masked]
Subject: Re: [multimob] [Fwd:
NewVersionNotificationfordraft-schmidt-multimob-fmipv6-pfmipv6-multicast-01]

Hi again Frank,

please see inline:

Thomas => This I commented on earlier: this should not be a big go.
Frank=>I am not sure your point.
My point is we are solving multicast mobility in which mobile node 
could implement MIPv4/MIPv6/PMIPv6. 

Thomas => Yes, but if this step is omitted, an FMIP MN has no option to
take actions. But pure FMIP is still - even though assisted by ARs -
tied to the end-to-end paradigm. I tend to respect this ... as it
sustains the option for proactive operations at the MN (e.g., taking a
choice on where to subscribe what -> see RFC 5757 for more detail).
Frank=>The solution you proposed does not seem to be consistence. MN 
with FMIPv6 has the option, while MN with PFMIPv6 has no such option.
>From user perspective, users would have different services.

Thomas => see above.

Thomas => It could query - but this causes delays and may be misleading
with respect to the MN (that may have multiple attachments).
Frank=>I am not clear about the misleading. As for delay, I don't think 
it is a problem.  If we separate multicast handover from unicast handover,
it won't affect unicast handover. After receiving FBU, PAR inquires
multicast
membership of the mobile node, at the same time, PAR also sends HI message
to NAR.  The PAR would send another HI for multicast context transfer.

>>>> Title:           Multicast Listener Extensions for MIPv6 and PMIPv6
Fast
>>>> Handovers

--

---

From: "Thomas C. Schmidt" <[email-masked]>
Date: Mon, 22 Mar 2010 12:01:32 -0700

Hi Frank,

thanks - let me straighten this discussion to the key point (please see
below):

> From user perspective, users would have different services.

Thomas => It seems there is some confusion here: (F)MIPv6 and P(F)MIPv6
are two different protocols and it is not the task of the Multicast
Extension Draft to re-merge the two unicast protocols. So complying to
the differences inherited from unicast IMHO does not lead to
"inconsistent multicast".

Consistency measures need to be applied with respect to the unicast
protocols, i.e., the question to be asked is "are the multicast
extensions defined consistently with respect to the corresponding
unicast protocols". And that was the aim and, I believe, should be the
objective.

So, an MN operating FMIPv6 is actively involved in the handover process,
while an MN that is hosted in a PFMIPv6 domain is not. Correspondingly,
multicast extensions are defined and IMHO should be - I cannot see a
point in reducing multicast-FMIPv6 to the PMIP restrictions, while the
opposite would violate the constraint of mobility-agnostics of MNs in PMIP.

All we can do is define a common set of messages and reuse as many
protocol elements as feasible - which we did (not only between fast
handover protocols, but also with MLD/IGMP).

Thus, no room for a grant unified theory (which belongs to physics
anyway), but a slim, easy and straight-forward multicast extension that
consistently augments the unicast protocols (specified elsewhere).

Does this make sense?

Cheers,

Thomas
--

---

From: "Thomas C. Schmidt" <[email-masked]>
Date: Mon, 22 Mar 2010 17:24:05 -0700

Hi again Frank,

let me summarize my arguments below:

Frank Xia wrote:

> To keep my points clearer, I would like to reiterate 
> what my unified solution is.
> 
> 1)PAR(PMAG) makes use of MLD/IGMP to collect multicast group 
> information of a mobile node

Thomas => This has several severe problems and cannot work smoothly with
FMIPv6:

 1. A nAR can only learn about the expected departure of a MN by
receiving the FBU (normally, FMIPv6 is *not* network initiated). If nAR
has to query after receiving an FBU, it either needs to delay the
HI/HACK dialog for unicast or it needs to add additional HI/HACK
exchanges. This would (sort of) twist the basic FMIPv6 spec.

 2. It will take the option to choose mcast context transfer away from
the MN in FMIPv6, as an MN cannot distinguish whether it receives a
general MLD Query for handover purposes or for a general state
maintenance. So it cannot stir which groups are to be transfered into
the new network.
This reduces FMIPv6 handover capabilities without an advantage obvious
to me.

 3. It would slow down handover timing & reduce network efficiency (by
adding general queries that may be answered by many nodes on a shared
FMIPv6 downlink).

So three good reasons to *not* avoid MLD queries whenever possible.

> 2) PAR(PMAG) uses HI/Hack to transfer this context to NAR(PMAG)

Thomas => Here it should be noted that Hi/Hack message exchange (from
the unicast side) is not identical in FMIPv6 and PFMIPv6. Multicast
Mobility options defined in
draft-schmidt-multimob-fmipv6-pfmipv6-multicast are identical, but still
the protocols need distinction.

> 3) PAR(PMAG) uses a IP4/IP6/GRE tunnel for multicast traffic from
> PAR(PMAG) to NAR(PMAG)．

Thomas => The pAR(pMAG)-nAR(nMAG) tunnel definition is part of the
unicast protocol specs. We don't (need to) change this for multicast
transfer (only need to define forwarding states).

> 
> This solution is applicable to MIPv6,PMIPv6, and MIPv4 scenarios, and
> does not change any unicast fast handover signaling. 
> 

Thomas => No, disagree: in any case we need to augment the unicast
handover protocol by Multicast Mobility Options that provide the context
transfer. These options are defined as Mobility Header Messages and
seamlessly plug into (P)FMIPv6. There is no way to provide mcast context
transfer without extending unicast protocols - so I really cannot see an
objective or requirement to "not change any unicast fast handover
signaling".

Rather, our design goal is to smoothly extend given protocol syntax and
semantic. To see this, the protocol extensions proposed in
draft-schmidt-multimob-fmipv6-pfmipv6-multicast converge to a single
"Multicast indicator bit in PrRtAdv" in the absence of multicast
subscribtions (FMIPv6). In PFMIPv6 we still need the query,
unfortunately we cannot do otherwise for an mobility-agnostic MN.

If you look at the proposal more closely, you may see a very easy
message handling / state transition between MLD(IGMP) records and
context transfer messages. This should make the protocol not only easy
to implement, but also easy to integrate into both, the mobility and the
multicast subsystems of the nodes/routers involved.

Cheers,

Thomas

> Sent: Monday, March 22, 2010 2:02 PM
> To: Frank Xia
> Cc: [email-masked]
> Subject: Re: [multimob]
> [Fwd:NewVersionNotificationfordraft-schmidt-multimob-fmipv6-pfmipv6-multicas
> t-01]
> 
> Hi Frank,
> 
> Frank=>If multicast handover is independent of specific unicast handover
> solutions, probable we can have a consistent multicast solution.
> 
> Frank=>see above. 
> Frank=>Just because you support multicast handover by expanding specific 
> unicast handover signaling, such FBU/FBA
> 
> Frank=>Probably we can go further, that is, no modifying unicast handover
> signaling while providing the same service.
> 
> Frank=>After discussing with you face to face, it makes more sense
> that a mobile node should be able to choose which multicast traffic
> to be handovered.  However, I still insist a unified solution.
> 
> Cheers,
> 
> Thomas

--

---

From: "Thomas C. Schmidt" <[email-masked]>
Date: Mon, 22 Mar 2010 19:15:27 -0700

Hi again Frank,

it seems there is an iteration loop here, which leaves the impression
that you have not read and thought carefully over the problem.

Just to be extremely clear:

 1. Regular FMIPv6 does not work reasonably well with Multicast +
initial MLD queries (3 reasons given)

 2. This cannot be healed by changing MLD/IGMP, and *we won't* propose
changes to MLD/IGMP for FMIP

 3. We likewise won't touch the tunneling mechanism of the FMIPv6
unicast protocol. If you don't like it, please propose an updated
version of RFC 5568. This is not multicast-related.

I guess this gives a definite & clear position ... and should terminate
the thread.

Cheers,

Thomas

Frank Xia wrote:
> Sent: Monday, March 22, 2010 7:24 PM
> To: Frank Xia
> Cc: [email-masked]
> Subject: Re: [multimob]
> Frank=>If you look at current wireless networks(3GPP/3GPP2/WiMAX),
> networks always knows the coming handover by some under-layer events.
> It is this mechanism that makes FPMIPv6 possible.
> 
> My proposal wont change  FMIPv6, and it is impossible to twist it.
> Additionally, just I showed you, FMIPv6 could be host initiated 
> or network initiated.  
> 
> 
> Frank=>If we want to keep this capability, we can extend MLD/IGMP.
> If the community has a consensus that we should not extend
> IGMP/MLD  even though it could streamline multicast mobility 
> solution, I won't make such noise any more.
> 
> Frank=>by extending MLD/IGMP, there is no such issues.
>  
> Frank=>Sure.
> Frank=>Of course, we won't change any unicast handover processing. 
> Additionally, I think GRE tunnel should be supported, just as is
> done with PFMIP.
> 
> Frank=>Partly agree. Let me say 
> " This solution is applicable to MIPv6,PMIPv6, and MIPv4 scenarios, and make
> the least extensions for unicast fast handover signalling"
> 
> Frank=>If we can extend MLD/IGMP, we can certainly provide the
> same service.
> 
> Frank=>I think I understand the proposal very well. I have a similar
> draft :-)
> 
> Cheers,
> 
> Thomas
> 
> 

--