Subject: [netlmm] Multiple Interface support in PMIPv6

From: Vijay Devarapalli <[email-masked]>
Date: Mon, 12 Nov 2007 14:07:43 -0800

Hello folks,

Here is a draft that analyzes various scenarios when a mobile node with
multiple interfaces attaches to a PMIPv6 domain.

http://www.ietf.org/internet-drafts/draft-devarapalli-netlmm-multihoming-01.txt

It talks about three cases, 1) Unique prefix per interface, 2) Unique
address per interface and 3) Shared address across interfaces. It also
addresses inter-access technology handovers.

Comments/reviews are welcome.

Vijay

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

---

From: "George Tsirtsis" <[email-masked]>
Date: Thu, 29 Nov 2007 17:11:16 +0000

Vijay,

Here are some comments:

At a high level I argue that context transfer by itself does not help
and that the suggested use of AAA is undesirable. In the end all this
only makes sense if the end node sends specific indications....one way
or another. See detailed comments and explanation below.

Thanks
George

-------------------------------------------------------------------------------------------
3.1.  Unique Prefix per Interface

...
   The Proxy Mobile IPv6 specification [2] does not specify any
   mechanism for MAG3 to figure out if the mobile node is performing a
   handover for if1 or if it is attaching to the Proxy Mobile IPv6
   domain for the first time via if1.  One option is for MAG3 to obtain
   this information via context transfer from MAG1.  This solution
   requires a context transfer interface between MAG1 and MAG3.

GT> Even if a CT interface exists between MAG1 and MAG3, how does MAG3
know to contact MAG1?

    Another
   option is for MAG3 to be told by the AAA infrastructure as part of
   access authentication that the mobile node was previously attached to
   the Proxy Mobile IPv6 domain via if1.  However, this solution may not
   work in case the AAA infrastructure does not store interface related
   information or if the AAA infrastructure is not being used.  One
   solution that may work in most cases is for the mobile node to
   indicate to MAG3 that it already has sessions on top of the prefix
   assigned to if1 and it is performing a handover.  The mobile node
   conveys this information as part of Layer 2 setup.  When MAG3 gets
   this information, it sets the Handover Indication field in the Access
   Technology Type option to indicate a handover for if1.

GT> Yes, I think this is the most realistic/generic option.

GT> One thing not investigated here is what happens if the mobile
hands-off if1 from MAG1 to MAG2, while if2 is already connected to
MAG2. I think this scenario requires a bit more investigation and may
have different implications depending on the nature of the MN to MAG
interface (i.e., shared or p2p).

3.1.1.  Inter-Access Technology Handovers
...
   The mobile node moves and attaches to the same Proxy Mobile IPv6
   domain via MAG2 using if2.  The mobile node may not have connectivity
   on if1 anymore.

GT> How can MAG2 and the LMA know that? And what happens if if1 is
still active? I think these two things have to be discussed a lot more
extensively here.

...
   For the above inter-access technology handover to work, the LMA must
   know that this is a handover involving two different interfaces of
   the mobile node.  The Interface Identifier option if present in the
   Proxy Binding Update from MAG2 will have a different identifier from
   what is stored in the binding cache entry on the LMA.  So this might
   appear to the LMA as if the mobile node is attaching via a different
   interface.

GT> Not only that, the access type will be different in this case too.

   The Proxy Binding Update from MAG2 MUST have the Handover
   Indication field in the Access Technology Type option set to "2" or
   "3" to indicate that it is a handover.  See Section 3.1 for a
   detailed description of how MAG2 determines when to indicate in the
   Proxy Binding Update that it is a handover.

GT> I think the mechanisms in 3.1 can not be reused here so easily; or
at least they deserve another look.
-	Context Transfer for example can not by itself be helpful because
unlike section 3.1 here you are talking about different interfaces on
different access types. So, the existence of state regarding if1/type1
on MAG1 can not imply by itself that the same state should be moved to
MAG2 to be applied to if2/type2.
-	AAA can in theory be used for this but I find such use of AAA
undesirable since the AAA will have to be aware of the configuration
of a particular device i.e., when a user changes the end device
(adds/removes/combines interfaces) the AAA will have to be updated
with the new relationships.
-	The explicit indication from the mobile seems to work but it now has
to be more specific than before i.e., when mobile connects if2/type2
it needs to indicate that it is handing-off if1/type2. IMO (as I have
stated before) it would be much easier for the mobile and the network
to instead hide if1/type1 and if2/type behind a virtual interface and
just present that virtual-IID to the network, in which case all the
options of section 3.1 apply.

   The mobile node must also be able to move the prefix from if1 to if2
   during the handover for the inter-access technology handover to work.
   A regular IPv6 mobile node, with no multi-homing support, may get
   confused if it sees the same prefix over two different interfaces.

3.1.2.  Mobile node with three or more interfaces

   This section considers a handover scenario for a mobile node with
   three or more interfaces and performing a handover from if1 to if3
   while staying connected over if2.  It is assumed that the mobile node
   is attached to MAG1 using if1, MAG2 using if2 and MAG3 using if3.  In
   this scenario, even if MAG3 knows that it is a handover, it does not
   which two interfaces are involved in the handover.  The AAA
   infrastructure does not help here since the AAA does not know which
   interface is being handed off to which one.  The only possible
   solution here is for the mobile node to tell MAG3 more information
   about if1 or the home network prefix assigned to if1 or information
   about MAG1.  MAG3 may indicate in the Proxy Binding Update
   information about if1 or the prefix assigned to if1 in the Proxy
   Binding Update sent to the LMA.  The LMA uses this information to
   assign the prefix that was assigned to if1 to if3 also.  In case the
   mobile node provides information about MAG1, then MAG3 can contact
   MAG1 over a context transfer interface and obtain more information
   about if1 or the home network prefix assigned to if1.  In all cases,
   MAG3 indicates that it is a handover in the Proxy Binding Update.

GT> I would argue that scenario in 3.1.1 should be handled exactly
like scenario 3.1.2. The simple reason is that just because a mobile
has 2 interfaces active at one time, it can not be assumed that these
are all the interfaces available to it. So, what happens if you assume
only 2 interfaces and then the mobile connects a 3rd? it makes no
sense to ever assume only 2!

George