Subject: [MEXT] Fwd: I-D Action:draft-tsirtsis-logically-separate-lmaha-00.txt

From: "George Tsirtsis" <[email-masked]>
Date: Tue, 25 Mar 2008 10:49:22 +0000

Hi all,

Krishnan and I put together a draft describing what the expected
behavior of a combined LMA/HA implementation should be. This should
help the discussions around the so called scenario C of the PMIP-MIPv6
interactions draft (draft-giaretta-netlmm-mip-interactions).

I hope you find the discussion in this draft useful.
Please let us know if you have any comments/questions.

Regards
George

---------- Forwarded message ----------
From:  <[email-masked]>
Date: 2008/3/25
Subject: I-D Action:draft-tsirtsis-logically-separate-lmaha-00.txt
To: [email-masked]

A New Internet-Draft is available from the on-line Internet-Drafts directories.

        Title           : Behavior of Collocated HA/LMA
        Author(s)       : G. Tsirtsis, S. Krishnan
        Filename        : draft-tsirtsis-logically-separate-lmaha-00.txt
        Pages           : 9
        Date            : 2008-03-25

 In discussions about PMIPv6-MIPv6 interactions in NETLMM WG, scenario
 C describes the case of collocation of LMA and HA function.  In this
 case a PMIP network emulates the "home link" for MNs using MIPv6.
 This document argues that even when LMA and HA functions are
 Collocated they MUST be treated as logically separate entities.  In
 particular this draft argues that PMIP BCEs MUST NOT overwrite MIPv6
 BCEs and vice versa.

 A URL for this Internet-Draft is:
 http://www.ietf.org/internet-drafts/draft-tsirtsis-logically-separate-lmaha-00.txt

 Internet-Drafts are also available by anonymous FTP at:
 ftp://ftp.ietf.org/internet-drafts/

 Below is the data which will enable a MIME compliant mail reader
 implementation to automatically retrieve the ASCII version of the
 Internet-Draft.

_______________________________________________
 I-D-Announce mailing list
 [email-masked]
 https://www.ietf.org/mailman/listinfo/i-d-announce
 Internet-Draft directories: http://www.ietf.org/shadow.html
 or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
_______________________________________________
MEXT mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mext

---

From: "Kilian Weniger" <[email-masked]>
Date: Tue, 25 Mar 2008 17:05:01 +0100

Hi all,

there has been little progress on the topic of interworking between MIPv6 and PMIPv6 recently. One reason is that the authors of draft-giaretta-netlmm-mip-interactions so far couldn't agree on the general approach to solve the interworking scenario, where the HA and LMA are co-located and the MN's mobility management scheme changes between PMIPv6 and MIPv6 during a session (i.e., MIPv6 HoA == PMIPv6 HoA). This scenario is called "scenario C" and is described in detail in draft-giaretta-netlmm-mip-interactions-02.

There are currently two approaches on the table to solve scenario C:

  1) One BCE per MN for PMIPv6-MIPv6 handovers (see draft-giaretta-netlmm-mip-interactions-02)

       BCE is equally shared by PMIPv6 and MIPv6, i.e., 
       MN and MAG change the same BCE. Neither of the
       mobility schemes is prioritized over the other.

  2) Two BCEs per MN for PMIPv6-MIPv6 handovers (see draft-tsirtsis-logically-separate-lmaha-00.txt)

       One BCE for PMIPv6 and one BCE for MIPv6. 
       The HA/LMA always prefers the MIPv6 BCE over the 
       PMIPv6 BCE for forwarding data packets, i.e., 
       PMIPv6 BCE is only used if the MIPv6 BCE is emtpy.

The current interactions draft draft-giaretta-netlmm-mip-interactions-02 assumes approach 1), whereas draft-tsirtsis-logically-separate-lmaha-00.txt proposes approach 2).

We would like to hear the WG's comments and opinions about both approaches. 

Thanks,

