Subject: [multimob] RV: New Version Notification for draft-ietf-multimob-handover-optimization-01.txt

From: LUIS MIGUEL CONTRERAS MURILLO <[email-masked]>
Date: Mon, 31 Dec 2012 17:14:33 +0000

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-masked] [mailto:[email-masked]]
Enviado el: lunes, 31 de diciembre de 2012 18:05
Para: LUIS MIGUEL CONTRERAS MURILLO
CC: [email-masked]; [email-masked]
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

---

From: "Alvaro Fernandez" <[email-masked]>
Date: Mon, 31 Dec 2012 19:45:56 +0100

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-masked] en nombre de LUIS MIGUEL CONTRERAS MURILLO
Enviado el: lun 31/12/2012 18:14
Para: [email-masked]
Asunto: [multimob] RV: New Version Notificationfor	draft-ietf-multimob-handover-optimization-01.txt
 
Dear colleagues,

Luis

-----Mensaje original-----
De: [email-masked] [mailto:[email-masked]]
Enviado el: lunes, 31 de diciembre de 2012 18:05
Para: LUIS MIGUEL CONTRERAS MURILLO
CC: [email-masked]; [email-masked]
Asunto: New Version Notification for draft-ietf-multimob-handover-optimization-01.txt

Abstract:

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-masked]
https://www.ietf.org/mailman/listinfo/multimob