Subject: Re: [multimob] OFFLIST: Charter and draft submission deadlines

From: <[email-masked]>
Date: Wed, 2 Mar 2011 13:19:16 +0100

Dear all,
Hopefully I understand the AMT draft well enough - currently I think that an enhancement of PMIP entities with AMT functionality would allow for similar optimizations as proposed:

   Each MAG with multicast subscribing MNs attached behaves as an AMT
   Gateway which has already established via a three way handshake a
   tunnel to AMT Relay or does so on subcription of a MN - similar to an
   M-Tunnel set-up as proposed in [I-D.asaeda-multimob-pmip6-extension].

   Since between MAG and LMA already a security association may be
   already established according to RFC5213, the handshake mechanism may
   be not required.
   
   A dedicated multicast LMA or a local MR with native multicast support
   behaves like an AMT Relay in that join messages are forwarded within
   the native Multicast environment and on the other hand received
   multicast traffic is subsequently forwarded via the AMT interface to
   the MAG/AMT Gateway.  Such a dedicated multicast DM-LMA is proposed by [I-D.zuniga-
   multimob-smspmip]
   
   The AMT relay can also provide direct local routing of traffic to the
   requesting MAG independent of any LMA as proposed in [I-D.sijeon-multimob-mms-pmip6].

Does that make sense?
Please comment!
Best regards
Dirk

-----Ursprüngliche Nachricht-----
Von: Behcet Sarikaya [mailto:[email-masked]] 
Gesendet: Montag, 28. Februar 2011 22:04
An: von Hugo, Dirk; [email-masked]
Betreff: OFFLIST: [multimob] Charter and draft submission deadlines

Hi Dirk,

> 
> Dear Stig, all
> Thanks for the reminder! AFAIAAO for the first new WI on  PMIPv6 routing 
>optimizations to avoid tunnel convergence problem we have at  least 4 different 
>drafts available tackling a potential solution such  as
> 

> I-D.ietf-mboned-auto-multicast:
>    WG MBONED (Multicast Backbone  Deployment) describes an approach which 
>allows
>    for automatic  multicast communication without explicit tunnels.  This 
>procedure
>     may be applied to isolated multicast-enabled sites or hosts which are  
>attached
>    to a network without native multicast support and removes  the need for 
>manual
>     configuration.

If you think this draft applies to our charter item then maybe we need a short 
draft explaining how.

Regards,

Behcet

---

From: Hitoshi Asaeda <[email-masked]>
Date: Wed, 02 Mar 2011 22:38:18 +0900 (JST)

Hi Dirk,

> Hopefully I understand the AMT draft well enough - currently I think
> that an enhancement of PMIP entities with AMT functionality would
> allow for similar optimizations as proposed:
> 

Well, AMT establishes a bi-directional tunnel between AMT gateway and
relay. This concept is similar to a bi-directional tunnel
establishment between LMA and MAG. Therefore one may think all
proposals using bi-directional tunnel look similar to the AMT at this
point.
However, as described in [I-D.asaeda-multimob-pmip6-extension], AMT
does not solve the fundamental problems, such as seamless handover and
local routing.
Also, an AMT gateway should have the IGMP/MLD proxy functionality.
This means, if MAG acts as an MLD proxy having a bi-directional tunnel
as proposed in the base solution, AMT is not necessary.

AMT is a protocol that simply establishes a bi-directional tunnel
bridging non-native multicast networks without explicit tunnel setup.

Regards,
--
Hitoshi Asaeda

---

From: <[email-masked]>
Date: Wed, 2 Mar 2011 15:55:50 +0100

Dear Hitoshi,
Thank you for the comments.  AFAIU the AMT draft the usage of IGMP/MLD messages for managing  groups is already foreseen there. And the AMT solution does also apply for mobility with change of AMT Gateway (like MAG) since it considers the case where the gateway that initially sent the AMT Request dynamically changes its IP address as does occur e.g. due to a link change in wireless networks.  Corresponding teardown messages are defined which would support at least 'a kind of' seamlessness.
And it is already a WG document and could be regarded as 'existing approach' ... Just to include it in the consideration (whether it is an optimum solution has to be evaluated).