Kilian

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of George Tsirtsis
> Sent: Dienstag, 25. März 2008 11:49
> To: Netlmm
> Cc: [email-masked]
> Subject: [MEXT] Fwd: 
> I-DAction:draft-tsirtsis-logically-separate-lmaha-00.txt
> 
> Hi all,
> 
>         Filename        : 
> draft-tsirtsis-logically-separate-lmaha-00.txt
>         Pages           : 9
>         Date            : 2008-03-25
> 

Panasonic R&D Center Germany GmbH
63225 Langen, Hessen, Germany
Reg: AG Offenbach (Hessen) HRB 33974
Managing Director: Thomas Micke

---

From: "Kilian Weniger" <[email-masked]>
Date: Tue, 25 Mar 2008 17:04:58 +0100

Hi George,

I have some clarifying questions regarding section 4.1.1 of your draft, which argues why sharing a single BCE between MIPv6 and PMIPv6 is supposed to be wrong in draft-giaretta-netlmm-mip-interactions-02. All three arguments mentioned in the draft are about scenarios where the MN has multiple active network interfaces (with or without MIPv6 multihoming). However, I don't really understand the logic of these arguments and why they apply, maybe you can elaborate. 

  1) "Directing traffic between foreign links: If an MN can maintain two
      links at the same time, it can direct traffic to one or the other
      link by simply sending a BU to its HA, registering the CoA
      corresponding to one or the other link."

Why is this scenario related to PMIPv6-MIPv6 interactions? This is a pure MIPv6 scenario not related to the discussion of shared vs. separate BCEs for PMIPv6 and MIPv6, right?

  2) "Directing traffic between home and foreign link: If one of the
      links maintained is the home link, the MN can direct traffic to it
      by sending a deregistration MIPv6 BU to the HA over the home link,
      while it can also direct traffic to the foreign link by sending a
      MIPv6 BU to the HA directing traffic to the CoA of the foreign
      link."

If I understand the scenario correctly, the MN has one active interface connected to the home link and another active interface connected to a foreign link and wants to switch dynamically between both without moving. Since we are not talking about HAs extended by MIPv6 multihoming/monami6 extensions here, is this special scenario even supported by RFC3775? I think it is not, since both the MN and the HA would defend the HA on the home link.

  3) "Directing traffic between Multiple links: MEXT WG is also working
      on [I-D.ietf-monami6-multiplecoa] and
      [I-D.soliman-monami6-flow-binding] specifications allowing an MN
      to register multiple links (multiple CoAs and the home link) to
      its HA at the same time and even direct different flows to
      different links."

      It should be clear that none of this can be possible if every time
      the MN connects to its home link, the corresponding PMIPv6 BCE
      overwrites the HA BCEs for the same mobile or every time the MN sends
      a BU to its HA over a foreign link, the MIPv6 BCE overwrites the LMA
      BCE entry for the same MN."

This argument only applies to monami6 HAs. However, monami6 is out of the agreed scope of the MIPv6-PMIPv6 interactions draft. draft-giaretta-netlmm-mip-interactions-02 says 

  "Note that the issues are described based on current
   specification and does not assume any optimized solution for any
   scenario.  The specifications considered as a baseline for the
   analysis are the following: [RFC3775], [RFC4877] and [pmipv6-draft]."

Thanks,

Kilian

---

From: "George Tsirtsis" <[email-masked]>
Date: Tue, 25 Mar 2008 16:37:56 +0000

Hi Kilian,

I appreciate you reading the draft so quickly, see below some comments.

>  Why is this scenario related to PMIPv6-MIPv6 interactions? This is a pure MIPv6 scenario not related to the discussion of shared vs. separate BCEs for PMIPv6 and MIPv6, right?

GT> This scenario does not present a problem for PMIP-MIP
interactions. It is presented in the draft since for some people
thinking about alternating between CoAs of two foreign links while
both of the foreign links are up sounds natural. In the draft I am
simply arguing that the same should be possible between a home and a
foreign link.

>  If I understand the scenario correctly, the MN has one active interface connected to the home link and another active interface connected to a foreign link and wants to switch dynamically between…

