Subject: Re: [netlmm] Multiple Interface support in PMIPv6

From: Vijay Devarapalli <[email-masked]>
Date: Mon, 25 Feb 2008 12:00:54 -0800

Hi George,

I forgot to reply to this email. I was going through the archives
and found this email again.

We re-organized the draft a bit. The handovers across interfaces
are now described in a separate section. We have added a new
section on requirements for a handover across interface using
PMIPv6 (thanks to Christian). It talks about what the mobile node
needs to do for a handover to work across interfaces. I will be
submitting a new version in the next couple of hours.

George Tsirtsis wrote:

> 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?

There are multiple options like the mobile node informing MAG3 that
it was attached to MAG1 before, or some "magic" in the network
telling MAG3 that the handover is from from MAG1. Anyway, I would
prefer not going into the details, since we don't have a concrete
specification on this.

> 
>     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.

Agree.

> 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).

It would appear to MAG2 as if the mobile node is attached with
two separate interfaces to the same MAG. I will add some text
on this scenario.

    Yet another handover scenario is where the mobile is attached to MAG1
    via if1 and MAG2 via if2, decides to attach to MAG2 via if3 and
    perform a handover from the if1 to if3.  In this scenario, the mobile
    node must indicate to MAG2 that it is performing a handover from if1
    by providing information about if1 when attaching to MAG2 using if3.
    MAG2 would then treat the attachment over if3 as a handover from if1
    and will indicate this in this Proxy Binding Update to the LMA.  The
    LMA would then assign the same prefix that was previously assigned
    for if1.  MAG would further treat existing attachment over if2
    separately and cause no modifications to the sessions over if2.

> 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.

I hope the new section on what the mobile node needs to do for a
handover across interfaces would be sufficient 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.

Does the LMA care? It know its a different interface. It doesn't
matter if the interface is of the same or different access type.

>    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.

Yes, that would work. But there are issues with it. 1) substantial
modification on the host. 2) the mobile node would have to know
beforehand which interfaces (among the multiple interfaces) it
needs to group under the virtual interface.

>    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!

The current sections are organized in this manner just for
describing each scenario separately. There seems to be a lot of
interest in a handover between two interfaces involving different
access technologies. So, there is a separate section on inter-
access technology handovers.

Vijay
_______________________________________________
netlmm mailing list
[email-masked]
http://www.ietf.org/mailman/listinfo/netlmm

---

From: Vijay Devarapalli <[email-masked]>
Date: Mon, 25 Feb 2008 14:27:52 -0800

Hello,

A revised draft on multiple interface support in PMIPv6 was
submitted today. You can find the draft at the following URL.

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

The main change is a new section on using PMIPv6 for handovers
across interfaces. It describes what is required on the mobile
node and the MAG and LMA behaviors.

Comments/reviews are welcome.

Vijay