Subject: [multimob] Thoughts on Context Transfer

From: "Thomas C. Schmidt" <[email-masked]>
Date: Tue, 29 Mar 2011 20:28:44 +0200

Hi all,

during the presentation of draft 
http://tools.ietf.org/html/draft-schmidt-multimob-fmipv6-pfmipv6-multicast, 
the following fundamental question was raised (in hurry):

Why don't we use a generic context transfer (by RFC 4067) for multicast 
states only, and leave unicast handover aside?

This question implies two subsequent questions:

  1. Is there any use case, in which an application-specific group 
membership (not all nodes group ...) should be transferred in a 
"fast-handover-type" context transfer, but unicast handover should not 
do the context transfer between ARs / MAGs?

  2. In case FMIPv6 / PFMIPv6 is applied, is it advisable to transfer 
multicast context different from unicast context (e.g., by CXTP)?

It would be good to get more elaborated opinions on the list than could 
be articulated in the short remaining time of the meeting ...

Cheers,

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: Hitoshi Asaeda <[email-masked]>
Date: Tue, 29 Mar 2011 21:20:51 +0200 (CEST)

> Why don't we use a generic context transfer (by RFC 4067) for
> multicast states only, and leave unicast handover aside?

As I presented today, our draft uses CXTP (rfc4067).
Regards,
--
Hitoshi Asaeda

---

From: "Thomas C. Schmidt" <[email-masked]>
Date: Wed, 30 Mar 2011 00:24:59 +0200

Hi Hitoschi,

that may be - the first draft to present a context transfer by CXTP 
independent of unicast handover was 
http://tools.ietf.org/html/draft-miloucheva-mldv2-mipv6-00 in 2005.

The question was about the reasons and the sense behind it ...
... and my reason for asking is that I cannot think of good reasons to 
do a multicast transfer directly between ARs decoupled from unicast 
handover.

Best regards,

Thomas

On 29.03.2011 21:20, Hitoshi Asaeda wrote:
> _______________________________________________
> multimob mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/multimob

--

---

From: Marco Liebsch <[email-masked]>
Date: Tue, 29 Mar 2011 22:38:47 +0000

Hi,
there was a further option mentioned during the meeting, which is the
transfer of MC context via the LMA. So, why not establishing the MC
context at the nMAG by means of PBU/PBA?
I just thought mandating a Fast Handover protocol to solve context transfer
may be a bit heavyweight. At leat it's a valid option to consider. Is there any
MC state on the pMAG which cannot be stored on the LMA? I think this
would meet also the requirement to establish MC context together with unicast
handover.

just some thoughts.
marco

________________________________________
Von: [email-masked] [[email-masked]]&quot; im Auftrag von &quot;Thomas C. Schmidt [[email-masked]]
Gesendet: Mittwoch, 30. März 2011 00:24
Bis: Hitoshi Asaeda
Cc: [email-masked]; [email-masked]
Betreff: Re: [multimob] Thoughts on Context Transfer

Hi Hitoschi,

Best regards,

Thomas

--

---

From: <[email-masked]>
Date: Wed, 30 Mar 2011 09:39:29 +0200

Hi Thomas, Hitoshi,
Regarding potential use cases for separated HO for multicast traffic (independent of concurrent unicast traffic to the MN) a reason might be operator policy running heterogeneous networks in parallel and doing (multicast) traffic off-load e.g. from cellular (with only few subscribers to a content) to a broadcast medium (e.g. DVB) in case the subscriber group reaches a certain size making it economic to switch the distribution path ...
AR's in this case may be radio towers ... Spannung a larger area than WiFi and cellular but nevertheless being limited e.g. in case of highway or train movement ...

Would this make sense?

Best regards
Dirk 

-----Ursprüngliche Nachricht-----
Von: [email-masked] [mailto:[email-masked]] Im Auftrag von Thomas C. Schmidt
Gesendet: Mittwoch, 30. März 2011 00:25
An: Hitoshi Asaeda
Cc: [email-masked]; [email-masked]
Betreff: Re: [multimob] Thoughts on Context Transfer

Hi Hitoschi,

Best regards,

Thomas

--

---

From: "Thomas C. Schmidt" <[email-masked]>
Date: Wed, 30 Mar 2011 10:03:14 +0200

Hi Marco,

thanks for commenting:

> context at the nMAG by means of PBU/PBA?

This would be the option of a "slow" context transfer, meaning that 
context transfer is not used for acceleration purposes. This raises the 
question about the benefit: What is the advantage of a network-based 
context transfer, if not speed?