GT> Kilian, please reconsider your thinking on this. RFC3775 fully
supports this scenario. There is a parallel thread in MEXT where this
is being discussed. RFC3775 does not say anything about how many IP
interfaces the MN has. The only think RFC3775 says is that only one
CoA is registered at any one time. An MN can obviously have two (or
more) IP links e.g., one over 3G and another over WLAN. These IP
interfaces have their own addresses, which are potential care-of
address in MIPv6. RFC3775 defines that only one of them can be
registered at any one time. MCoA extensions allow more than one to be
registered at the same time.

GT> The above should be blindingly obvious to anyone who has ever
implemented Mobile IP for inter-technology handoffs. People who doubt
this, should check any one the many Mobile IP based WLAN to 3G handoff
implementations. Most companies in the wireless space have tried this
at least internally over the last several years. I know for a fact
that the implementation I was involved with did exactly that and I bet
most others do the same. This is obvious since different airlink
technologies tend to overlap in coverage causing the MN to be
connecting to both of them at the same time. at least for a time (...a
long time of the MN stays in the overlap zone). By registering either
one CoA or the other the MN switches between the two available links
based on SNR ot policy parameters..

>  This argument only applies to monami6 HAs. However, monami6 is out of the agreed scope of the MIPv6-PMIPv6 interactions draft. draft-giaretta-netlmm-mip-interactions-02 says

GT> The MCoA considerations in this draft are there to remind people
what else is possible given features we are developing in MEXT and the
fact that implementing BCEs in the wrong day today, may affect
features tomorrow. It would be rather shortsighted to ignore what we
know is coming. In any case, as you see above the issue exists even
without considering MCoA.

---

From: "George Tsirtsis" <[email-masked]>
Date: Tue, 25 Mar 2008 16:42:55 +0000

Killian, let's stop cross posting to MEXT and continue this discussion
in NETLMM list ONLY!
This should be the last e-mail to MEXT on this topic.

Thanks for your help
George

---

From: Hesham Soliman <[email-masked]>
Date: Wed, 26 Mar 2008 19:37:45 +1100

Please take mext out of this thread. This is a NETLMM draft.

On 26/03/2008, at 3:05 AM, Kilian Weniger wrote:
> Hi all,
>
> there has been little progress on the topic of interworking between  
> MIPv6 and PMIPv6 recently. One reason is that the authors of draft- 
> giaretta-netlmm-mip-interactions so far couldn't agree on the  
> general approach to solve the interworking scenario, where the HA  
> and LMA are co-located and the MN's mobility management scheme  
> changes between PMIPv6 and MIPv6 during a session (i.e., MIPv6 HoA  
> == PMIPv6 HoA). This scenario is called "scenario C" and is  
> described in detail in draft-giaretta-netlmm-mip-interactions-02.
>
> The current interactions draft draft-giaretta-netlmm-mip- 
> interactions-02 assumes approach 1), whereas draft-tsirtsis- 
> logically-separate-lmaha-00.txt proposes approach 2).
>

---

From: "Kilian Weniger" <[email-masked]>
Date: Wed, 26 Mar 2008 15:23:02 +0100

Hi George, 

thanks for the clarifications. Please see comments inline.

> >  If I understand the scenario correctly, the MN has one 
> active interface connected to the home link and another 
> active interface connected to a foreign link and wants to 
> switch dynamically between both without moving. Since we are 
> not talking about HAs extended by MIPv6 multihoming/monami6 
> extensions here, is this special scenario even supported by 
> RFC3775? I think it is not, since both the MN and the HA 
> would defend the HA on the home link.
> >
> 

Maybe we have different specific scenarios in mind. I agree of course
that generally an inter-technology handoff can be supported by RFC3775,
but an inter-technology handoff can also be supported by
draft-giaretta-netlmm-mip-interactions-02.txt when the BCE is
overwritten after the handover. Can you elaborate what exactly is the
problem when the BCE is overwritten in an inter-technology PMIPv6-MIPv6
handoff scenario? Let's discuss this using specific example scenarios.

The example scenario I had in mind from your description is as follows:
1. The MN is connected to the foreign link via interface 1 and the CoA
is registered at the HA
2. The MN switches on interface 2, which attaches to the home link.
Hence, interface 2 configures the MN's HoA.
3. Usually, the MN would now send a BU de-registration to update the HA
with the new location. As I understood your scenario, the MN now does
*not* send a BU de-registration, because it still wants to receive the
traffic via interface 1 for some reason. 

