Subject: Re: [multimob] comments for draft-contreras-multimob-rams-03

From: LUIS MIGUEL CONTRERAS MURILLO <[email-masked]>
Date: Wed, 07 Dec 2011 17:45:27 +0100

Hi Hitoshi,

I'm very sorry for my long silence.

Please, find answers below.

-----Mensaje original-----
De: [email-masked] [mailto:[email-masked]] En nombre de Hitoshi Asaeda
Enviado el: viernes, 11 de noviembre de 2011 11:23
Para: [email-masked]
CC: [email-masked]
Asunto: Re: [multimob] comments for draft-contreras-multimob-rams-03

Hi Luis,

Thank you for your reply.
Can I continue the discussion a little more?

>> In this draft the authors propose "proactive" handover and "reactive"
>> handover, but it was difficult to understand the benefit of the
>> extension for reactive handover, or how the proposed reactive
>> handover accelerates handover.
>
> The comparisson has to be done with the reactive case in RFC6224.There
> the nMAG is aware of the entering MN subscription once it receives the
> MLD Report from the MN, as a reply of the MLD Query sent by the nMAG
> once the link was set up.

MLD Query is *not always* triggered by MLD Report. It depends on the Report type and the state maintained by the router.
But it is not the point of our current discussion, so skip this.