One answer I can think of is not to rely on MLD signaling on the 
wireless link. This will reduce sources of errors (lost MLD messages) 
and save wireless bandwidth (some bits).

Do you have additional arguments in mind?

> may be a bit heavyweight. At leat it's a valid option to consider.

Sure, and my question is earnestly looking for arguments that I may have 
missed.

On the other hand, Mipshop did design the fast handover protocols for 
rapid (unicast) context transfer of MNs - if we believe that multicast 
context transfer should follow unicast context transfer, then we 
probably have to stick to the *fmip protocols (at least we are not 
chartered to design new unicast handover protocols).

> Is there any
> MC state on the pMAG which cannot be stored on the LMA?

Normally, MC states are per interface. MAGs have interfaces per MN, 
while LMAs have (tunnel) interfaces per MAG. Thus, LMAs only see 
aggregated MC states independent of individual MNs. In other words, if 
an MN handovers, an LMA (on its own) would not know which MC state to 
transfer/duplicate/terminate. This knowledge is only at the pMAG (and 
needs to go to the nMAG).

Of course you could build something like a "backup database" at the LMA 
... but this does not sound clever to me.

>I think this

I guess we agree on this :-)

Cheers,

Thomas

_____________________________________
> Von: [email-masked] [[email-masked]]&quot; im Auftrag von&quot;Thomas C. Schmidt [[email-masked]]

--

---

From: "Thomas C. Schmidt" <[email-masked]>
Date: Wed, 30 Mar 2011 10:16:47 +0200

Hi Dirk,

> Regarding potential use cases for separated HO for multicast traffic (independent of concurrent unicast traffic to the MN) a reason might be operator policy running heterogeneous networks in parall…

O.K., I see. But still this is not exactly a PMIP-like scenario. In your 
case, MN would have to activate an additional radio interface (DVB or 
??) to receive multicast from there. But this interface would first need 
to configure a unicast IP address before participating in the multicast 
communication. However, this unicast interface would be newly 
instantiated, thus experiences no context transfer, and also lives at a 
different media - so this may be rather a case for MIH??

> AR's in this case may be radio towers ... Spannung a larger area than WiFi and cellular but nevertheless being limited e.g. in case of highway or train movement ...

I agree, this is an interesting scenario, provided operators do such 
things (or are interested in doing so ???). Still, the problem is a 
different one, in particular for the case of unidirectional downlinks 
such as DVB or satellites or ...

Even though I would argue that this scenario is something different, it 
might be quite interesting for the group to learn about possible 
deployment options. Will you be able to gather knowledge on this area 
and share with the group?

Thanks & best wishes

Thomas

--

---

From: "Luis M. Contreras" <[email-masked]>
Date: Wed, 30 Mar 2011 12:01:14 +0200

Hi all,

this way is something already explored in draft-contreras-multimob-rams-00,
where the active multicast subscription is transferred from the pMAG to the
nMAG through the LMA by means of PBU/PBA messages (plus some additional
mechanisms to govern the process).

Regards,

Luis

2011/3/30 Marco Liebsch <[email-masked]>

> Von: [email-masked] [[email-masked]]&quot; im
> Auftrag von &quot;Thomas C. Schmidt [[email-masked]]

---

From: "Thomas C. Schmidt" <[email-masked]>
Date: Wed, 30 Mar 2011 14:17:14 +0200

Hi Luis,

yes ... and we already had a longer discussion on the list about this: 
Your argument was "handover acceleration" and I tried to give you 
numbers that - in regular deployment cases where the LMA is not adjacent 
to the MAG - this does not accelerate.

In other words: in the base scenario, unicast handover (RtrSol -> PBU -> 
PBA -> RtrAdv + perhaps DAD) consumes the dominant amount of time, while 
MLD query/answer is commonly few ms.

Best,

Thomas

On 30.03.2011 12:01, Luis M. Contreras wrote:
> Hi all,
> this way is something already explored in
> draft-contreras-multimob-rams-00, where the active multicast
> subscription is transferred from the pMAG to the nMAG through the LMA by
> means of PBU/PBA messages (plus some additional mechanisms to govern the
> process).
> Regards,
> Luis
>
> 2011/3/30 Marco Liebsch <[email-masked]
> <mailto:[email-masked]>>
>
>     Hi,
>     Von: [email-masked] <mailto:[email-masked]>
>     [[email-masked] <mailto:[email-masked]>]&quot;
>     im Auftrag von &quot;Thomas C. Schmidt
>     [[email-masked]
>     <mailto:[email-masked]>]
>     Cc: [email-masked] <mailto:[email-masked]>; [email-masked]
>     <mailto:[email-masked]>
>     >  [email-masked] <mailto:[email-masked]>
>     [email-masked] <mailto:[email-masked]>
>     [email-masked] <mailto:[email-masked]>

