Subject: Re: PMIP compatibility with multihoming RE: [netlmm] Re: Proposed text for resolving the multi-homed host issue

From: Behcet Sarikaya <[email-masked]>
Date: Tue, 2 Oct 2007 10:07:33 -0700 (PDT)

Dear all,
  Querreling over email aside , I kind of like George's description of the problem. I don't think it conflicts with Vijay's text, it is indeed complimentary.
  What I would like to add is that current SDO activity on interworking using PMIP is very hot but the assumption there is handover is inter-technology handover. So however we conclude this thread (in-scope, out-of-scope, etc.) is not going to invalidate the activity.

Secondly, the last case in George's text on 

Multiple connections with the same technology and to the same
administrative domain.

I think this case as it currently only applies to Wi-Fi can not be handled by PMIP6 base protocol due to the link model, Wi-Fi uses shared link model which is not supported by Sri's protocol.

Hope this helps.

Behcet
----- Original Message ----
From: "Tsirtsis, George" <[email-masked]>
To: Vijay Devarapalli <[email-masked]>; Basavaraj Patil <[email-masked]>
Cc: [email-masked]
Sent: Monday, October 1, 2007 1:33:08 PM
Subject: PMIP compatibility with multihoming RE: [netlmm] Re: Proposed text for resolving the multi-homed host issue

Hi Vijay et.al.,

The stated objective is that PMIP must not require any changes in the IP
stack of the host. I presume that this means that any "legal" IP stack
that attaches to a PMIP domain should work without knowing anything
about PMIP.

Claiming that you satisfy the objective by placing multi-homing out of
scope is a contradiction in terms, since any IP stack that is capable of
multi-homing, will not work properly when it is attached to a PMIP
domain, thus breaking the stated objective.

Instead of pushing this under the rag, a cursory look at multi-homing as
a general IP capability reveals the following. Multi-homing can be
achieved in the following ways, immediately pointing to corresponding
solutions regarding PMIP's compatibility with it:

1) Multiple connections over different technologies.
Given no changes to the end host, the only way to ensure that PMIP is
compatible with multi-technology capable hosts, is to make sure that a
PMIP domain NEVER spans network technologies. IF this is clearly
defined, and IF the protocol is used legally, then a multi-technology
mobile can never connect more than one of its interfaces to the same
PMIP domain.

2) Multiple connections over the same technology but to different
administrative domains.
The only way to ensure that PMIP is compatible with hosts multi-homing
to different administrative domains, is to make sure that a PMIP domain
NEVER spans administrative domains. 
IF this is clearly defined, and IF the protocol is used legally, then
hosts multi-homing to different admin domains can never connect to the
same PMIP domain.

3) Multiple connections with the same technology and to the same
administrative domain.
As far as I can tell, it is NOT possible to ensure that PMIP is
compatible with hosts multi-homing on the same technology and the same
administrative domain (albeit a rare case for common wireless links). 
For this reason, however, it should be clearly stated in an
applicability section that access technologies that allow multiple
connections from the same host and with the same identifier MUST NOT
deploy PMIP....at least in its current form. 

Regards
George

-----Original Message-----
From: Vijay Devarapalli [mailto:[email-masked]] 
Sent: Monday, October 01, 2007 1:17 AM
To: Basavaraj Patil
Cc: [email-masked]
Subject: [netlmm] Re: Proposed text for resolving the multi-homed host
issue

Hi Raj,

Further changes. I don't think a typical host implementation would 
assign the same address to two different interfaces. Here is the new
text.

Folks, please comment on the following text.

   A mobile node which has multiple interfaces may attach to different
   MAGs in a Proxy Mobile IPv6 domain simultaneously. If the mobile node
   is identified by a common MN-ID, the LMA will receive multiple proxy
   Binding Updates from the MAGs to which the mobile node is attached to
   via its multiple interfaces. The LMA cannot differentiate whether the
   Proxy Binding Update from a given MAG is a result of the mobile node
   performing a handoff or if the mobile node attaching via a second
   interface to another MAG in the Proxy Mobile IPv6 domain.

   Since the mobile node is attached to the same Proxy Mobile IPv6
