Hi and Happy New Year
I haven't write to this group is some years and may be I am missing something
but I have a question after reading the draft:
Why considering the time to answer a Query to calculate the latency in the
handover?
The MN can send the IGMP/MLD messages without waiting for a Query.
Below there is a copy of the part 5.1 of the RFC 3376.
Regards
Alvaro
FROM RFC 3376
There are two types of events that trigger IGMPv3 protocol actions on
an interface:
o a change of the interface reception state, caused by a local
invocation of IPMulticastListen.
o reception of a Query.
(Received IGMP messages of types other than Query are silently
ignored, except as required for interoperation with earlier versions
of IGMP.)
The following subsections describe the actions to be taken for each
of these two cases. In those descriptions, timer and counter names
appear in square brackets. The default values for those timers and
counters are specified in section 8.
5.1. Action on Change of Interface State
An invocation of IPMulticastListen may cause the multicast reception
state of an interface to change, according to the rules in section
3.2. Each such change affects the per-interface entry for a single
multicast address.
A change of interface state causes the system to immediately transmit
a State-Change Report from that interface. The type and contents of
the Group Record(s) in that Report are determined by comparing the
filter mode and source list for the affected multicast address before
and after the change, according to the table below. If no interface
state existed for that multicast address before the change (i.e., the
change consisted of creating a new per-interface record), or if no
state exists after the change (i.e., the change consisted of deleting
a per-interface record), then the "non-existent" state is considered
to have a filter mode of INCLUDE and an empty source list.
etc.
-----Mensaje original-----
De: [email protected] en nombre de LUIS MIGUEL CONTRERAS MURILLO
Enviado el: lun 31/12/2012 18:14
Para: [email protected]
Asunto: [multimob] RV: New Version Notificationfor
draft-ietf-multimob-handover-optimization-01.txt
Dear colleagues,
The version -01 of draft-ietf-multimob-handover-optimization has been just
uploaded, covering the following points according to the comments received:
.- List of requirements for handover optimization
.- IPv4 support
.- Compatibility with different versions of MLD/IGMP
Best regards, and Happy New Year,
Luis
-----Mensaje original-----
De: [email protected] [mailto:[email protected]]
Enviado el: lunes, 31 de diciembre de 2012 18:05
Para: LUIS MIGUEL CONTRERAS MURILLO
CC: [email protected]; [email protected]
Asunto: New Version Notification for
draft-ietf-multimob-handover-optimization-01.txt
A new version of I-D, draft-ietf-multimob-handover-optimization-01.txt
has been successfully submitted by Luis M. Contreras and posted to the IETF
repository.
Filename: draft-ietf-multimob-handover-optimization
Revision: 01
Title: PMIPv6 multicast handover optimization by the Subscription
Information Acquisition through the LMA (SIAL)
Creation date: 2012-12-30
WG ID: multimob
Number of pages: 47
URL:
http://www.ietf.org/internet-drafts/draft-ietf-multimob-handover-optimization-01.txt
Status:
http://datatracker.ietf.org/doc/draft-ietf-multimob-handover-optimization
Htmlized:
http://tools.ietf.org/html/draft-ietf-multimob-handover-optimization-01
Diff:
http://www.ietf.org/rfcdiff?url2=draft-ietf-multimob-handover-optimization-01
Abstract:
This document specifies a multicast handover optimization mechanism
for Proxy Mobile IPv6 to accelerate the delivery of multicast traffic
to mobile nodes after handovers. The mechanism is based on speeding
up the acquisition of mobile nodes' multicast context by the mobile
access gateways. To do that, extensions to the current Proxy Mobile
IPv6 protocol are proposed. These extensions are not only applicable
to the base solution for multicast support in Proxy Mobile IPv6, but
they can also be applied to other solutions being developed to avoid
the tunnel convergence problem. Furthermore, they are also
independent of the role played by the mobile access gateway within
the multicast network (either acting as multicast listener discovery
proxy or multicast router).
The IETF Secretariat
________________________________
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
_______________________________________________
multimob mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/multimob
_______________________________________________
multimob mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/multimob