--

---

From: "Luis M. Contreras" <[email-masked]>
Date: Wed, 30 Mar 2011 15:31:37 +0200

Hi Thomas,

note that the MLD query can not been sent before PBA is received by the new
MAG, so the ms you mention are additional to the PBU/PBA timing (thus,
leading to a worst situation)

Regards,

Luis

2011/3/30 Thomas C. Schmidt <[email-masked]>

> Hi Luis,
>
> yes ... and we already had a longer discussion on the list about this: Your
> argument was "handover acceleration" and I tried to give you numbers that -
> in regular deployment cases where the LMA is not adjacent to the MAG - this
> does not accelerate.
>
> PBA -> RtrAdv + perhaps DAD) consumes the dominant amount of time, while MLD
> query/answer is commonly few ms.
>
> Best,
>
> Thomas
>
>

---

From: Marco Liebsch <[email-masked]>
Date: Wed, 30 Mar 2011 14:53:20 +0000

Thomas,
please see inline for my reply. This time labelled with [marco].

Gesendet: Mittwoch, 30. März 2011 10:03
Bis: Marco Liebsch

Hi Marco,

thanks for commenting:

[marco] Why not speed? I heard about the requirement that the MC context should
not be established before unicast context. So, isn't it the fastest approach to establish
MC context together with unicast context? This is what the PBU/PBA can do. This implies
that we define a completed unicast state establishment as a completed PBU/PBA handshake.
If you consider a different definition, e.g. a completed forwarding state between pMAG and
nMAG as sufficient, this can be done. But then the solution is fast Handover specific.

[marco] ok

[marco] I did not follow the previous discussion on this, I just heard this requirement during yesterday's meeting.
My comments are just based on observations. As I told you, I have to dig a bit more into the details
of the discussion. So, just treat my comments as input to the scope of an analysis of solution candidates. 

Thanks,
marco

Cheers,

Thomas

--

---

From: "Thomas C. Schmidt" <[email-masked]>
Date: Wed, 30 Mar 2011 17:04:41 +0200

Hi Luis,

the query is typically sent when the link comes up, see 
http://tools.ietf.org/html/draft-ietf-multimob-pmipv6-base-solution-07#appendix-A, 
latest after the link-local address is configured. On a ptp-link, this 
costs virtually no time.

The biggest issue in handover delay is DAD, otherwise PBU/PBA when the 
LMA is far remote.

So in conclusion, multicast state acquisition after handover is not an 
issue of time - the delays arise from unicast handover and address 
configuration.

That's why I question the value of an additional multicast context 
transfer independent of the unicast handover.

Cheers,

Thomas

On 30.03.2011 15:31, Luis M. Contreras wrote:
> Hi Thomas,
> note that the MLD query can not been sent before PBA is received by the
> new MAG, so the ms you mention are additional to the PBU/PBA timing
> (thus, leading to a worst situation)
> Regards,
> Luis
>
> 2011/3/30 Thomas C. Schmidt <[email-masked]
> <mailto:[email-masked]>>
>
>     Hi Luis,
>
>     yes ... and we already had a longer discussion on the list about
>     this: Your argument was "handover acceleration" and I tried to give
>     you numbers that - in regular deployment cases where the LMA is not
>     adjacent to the MAG - this does not accelerate.
>
>     In other words: in the base scenario, unicast handover (RtrSol ->
>     PBU -> PBA -> RtrAdv + perhaps DAD) consumes the dominant amount of
>     time, while MLD query/answer is commonly few ms.
>
>     Best,
>
>     Thomas
>
>
>         <mailto:[email-masked]>
>         <mailto:[email-masked] <mailto:[email-masked]>>>
>
>             Hi,
>             I just thought mandating a Fast Handover protocol to solve
>         context
>             transfer
>         <mailto:[email-masked]
>         <mailto:[email-masked]>>
>             [[email-masked]
>         <mailto:[email-masked]>
>         <mailto:[email-masked]
>         <mailto:[email-masked]>>]&quot;
>
>         <mailto:[email-masked]>
>         <mailto:[email-masked]
>         <mailto:[email-masked]>>]
>
>             Cc: [email-masked] <mailto:[email-masked]>
>         <mailto:[email-masked] <mailto:[email-masked]>>;
>         <mailto:[email-masked] <mailto:[email-masked]>>
>
>         <mailto:[email-masked] <mailto:[email-masked]>>
>
>             ° Hamburg University of Applied Sciences
>         Berliner
>             Tor 7 °
>             ° Dept. Informatik, Internet Technologies Group    20099
>         Hamburg,
>             Germany °
>         <mailto:[email-masked] <mailto:[email-masked]>>
>
>         <mailto:[email-masked] <mailto:[email-masked]>>
>

