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
