Subject: [multimob] Comment on draft-sijeon-multimob-mms-pmip6-00

From: "Luis M. Contreras" <[email-masked]>
Date: Tue, 06 Oct 2009 00:06:28 +0200

Hi all,

I have one question/comment regarding 
draft-sijeon-multimob-mms-pmip6-00. There, the handover process uses a 
context transfer mechanism to minimise the multicast service 
disruption. The old MAG can predict the MNs movement and transfers the 
multicast context to the new MAG.

I can see this for a MN using the same wireless access technology in 
both old- and new-MAGs attachments. But, what about if the handover is 
a wireless technology handover, i.e., from an UMTS to a WiMax handover? 
Should the MAG take into account all the possible types of accesses in 
a certain area to decide/predict the contex transfer? Should be another 
element (e.g., LMA) to decide new MAG taking into account all the 
possible accesses sorrounding the moving MN?

Thanks in advance,

regards,
Luis

---

From: "Seil Jeon" <[email-masked]>
Date: Tue, 6 Oct 2009 15:12:40 +0900

Hi Luis,

Thanks for commenting.

That is good question. Simply speaking, there are several way how to
decide/predict the context transfer in heterogeneous network.

Most simple way is that all MAG have the information of adjacent MAG within
a range.

In another way, a cross-layering approach could be combined (e.g., MIH)

But, I think former is most realistic method.

Best Regards,

Seil Jeon

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Luis M. Contreras
Sent: Tuesday, October 06, 2009 7:06 AM
To: [email-masked]
Subject: [multimob] Comment on draft-sijeon-multimob-mms-pmip6-00

Hi all,

I have one question/comment regarding
draft-sijeon-multimob-mms-pmip6-00. There, the handover process uses a
context transfer mechanism to minimise the multicast service disruption.
The old MAG can predict the MNs movement and transfers the multicast
context to the new MAG.

I can see this for a MN using the same wireless access technology in both
old- and new-MAGs attachments. But, what about if the handover is a
wireless technology handover, i.e., from an UMTS to a WiMax handover? 
Should the MAG take into account all the possible types of accesses in a
certain area to decide/predict the contex transfer? Should be another
element (e.g., LMA) to decide new MAG taking into account all the possible
accesses sorrounding the moving MN?

Thanks in advance,

regards,
Luis

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

---

From: "Luis M. Contreras" <[email-masked]>
Date: Thu, 29 Oct 2009 23:42:45 +0100

Hi Seil,

I've been thinking about your answer to my previous comments on 

> But, I think former is most realistic method.

It seems that the info to collect from other MAGs to decide/predict the 
context transfer is necessary only to support handovers events for 
multicast MNs. The handover in the unicast case does not need to manage 
such information because RFC5213 provides a method for unicast 
handover. So, if the process and the signalling load between MAGs for 
collecting the info that helps to decide or predict the handover is an 
essential part of the method that you propose to work correctly, don't 
you think it would be needed to specify or sketch it in your draft? I 
think it would be nice to have an idea about the extra signalling and 
process complexity required in the MAGs in order to properly compare 
all the proposals.

More additional comments after reading your version -01.

1/ On the second paragraph of section 1 you state that: "... if a MAG 
has an MR function, a LMA needs to have MR function". You link this 
idea with the argument that a MAG implementing MR function can degrade 
the performance of PMIPv6 due to frequent routing overhead created by 
the MNs as they move. I think that the MR function in the MAG does not 
force to implement a MR function in the LMA. This is true if both the 
MAG and the LMA are back-to-back (and the MAG runs PIM protocol on the 
tunnel interface), but in a real network deployment both MAG and LMA 
could have a number of routers in between. Graphically, this could be 
the situation:

-------
| LMA |
-------
   ||
   ||
------------
|      MR  |
------------
   ||
   ||
-------
| MAG |
-------