My comment was that this may be a problem, since both MN and HA would
defend the same HoA on the home link. AFAIK, RFC3775 doesn't specify the
case that the MN is attached to the home link and has the HoA
configured, but does not defend its HoA on the link (BTW, IMHO we should
discuss what the text in the RFC3775 specification supports, not what
some MIPv6 implementations support.)

> >  This argument only applies to monami6 HAs. However, 
> monami6 is out of the agreed scope of the MIPv6-PMIPv6 
> interactions draft. draft-giaretta-netlmm-mip-interactions-02 says
> >
> 

The point is that MCoA extensions are out of scope of the current
PMIPv6-MIPv6 interactions draft. It really doesn't make sense to discuss
out of scope topics IMHO. It is already difficult enough to have
progress with the in-scope topics. Mixing the discussion with potential
future extensions doesn't help progress at all IMHO.

Furthermore, you need to do a fair comparison. If you consider MIPv6
MCoA HA for the MIPv6-PMIPv6 handoffs, you also need to consider LMAs
with future PMIP MCoA + flow filtering extensions (which may involve the
MN). With such extensions in place, it will probably be possible to
support your scenario even when the single-CoA PMIPv6-MIPv6 handoff
scenario (which is the one that is actually for discussion now) is
solved by overwriting the BCE. A PMIP MCoA extension would extend the
single BCE in the LMA to multiple BCEs, because how can you ever support
multiple CoAs with a single BCE (Monami6 also specifies multiple BCEs)?
But again, such discussion is mood, since we don't know yet how a future
PMIP MCoA extension looks like. Let's focus on the scenarios that are in
scope of the PMIPv6-MIPv6 interactions draft now and that is the single
CoA handoff scenario.

Kilian

---

From: "George Tsirtsis" <[email-masked]>
Date: Thu, 27 Mar 2008 11:14:22 +0000

Killian, sorry for the delay in responding...things are a bit crazy
here. See comments inline.

>  traffic via interface 1 for some reason.

GT2> Yes, this is a valid example illustrating what I have been talking about.

>  some MIPv6 implementations support.)

GT2> There is nothing in RFC3775 preventing this. In fact, RFC 3775
(section 11.5.4) is very explicit about the fact that the MN MUST NOT
defend its HoA on the home link until AFTER it sends a BU to the HA,
so that you do not have two nodes on the same link defending the same
address. The RFC is also very specific about how the MN should
construct an NS message if one must be sent prior to the deregBU,
exactly for the same reason.

>  future extensions doesn't help progress at all IMHO.

GT2> I disagree. Making MCoA out of scope is arbitrary and wrong.
Documenting a PMIPv6 implementation that is clearly incompatible with
an already fully specified MIPv6 extension (in WG LC level) is wrong
and against NETLMM charter which requires PMIPv6 and MIPv6
compatibility. I repeat, however, that what you have been proposing is
even incompatible with RFC3775.

GT2> Kllian think about this carefully. PMIP MUST NOT be visible to
mobiles. A PMIP domain emulates a link and as far as the MN is
concerned, a link is a link, whether the link is using Ethernet, GTP,
PMIP or whatever. As you may know PMIP and GTP are now used almost
interchangeably in 3GPP Rel8 specifications. In this system the
following configurations are defined.
       (1)  the 3GPP Gateway implements a PMIP LMA and a MIPv6 HA, and
       (2) the 3GPP Gateway implements a GTP termination and a MIPv6 HA.
In both cases the GTP and PMIP domains emulate a home link for MIPv6
i.e., scenario C as we discuss here.

GT2> Could you imagine us having the same discussion we are having now
about PMIP-MIP interactions, about GTP-MIP interactions? Would you
find acceptable that a GTP registration overwrites a MIPv6 BCE?. It
would be unthinkable and anyone who proposed such a notion would be
laughed at. Why is it then so appealing to do this obviously wrong
thing when instead of GTP based link-emulation, we have PMIP based
link-emulation?

George