domain
   with both interfaces, it may receive the same prefix on both
   interfaces. Typical host implementations do not allow assigning the
   same address to two different interfaces. If the mobile node performs
   IPv6 stateless address auto-configuration using different interface
   identifiers, then it would end up with different addresses from the
   same prefix on the two interfaces. Then it becomes a multi-homed host
   in the Proxy Mobile IPv6 domain.

   As far as this document is concerned, the LMA maintains only a single
   binding cache entry for the mobile node at any given time. This
   binding cache entry will have the IP address of the MAG that last
sent
   successful Proxy Binding Update as the care-of address. Since the
   mobile node is attached to multiple MAGs, each MAG will keep
   attempting to refresh the binding cache entry in the LMA. This will
   cause the binding cache entry for the mobile node in the LMA to keep
   oscillating between MAGs. This situation becomes recoverable if the
   mobile node turns of the one of the interfaces or if the LMA
instructs
   one of the MAGs to stop sending proxy BUs for the mobile node.

   In the context of this document, where no changes or enhancements to
   the mobile node are possible, a complete solution for multi-homed
   hosts is considered to be out-of-scope.

Vijay

Basavaraj Patil wrote:
> Hello,
> 
> Below is proposed text for resolving the current impasse on the
multi-homed
> host issue. 
> 
> At this time, we do not seem to be making much headway on closing this
> issue. We (authors) recognize the issue... But we believe that a
complete
> solution to the problem needs to be dealt with separately and hence it
is
> perfectly okay to state that it is out-of-scope of this specification.
The
> WG can decide to work on the issue as a separate effort.
> 
> The proposed text will hopefully be sufficient to close this issue and
move
> forward. Else we would like to request the chairs to get consensus
from the
> WG on the proposed text.
> 
> "
> 
> Sec x.y TBD
> 
>    A mobile node which has multiple interfaces may attach to different
>    MAGs in a Proxy Mobile IPv6 domain simultaneously. If the mobile
node
>    is identified by a common MN-ID, the LMA will receive multiple
proxy
>    Binding Updates from the MAGs to which the mobile node is attached
to
>    via its multiple interfaces. The LMA cannot differentiate whether
the
>    Proxy Binding Update from the second MAG is a result of:
>    a. the mobile node performing a handoff or
>    b. the mobile node attaching via a second interface to another
>       MAG in the Proxy Mobile IPv6 domain.
> 
>    A host which receives the same prefix from different access routers
>    (i.e MAGs) may end up with duplicate addresses being configured on
the
>    interfaces when IPv6 stateless address auto-configuration is used
and
>    not based on a unique ID such as an L2 identifier. The behavior of
the
>    mobile node in such a scenario is unpredictable as it depends on
the
>    implementation of how duplicate addresses on the interfaces of the
>    host are handled. Therefore this  behavior of a multi-homed host
>    attaching to a Proxy Mobile IP6 domain via multiple interfaces is
>    implementation dependent and out-of-scope for this document.
> 
>    As far as this document is concerned, the LMA maintains only a
single
>    binding cache entry for the mobile node at any given time. This
>    binding cache will have the IP address of the MAG that last sent
>    a successful Proxy Binding Update as the care-of address. Since the
>    mobile node is attached to multiple MAGs, each MAG will keep
>    attempting to refresh the binding cache entry in the LMA. This will
>    cause the binding cache entry for the mobile node in the LMA to
keep
>    oscillating between MAGs. This situation becomes recoverable if the
>    mobile node turns off one of the interfaces or if the LMA instructs
>    one of the MAGs to stop sending proxy BUs for the mobile node.
> 
>    In the context of this document, where no changes or enhancements
to
>    the mobile node are possible, a complete solution for multi-homed
>    hosts is considered to be out-of-scope.
> "
> 
> -Raj
> 

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

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

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