And since any AMT relay (not only one at the LMA site) can be used it would enable local routing, no?

But how would you estimate the messaging effort - perhaps that would be a show stopper?

Thanks!

Best regards
Dirk

-----Ursprüngliche Nachricht-----
Von: [email-masked] [mailto:[email-masked]] Im Auftrag von Hitoshi Asaeda
Gesendet: Mittwoch, 2. März 2011 14:38
An: von Hugo, Dirk
Cc: [email-masked]
Betreff: Re: [multimob] OFFLIST: Charter and draft submission deadlines

Hi Dirk,

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

---

From: Hitoshi Asaeda <[email-masked]>
Date: Thu, 03 Mar 2011 12:28:58 +0900 (JST)

Hi Dirk,

> Thank you for the comments.  AFAIU the AMT draft the usage of
> IGMP/MLD messages for managing  groups is already foreseen
> there.

I cannot understand what you imply here, but I try to explain the
following statements.

> And the AMT solution does also apply for mobility with change
> of AMT Gateway (like MAG) since it considers the case where the
> gateway that initially sent the AMT Request dynamically changes its
> IP address as does occur e.g. due to a link change in wireless
> networks.  Corresponding teardown messages are defined which would
> support at least 'a kind of' seamlessness.

I think you are talking about a failover mechanism of AMT gateway.
If we assume MN acts as an AMT gateway, it'd be possible for the MN to
spontaneously switch to a different AMT relay due to its link failure
detection. But this is not our assumption; MNs should not be obliged
to install some additional functions. Moreover, if all MNs themselves
act as AMT gateways, they (all MNs) must *directly* establish their
own bi-dir tunnels to LMA acting as an AMT relay.
On the other hand, we may be able to consider the case that MAG acts
as an AMT gateway, and this is the case I've explained. However, in
this situation, the MAG acting as an AMT gateway does not support
handover or context transfer for each downstream MN. 

> And it is already a WG document and could be regarded as 'existing
> approach' ... Just to include it in the consideration (whether it is
> an optimum solution has to be evaluated).
> 

In my thought, this is not local routing, but "AMT relay selection
by the anycast mechanism". There is no routing dependency here.

Regards,
--
Hitoshi Asaeda

---

From: <[email-masked]>
Date: Thu, 3 Mar 2011 10:34:21 +0100

Dear Hitoshi,
Thanks for your answer - and sorry for additional questions, unfortunately I am not the Multicast expert ;-(

Please see my comments inline ... 

Best regards
Dirk

Hi Dirk,

=> I just referred to the AMT draft saying
   
  If the gateway is serving as a local router, it SHOULD also function
   as an IGMP/MLD Proxy, as described in [RFC4605], with its IGMP/MLD
   host-mode interface being the AMT pseudo-interface.

=> So the AMT approach should be in line with our charter.

=> I agree that we should not modify the MN for mobility support as we focus on PMIP!

=> Right, the pure AMT gateway does not, but can't we assume a combined MAG & AMT Gateway which can manage both - provide handover and mobility towards the MNs and control a separate Multicast tunnel towards the AMT relay for minimizing multiple packets downstream from the LMAs?

=> From formal wording you may be right - but isn't the effect a similar one, when the AMT Gateway discovers the 'optimum relay' ... Or does the anycast mechanism exclude the detection of a best suited local MR? Or even require extension of the Relay Discovery message - then of course the advantage of an 'existing approach' is no longer valid!
=> Thanks for your patience in advance ;-)

Regards,
--
Hitoshi Asaeda

---

From: Hitoshi Asaeda <[email-masked]>
Date: Thu, 03 Mar 2011 19:23:48 +0900 (JST)

>    host-mode interface being the AMT pseudo-interface.

Ok, then as I previously said;
> Also, an AMT gateway should have the IGMP/MLD proxy functionality.

It means, if I simplify the spec, AMT gateway provides a tunneling
protocol *having* the IGMP/MLD proxy function. If MAG already sets up
a tunnel between LMA, then MAG only needs the IGMP/MLD function (i.e.
no tunneling protocol required).