--

---

From: "Thomas C. Schmidt" <[email-masked]>
Date: Wed, 30 Mar 2011 17:14:08 +0200

Hi Marco,

thanks, my comments are labelled with [thomas]

> please see inline for my reply. This time labelled with [marco].

[thomas] As I just answered to Luis, the MLD state acquisition is not 
costly and starts before the unicast context (addressing) is fully 
established. However, we do have a communication problem as long as MN 
has no link-local address. There is an additional aspect: PMIP with 
local non-flat routing may want to initiate predictive joins (here we 
need predictive handovers, which we get from PFMIP) ... and we're also 
looking on (F)MIP scenarios where an update delay problem with HA 
obviously exists ...

> of the discussion. So, just treat my comments as input to the scope of an analysis of solution candidates.

[thomas] Yes, thanks!

Thomas

--

---

From: "Luis M. Contreras" <[email-masked]>
Date: Wed, 30 Mar 2011 21:20:06 +0200

Hi Thomas,

three additional comments, on your mail

> latest after the link-local address is configured. On a ptp-link, this costs
> virtually no time.
>
Luis>> That's true, but this always come after PBU/PBA completion (the PBA
carries the local-link address of the MAG, needed to send the MLD Query to
the MN)

>
> The biggest issue in handover delay is DAD, otherwise PBU/PBA when the LMA
> is far remote.
>
Luis>> So the lower limit in the delay for multicast context transfer is the
unicast handover. The fastest solution is then the one that equals the
unicast handover.

>
> That's why I question the value of an additional multicast context transfer
> independent of the unicast handover.
>
Luis>> I think on two reasons:
.- Multicast traffic typically serves real-time traffic, that is, a traffic
more sensitive to delay
.- The multicast state is kept at MAG level (the LMA doesn't know the
specific subscriptions of the MN) . For efficient service continuity, it
seems better to transfer the subscription information than to rebuild the
subscription at the destination point.

Best regards,
Luis

---

From: "Thomas C. Schmidt" <[email-masked]>
Date: Thu, 31 Mar 2011 19:49:51 +0200

Hi Luis et al,

some answers marked by [Thomas]

On 30.03.2011 21:20, Luis M. Contreras wrote:
>     latest after the link-local address is configured. On a ptp-link,
>     this costs virtually no time.
>
> Luis>> That's true, but this always come after PBU/PBA completion (the
> PBA carries the local-link address of the MAG, needed to send the MLD
> Query to the MN)

[Thomas] Well, the initial query of the router is before, when link 
comes up ... but the report can only be sent after PBA, that's correct.

>
>
>     The biggest issue in handover delay is DAD, otherwise PBU/PBA when
>     the LMA is far remote.
>
>     So in conclusion, multicast state acquisition after handover is not
>     an issue of time - the delays arise from unicast handover and
>     address configuration.
>
> Luis>> So the lower limit in the delay for multicast context transfer is
> the unicast handover. The fastest solution is then the one that equals
> the unicast handover.

[Thomas] Yes, ideally multicast is enabled with (or right after) unicast 
handover ...

> .- Multicast traffic typically serves real-time traffic, that is, a
> traffic more sensitive to delay
> seems better to transfer the subscription information than to rebuild
> the subscription at the destination point.

[Thomas] IMHO, there is not much room for multicast to be treated 
independent of unicast, as both contexts need to be aligned to the 
actual handover. If multicast context transfer is not synchronized with 
handover, multicast context may decouple from the MN, i.e., at some 
times multicast groups end up at a different MAG than the MN.

... and on the other hand: if you perform a fast context transfer for 
multicast, you can treat this in combination with unicast. You always do 
exchange context records, in a HI/HACK pair or in some other pair that 
does not simplify the solution.

Cheers,

Thomas
--