In the graph above, the MAG implements the MR function and the router 
connected back-to-back to MAG also implements the MR function, running 
PIM both of them on the link connecting one to the other. The LMA is 
deeper in the core network, and the tunnel between MAG and LMA pass 
through the router implementing the MR function. Tha MAG does not run 
PIM on the tunnel interface (or even the LMA is not a PIM-enabled 
router). The multicast traffic between the multicast router and the MAG 
is of course out of the tunnel.
I think in this case your assumption of performance degradation when 
MAG implements MR function does not apply any more. In this scenario 
LMA is not aware of multicast traffic, while the MAG acts as multicast 
router. This can be extended to the case in which MAG is back-to-back 
with both the LMA and the mutlicast router but on separate links. The 
MAG would run PIM on the link connecting to the multicast router, but 
not in the link (tunnel) connecting to the LMA

-------    -------
| LMA |    |  MR |
-------    -------
   ||         |
   ||         |
------------------
|      MAG       |
------------------

What do you think?

2/ Looking at figure 2 it is not clear to me if the the multicast 
traffic received by the nMAG from the MR is immediately forwarded to 
the MN or if the proxy binding process should be finished first (before 
forwarding any traffic to the MN).

Sorry for this long mail,

Regards,

Luis

---

From: "Seil Jeon" <[email-masked]>
Date: Fri, 30 Oct 2009 19:37:40 +0900

Hi Luis,

Thank you for your comment. Please check my response.