> => So the AMT approach should be in line with our charter.

In my mind, the basic IGMP/MLD proxy solution suffices your demand at
the same level.

> => I agree that we should not modify the MN for mobility support as

Right.

> => Right, the pure AMT gateway does not, but can't we assume a
>    combined MAG & AMT Gateway which can manage both - provide
>    handover and mobility towards the MNs and control a separate
>    Multicast tunnel towards the AMT relay for minimizing multiple
>    packets downstream from the LMAs? 

In your scenario, MAG (acting an AMT gateway) is the tunnel end-point,
and what is another tunnel end point (acting an AMT relay)? It must be
always LMA, right?
Then again, if we already set up MAG-LMA tunnel by the basic solution
or PMIP extension or whatever, why we need AMT?

> => From formal wording you may be right - but isn't the effect a
>    similar one, when the AMT Gateway discovers the 'optimum relay'
>    ... Or does the anycast mechanism exclude the detection of a best
>    suited local MR? Or even require extension of the Relay Discovery
>    message - then of course the advantage of an 'existing approach' is
>    no longer valid! 

AMT gateway discovers the optimam relay? "The optimam relay" and "best
suited local MR" you are saying seems not LMA. This breaks the current
LMA-MAG consolidation, no? It is beyond the scope, I bet.

> => Thanks for your patience in advance ;-)

No problem.;)

Regards,
--
Hitoshi Asaeda

---

From: <[email-masked]>
Date: Thu, 3 Mar 2011 13:24:03 +0100

Dear Hitoshi,
So if I understand you correctly you are saying that 
- AMT approach via tunneling and MLD proxy adds no new advantage to PMIP tunnel and moreover doesn't save effort  
- in case of AMT relay is no LMA (as for local or direct routing) this is again more complex than just adding MR capability to MAG - because local routing only applies when the multicast source is within the PMIP domain. For any content outside PMIP domain the M-LMA is the better (i.e. more optimum and PMIP consistent) choice.

That would rule out AMT approach for Route Optimization in case of PMIP-Multimob ...

Just being curious: May the AMT approach be a way to extend Multimob to non-PMIP?? Since we have in the charter also
 
   It is possible but not required that the solutions are applicable also for Mobile IPv6
   (MIPv6) based networks.

Thanks again and

Best regards
Dirk 
-----Ursprüngliche Nachricht-----
Von: Hitoshi Asaeda [mailto:[email-masked]] 
Gesendet: Donnerstag, 3. März 2011 11:24
An: von Hugo, Dirk
Cc: [email-masked]
Betreff: Re: AW: AW: [multimob]: Charter and draft submission deadlines

Right.

No problem.;)

Regards,
--
Hitoshi Asaeda

---

From: Hitoshi Asaeda <[email-masked]>
Date: Thu, 03 Mar 2011 23:25:34 +0900 (JST)

> - AMT approach via tunneling and MLD proxy adds no new advantage to
> PMIP tunnel and moreover doesn't save effort  

Yes.

> - in case of AMT relay is no LMA (as for local or direct routing)
> this is again more complex than just adding MR capability to MAG -
> because local routing only applies when the multicast source is
> within the PMIP domain. For any content outside PMIP domain the
> M-LMA is the better (i.e. more optimum and PMIP consistent) choice.

M-LMA means multicast enabled LMA? If so, yes.

> Just being curious: May the AMT approach be a way to extend Multimob
> to non-PMIP?? Since we have in the charter also
>  

I think it is possible to use AMT in MIPv6. But in this case, I don't
think any AMT or MIPv6 protocol modification is necessary. (This
means, AMT can just cooperate with MIPv6 without any extension because
MN having the AMT gateway function would simply discover an
appropriate AMT relay and attach to it.)

Regards,
--
Hitoshi Asaeda

---

From: <[email-masked]>
Date: Fri, 4 Mar 2011 13:05:33 +0100

Thanks, Hitoshi,
So I think I will prepare a corresponding draft for the agenda item as suggested by Behcet, and include you as co-author, if you don't bother?

