Re: [multimob] Fast Handover Solutions

[LUIS MIGUEL CONTRERAS MURILLO <[e-mail]>]

Hi all,

One additional comment on this.

It would be worthy to remark that a generic solution, non-dependent on layer-2 capabilities, has been adopted to avoid partial solutions not applicable to all the MNs in a network. This solution provides a uniform performance as it does not depend on the underlying radio particularities (framing, reliability, contention, etc) nor the multicast protocols specificities (like the IGMP/MLD timers, conceived for very distinct environment to the one addressed by PMIPv6). From an operator point of view, this predictability easies the planning of the access network and the expected performance guarantees to be delivered to the end user across all the access points in the network, especially for the upcoming heterogeneous access network scenarios. The unpredictability impacts on the usability of a protocol.

Best regards,

Luis
________________________________
Luis M. Contreras

Technology / Global CTO / Telefónica
Efficiency Projects / Telefónica I+D

Distrito Telefónica, Edificio Sur 3, Planta 3
28050 Madrid
España / Spain

[e-mail]


________________________________

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

--- Begin Message ---

Hi Thomas, all,

Please see some comments inline below.

On Mon, 2012-11-12 at 23:28 +0100, Thomas C. Schmidt wrote:
> Hi all,
>
> after the - somewhat uninformed discussion at IETF85 - chairs asked me
> to restate requirements of a "fast handover solution" for Multicast
> Mobility.

I don't recall the chairs asking you to restate the requirements of a
"fast handover solution", and the minutes do not reflect that either.
Our AD asked the WG to document the requirements of the different
solutions the WG is working on, as well as the feedback obtained from
operators interested in multimob work.

Actually, the WG already has a WG document for the fast handover
solution milestone, and during initial discussions and the adoption
process, we did have discussions on different aspects of how a fast
handover solution should operate and the different requirements it
should meet. There have been several reviews of the WG document and it
captures feedback from the WG.

>
> Here they are:

This list, IMHO, is not complete. For example, one critical aspect that
has been discussed several times is how generic the solution is and what
requirements it imposes on the different involved entities, as for
example the need of layer-2 triggers on the mobile node.

>
>   (i) Handover should be fast (this is only true for a direct pMAG/AR to
> nMAG/AR solution such as
> http://tools.ietf.org/html/draft-schmidt-multimob-fmipv6-pfmipv6-multicast).

The handover speed will highly depend on the network topology in place.
It cannot be generally stated that direct communication will always be
faster than MAG to LMA communication. In fact, taking into account
typical operative networks, an strict hierarchical topology is commonly
deployed where the communication among different elements located in
different access networks pass through central elements, using an star
topology. Considering that a MAG could be able to serve a huge number of
radio accesses, the more logical trend could be to deploy separated
MAGs, without direct connectivity capabilities. Additionally, as
previously discussed on this mailing list, you should note that the
reactive case for FPMIPv6 is extremely harmful from the multicast
handover delay perspective, as it needs to firstly register the MN and
resolve the MLD Query process of RFC6224 to trigger the reactive
mechanism afterwards. There is for sure no improvement regarding
RFC6224. Furthermore, the dependency on the radio part (for layer-2
trigger capabilities) definitely limits the potential benefits that your
proposal could provide.

>
>   (ii) Multicast handover should be fully synchronized with unicast
> handover (otherwise unicast and multicast states diverge as is a
> well-known issue for the RAMS-approach, i.e.,
> https://tools.ietf.org/html/draft-ietf-multimob-fast-handover).
>

The adopted WG document draft-ietf-multimob-fast-handover (previously
aka RAMS, now SIAL) is totally synchronized with the unicast handover,
up to the point that it is triggered by the registration and/or
de-registration messages of the unicast handover. It is difficult to
achieve a better integration. In the proactive case, the de-registration
message for unicast handover sent by the pMAG conveys the multicast
membership subscription context for the moving MN. In the reactive case,
the registration message for the MN attaching to the nMAG triggers the
process, and the response to the registration PBU conveys the multicast
membership subscription context. Do you really think these are not
synchronized processes?

BTW, what is the "well-known" issue you refer to?

>   (iii) Multicast handover solutions should tightly integrate with
> unicast handover (only
> http://tools.ietf.org/html/draft-schmidt-multimob-fmipv6-pfmipv6-multicast
> integrates with PFMIPv6 and FMIPv6).
>

The key point here is to be *integrated* with PMIPv6 in a *general* way.
The integration of SIAL with PMIPv6 is ensured as described above.
Furthermore, it is general because it does not impose the necessity of
additional layer-2 capabilities in the MN to work. This does not happen
with other solutions, including yours.

Additionally, this has been discussed already in the WG. Several
individuals, such as Marco, expressed that unicast and multicast
handovers have different considerations. The WG consensus was to not to
specify in the adopted document a solution bound to a unicast handover
optimization solution.

>   (iv) Handover management should reuse standard mobility and multicast
> protocol operations for easy implementation and deployment
> (http://tools.ietf.org/html/draft-schmidt-multimob-fmipv6-pfmipv6-multicast
> introduced the use of standard IGMP/MLD records for context description
> in transfer, which has been copied several times).

draft-ietf-multimob-fast-handover incorporated the use of the standard
multicast address record format as result of the WG feedback.

>
>   (v) Multicast handover management should integrate ASM and SSM, as
> well as IPv4 (IGMP) and IPv6 (MLD), which is only provided by
> http://tools.ietf.org/html/draft-schmidt-multimob-fmipv6-pfmipv6-multicast.

Since the SIAL solution deals with multicast membership subscription
context transfer, no issues relate to ASM and SSM. Regarding the IPv4
treatment, we thank you for pointing this out and this is going to be
addressed in the next revision of the document, as we discussed during
the Atlanta meeting. We don't foresee any significant issue on adding
that support, and we of course welcome any contribution from you or any
other WG member on this aspect.

>
> Based on these facts, chairs and AD proclaimed to re-decide on future
> paths for Multimob fast handover solutions.

Again, based on what I recall, that seems to match what is captured in
the minutes, what was discussed is that the AD would check with the
chairs the process of the adoption call of
draft-schmidt-multimob-fmipv6-pfmipv6-multicast. I don't quite see how a
formal process revision (decision of the chairs on a WG adoption
document) relates with your e-mail.

Thanks,

Carlos

>
> Cheers,
>
> Thomas

--
Carlos Jesús Bernardos Cano  http://www.netcom.it.uc3m.es/
GPG FP: D29B 0A6A 639A A561 93CA  4D55 35DC BA4D D170 4F67

--- End Message ---