-----Original Message-----
From: Luis M. Contreras [mailto:[email-masked]] 
Sent: Friday, October 30, 2009 7:43 AM
To: [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: RE: [multimob] Comment on draft-sijeon-multimob-mms-pmip6-00

Hi Seil,

I've been thinking about your answer to my previous comments on
draft-sijeon-multimob-mms-pmip6-00:

> Most simple way is that all MAG have the information of adjacent MAG 
> within a range.
>

multicast MNs.

=> Yes, in general case. But, context transfer mechanism is essential for
inter-technology handover in unicast case.

The handover in the unicast case does not need to manage such information
because RFC5213 provides a method for unicast handover. So, if the process
and the signalling load between MAGs for collecting the info that helps to
decide or predict the handover is an essential part of the method that you
propose to work correctly, don't you think it would be needed to specify or
sketch it in your draft? I think it would be nice to have an idea about the
extra signalling and process complexity required in the MAGs in order to
properly compare all the proposals.

==> That's good point. Actually, I didn't consider about that very
carefully.

But, I pointed out the need of context transfer mechanism and suggested
PMIPv6-based context transfer mechanism.

As you said, of course, I will provide detailed information.

1/ On the second paragraph of section 1 you state that: "... if a MAG has
an MR function, a LMA needs to have MR function". You link this idea with
the argument that a MAG implementing MR function can degrade the
performance of PMIPv6 due to frequent routing overhead created by the MNs
as they move. I think that the MR function in the MAG does not force to
implement a MR function in the LMA. This is true if both the MAG and the
LMA are back-to-back (and the MAG runs PIM protocol on the tunnel
interface), but in a real network deployment both MAG and LMA could have a
number of routers in between. Graphically, this could be the situation:

=>  If the MAG has a MR function regardless of connection between MAG and
LMA, the MAG should involve multicast routing update.

      Considering the scenario of dynamic service flow, the routing update
on the MAG will be increased as MNs move.

-------
| LMA |
-------
   ||
   ||
------------
|      MR  |
------------
   ||
   ||
-------
| MAG |
-------

=>  I can't understand how above figure could be made.

Where the multicast packets come from?

Without joining to another MR, how the LMA can receive multicast packets?

If a LMA use tunnel, why the MR should be involved in tunnel forwarding
procedure.

In the graph above, the MAG implements the MR function and the router
connected back-to-back to MAG also implements the MR function, running PIM
both of them on the link connecting one to the other. The LMA is deeper in
the core network, and the tunnel between MAG and LMA pass through the
router implementing the MR function. Tha MAG does not run PIM on the tunnel
interface (or even the LMA is not a PIM-enabled router). The multicast
traffic between the multicast router and the MAG is of course out of the
tunnel.
I think in this case your assumption of performance degradation when MAG
implements MR function does not apply any more. In this scenario LMA is not
aware of multicast traffic, while the MAG acts as multicast router. 

This can be extended to the case in which MAG is back-to-back with both the
LMA and the mutlicast router but on separate links. The MAG would run PIM
on the link connecting to the multicast router, but not in the link
(tunnel) connecting to the LMA

=> Yes, it is our idea. tunnel is existed between MAG and LMA. And, the MAG
has separated link with MR.

   However, one point is different. To reduce complexity and routing
overhead on the MAG, we propose IGMP/MLD proxy function on the MAG.

-------    -------
| LMA |    |  MR   |
-------    -------
   ||         |
   ||         |
-------------
|      MAG       |
-------------

What do you think?

2/ Looking at figure 2 it is not clear to me if the the multicast traffic
received by the nMAG from the MR is immediately forwarded to the MN or if
the proxy binding process should be finished first (before forwarding any
traffic to the MN).

==> Through joining to the MR by the N-MAG, the N-MAG can receive the
multicast packets.

After establishing point-to-point between MN and MAG, the MN can receive
the multicast packets.

Because the MAG does not receive multicast packets from LMA, PBU/PBA
process is not related to delivery the multicast packets from the MR.

==> No. it is not. I really appreciate your comments.

Regards,

Luis

---

From: "Luis M. Contreras" <[email-masked]>
Date: Fri, 30 Oct 2009 14:50:22 +0100

Thanks Seil,

> | LMA |

Please find enclosed a ppt drawing to better explain what I mean. 
Unicast traffic is always through LMA, multicast traffic is always 
through multicast router, and both traffics are carried through the 
physical interface linking MAG with one intermediate router (with MR 
function). Tha LMA has no multicast functions.

> process is not related to delivery the multicast packets from the MR.

Anyway multicast traffic pass through MAG, so MAG could decide to not 
forward it until MN full registration.

Thanks,

regards,

Luis

---

From: "Seil Jeon" <[email-masked]>
Date: Fri, 30 Oct 2009 23:29:16 +0900

Hi. Luis,

My response is below.

-----Original Message-----
From: Luis M. Contreras [mailto:[email-masked]] 
Sent: Friday, October 30, 2009 10:50 PM
To: [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: RE: [multimob] Comment on draft-sijeon-multimob-mms-pmip6-00

Thanks Seil,

some few comments below:

> If a LMA use tunnel, why the MR should be involved in tunnel 
> forwarding procedure?
>

Please find enclosed a ppt drawing to better explain what I mean. 
Unicast traffic is always through LMA, multicast traffic is always through
multicast router, and both traffics are carried through the physical
interface linking MAG with one intermediate router (with MR function). Tha
LMA has no multicast functions.

=> I checked picture what you said. It is absolutely different between
above figure and ppt drawing.
As you see the drawing in ppt, multicast router receives the multicast
packets from multicast tree.
And intermediate router is not multicast router. Is it right?
So, we can say the picture in the ppt is same as like following model.
In the case, there's no need to install multicast routing function at the
LMA.

----------    ----------
|   LMA    |    |     MR     |
----------    ----------
    ||               |
    ||               |
   -------------
   |      MAG       |
   -------------

> the MN or if the proxy binding process should be finished first 
> (before forwarding any traffic to the MN).
>
> After establishing point-to-point between MN and MAG, the MN can 
> receive the multicast packets.
>

=> full registration? PMIPv6?
As soon as the MAG finish to acquire MN profile from (AAA/Policy Store),
the MN can receive the multicast packets.
As I said above, it is not related to PBU/PBA action.

Thanks,

regards,

Luis