Concerning the mentioned 'MN having the AMT gateway function' that might result in a big functionality set on a usually small, power- and size limited MN ... For a NEMO router this is surely appropriate, but for a pure single-customer operated MN perhaps a reduced lite-AMT version would be a better approach, what do you think?

Thanks and best regards
Dirk 

-----Ursprüngliche Nachricht-----
Von: Hitoshi Asaeda [mailto:[email-masked]] 
Gesendet: Donnerstag, 3. März 2011 15:26
An: von Hugo, Dirk
Cc: [email-masked]
Betreff: Re: AW: AW: AW: [multimob]: Charter and draft submission deadlines

Yes.

Regards,
--
Hitoshi Asaeda

---

From: Stig Venaas <[email-masked]>
Date: Mon, 07 Mar 2011 11:19:02 -0800

>> PMIP tunnel and moreover doesn't save effort

I'm not sure how useful AMT is to us either.

If we just use AMT as it is, then I'm inclined to think of it as
local multicast support. Multicast is somehow provided separate
from the PMIP infrastructure.

That is, does it make much difference to us from a protocol point
of view whether MAG receives multicast natively from local routers
or whether it is tunneled with the help of AMT or some other
mechanism from a router somewhere that supports multicast? How exactly
the multicast is received doesn't matter much to us unless it somehow
relates to PMIP and/or mobility. The provider deploying PMIP and
multicast can pretty much choose this independently and make
different choices.

I'm interested in hearing though if there are particular benefits
with AMT, or ways it can fit with e.g. PMIP. But at least so far,
I'm not so sure.

I think AMT is pretty cool and has its use, just not sure how it
applies to us. It may also be a concern that there are very few
implementations and little deployment so far. I'm hoping that may
change.

Stig

---

From: Stig Venaas <[email-masked]>
Date: Mon, 07 Mar 2011 11:27:11 -0800

> Concerning the mentioned 'MN having the AMT gateway function' that might result in a big functionality set on a usually small, power- and size limited MN ... For a NEMO router this is surely approp…

I was assuming the MAG was the gateway.

AMT can certainly be implemented in hosts, and could be in a MN. In that
case, what can we do? In the access network and wrt PMIP, wouldn't we
only see unicast traffic? It would be a reasonable solution if there was
no multicast support in the network (locally nor PMIP), but we are
trying to do something better. It would also result in waste of
bandwidth, losing the benefit of multicast.

Stig

---

From: <[email-masked]>
Date: Tue, 8 Mar 2011 10:38:46 +0100

Dear Stig,
As you may have detected we meanwhile have submitted a draft at http://www.ietf.org/internet-drafts/draft-von-hugo-multimob-ro-compa-00.txt in which we also resume that AMT for PMIP would not make too much sense (neither MN nor MAG), but that 'Client-MIP6' hosts or (mobile) routers might be a possible use case for AMT deployment ...  If one understands the charter in the sense that the non-PMIP application is foreseen only as add-on to a PMIP case, then this may not be in the focus of our WG now ;-(

Is that a unanimous understanding?

Thanks and best regards
Dirk 

-----Ursprüngliche Nachricht-----
Von: Stig Venaas [mailto:[email-masked]] 
Gesendet: Montag, 7. März 2011 20:27
An: von Hugo, Dirk
Cc: [email-masked]; [email-masked]
Betreff: Re: [multimob] : Charter and draft submission deadlines

Stig

---

From: Stig Venaas <[email-masked]>
Date: Wed, 09 Mar 2011 14:48:12 -0800

> As you may have detected we meanwhile have submitted a draft at http://www.ietf.org/internet-drafts/draft-von-hugo-multimob-ro-compa-00.txt in which we also resume that AMT for PMIP would not make…

Without saying anything conclusive now, I think at least our focus is
on PMIP for most of our work. It's great if we come up with things that
have a greater applicability though. Also, what work items we may have
are a bit restrictive, but as long as it doesn't distract us from
working on those, I like us to discuss other related topics.

I read the draft maybe a bit too quickly now, but everything there
looks quite reasonable, unless I missed something...

Stig