[Luis>>] (I'm not sure if I understand your point) Well, in the case I'm referring to, the nMAG sends an MLD Query because it detects a new link is up (normal procedure for MLD enabled devices); this is consequence of the MN attaching to the nMAG. Once the MN receives the Query. It will process an answer in the form of an MLD Report. This is the way the nMAG discovers the subscription if following the rfc6224 procedure.

> The time considered in the MLD Query transfer in the radio link
> (including framing, radio access delay, ...), plus the time taken by
> the MN to process and answer the MLD Query (conditioned by the Query
> Response interval), plus the MLD Report going back through the radio
> channel to the nMAG, is higher than the time taken on asking the pMAG,
> which maintains the multicast subscription of the MN because we are in the reactive case.
>
> We have try to model this in the following paper:
> http://isyou.info/jowua/papers/jowua-v2n2-5.pdf

I took a look at this paper.
Comparing with Fig.7 (proactive) and 8 (reactive), the time difference is with "Tacq". The time for reactive handover always adds Tacq time to the one for proactive handover, hence it's always longer, isn't it?

[Luis>>] Of course, the reactive case is always longer than the proactive case. In the proactive case the subscription information (or context) is piggybacked in the normal registration and de-registration proceudres. In the reactive case it is necessary to interrogate the pMAG to obtain such information.

> The savings due to RAMS apply not only to RFC6224, but to any other
> solution which could depend on the answer of the MN to the MLD Query
> sent by the nMAG.

Maybe. But my question is, in what kind of situation (or what is the use case that) your reactive handover is useful, or faster than proactive handover?

[Luis>>] The reactive case is always longer than the proactive. But both cases are feasible. If the MN signals the de-registration before entering a nMAG, then we have the proactive case. On the contrary, if the MN attaches a nMAG without a previous de-registration of the pMAG, we then have a reactive case. Both situations can happen during the lifetime of a communication, and both have different performance.

>> Regarding the reactive handover, sect.4.2.1 says;  "After receiving
>> the PBU message from the nMAG, the LMA will take the
>>   decision of interrogating or not the pMAG regarding any existing
>>   multicast subscription for that MN.
>>   Once the multicast subscription information is retrieved from the
>>   pMAG, the LMA encapsulates it in the PBA message by using the TLV
>>   option "Active Multicast Subscription", and forwards the PBA message
>>   to the nMAG. Then, the nMAG can subscribe the multicast flow on
>>   behalf of the MN, if there is no other MN receiving it already at the
>>   nMAG."
>> However, the reactive handover explained in section 4 requires
>> exchanging many messages and complex procedures, and I cannot find
>> the big advantage of providing such extension.
>
> Let me explain in few words. Two are the processes involved:
>
> 1/ When an MN maintains an active subscription, a flag is maintained
> in the LMA indicating that (it is not relevant the channel subscribed,
> because this is dynimic; it is only relevant that the MN has an active
> subscription)

I may not understand this.
Whenever MN subscribes some channels, pMAG sends DeReg PBU including the subscription information (*) to LMA, and LMA transfers it to nMAG via PBA including the subscription information (*). Then nMAG operates to forward data to the MN if needed.
Why another "active" flag and message transmission is needed?

(*) This message extension is needed. In my PMIPv6 extension draft, PBU-M and PBA-M are defined for each.

[Luis>>] I think we have to improve the text of the proposal in order to make it clear. The flag for activity indication is needed only to indicate that the MN maintains an active subscription. That flag is stored in the LMA (it could be also stored in the profile). This flag is activated once the MN request a channel for first time (e.g., by means of an MLD Report). An stationary MN which change its subscription requesting a different channel does not introduce new signaling. Anything changes. The flag continuous to be set up. Once the MN changes from pMAG to nMAG is when either the reactive or the proactive mechanisms take place. And these mechanisms are introduced to transfer the subscription information. Hope it is more clear now.

> 2/ When the MN moves to a new access network, as consequence of the
> registration process at the nMAG, the LMA checks the flag, and in case
> the flag is set, it request to the pMAG the subscription information
> (IP addresses of the source and the multicast group) to be passed to
> the nMAG, completing the registration. (In case th flag is not set up,
> meaning that there is no active subscription, the registration process
> is done as in
> RFC5213)

Whether the MN subscribes some channel or not, LMA gets DeReg PBU.
If DeReg PBU includes MN's subscription info, LMA does not need to newly ask the MN's subscription information.
Why additional message for transmitting the subscription info must be defined?

[Luis>>] The new message is needed in the reactive case, because there is no previous de-registration from pMAG (the LMA registers that the MN is yet anchored to pMAG)

> Hopefully now is better understood.

I think I understand the procedure you defined. But I don't understand why your reactive handover procedure should be defined as well as the proactive handover.
Is there any technical reason? Or there is some configuration or policy requirement I missed?

[Luis>>] I hope now is more clear. If not, please let me know. I'll try to answer quicker. Anyway I see that the text of the proposal should be severely improved to make it more clear.
Best regards,

Luis

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

Este mensaje se dirige exclusivamente a su destinatario. Puede consultar nuestra política de envío y recepción de correo electrónico en el enlace situado más abajo.
This message is intended exclusively for its addressee. We only send and receive email on the basis of the terms set out at.
http://www.tid.es/ES/PAGINAS/disclaimer.aspx

---

From: Hitoshi Asaeda <[email-masked]>
Date: Thu, 08 Dec 2011 17:56:48 +0900 (JST)

Hi Luis,

Thank you for your reply.
I understand most of the points.

> Whenever MN subscribes some channels, pMAG sends DeReg PBU including
> the subscription information (*) to LMA, and LMA transfers it to
> nMAG via PBA including the subscription information (*). Then nMAG
> operates to forward data to the MN if needed.
>> [Luis>>] I think we have to improve the text of the proposal in
>> order to make it clear. The flag for activity indication is needed
>> only to indicate that the MN maintains an active subscription. That
>> flag is stored in the LMA (it could be also stored in the
>> profile). This flag is activated once the MN request a channel for
>> first time (e.g., by means of an MLD Report). An stationary MN
>> which change its subscription requesting a different channel does
>> not introduce new signaling. Anything changes. The flag continuous
>> to be set up. Once the MN changes from pMAG to nMAG is when either
>> the reactive or the proactive mechanisms take place. And these
>> mechanisms are introduced to transfer the subscription
>> information. Hope it is more clear now.

I'd like to read the improved text for this extension in the revised
draft as there may be some question about the active flag.

Thanks for your effort.

Regards,
--
Hitoshi Asaeda