Subject: [netlmm] RE: Solution proposal for accommodating multihomed IP nodes in PMIP6

From: "Narayanan, Vidya" <[email-masked]>
Date: Mon, 15 Oct 2007 14:17:07 -0700

Correcting one typo below.  

> -----Original Message-----
> From: Narayanan, Vidya 
> Sent: Monday, October 15, 2007 2:12 PM
> To: Netlmm
> Subject: Solution proposal for accommodating multihomed IP 
> nodes in PMIP6
> 
> 
> All,
> Jonne, Jari and myself had a call with some of the key people 
> involved in the two solution proposals to see if common 
> ground can be achieved.  After discussion, we have settled on 
> a solution that all the people on the call could agree upon.  
> The following write-up captures that discussion.  Please 
> review and comment on it.  
> 
> If there is consensus, we will move forward with documenting 
> this in the base spec.  Please note that this write-up only 
> captures the concept in reasonable detail for discussion 
> purposes and the authors will work on the exact wording and 
> details to be captured in the document once there is agreement. 
> 
> Thanks,
> Vidya 
> 
> -------------------------------------------------------
> 
> The goal is to limit the assignment of a given prefix to one 
> interface of an MN at a time.  In other words, when multiple 
> interfaces are simultaneously in use on an MN, different 
> prefixes should be assigned to each of those interfaces.  
> However, in a handoff situation, the same prefix may be 
> assigned to a different interface (with the understanding 
> that the other interface is either shut down or not using 
> this prefix).  
> 
> - The MAG carries the following pieces of information in the 
> PBU to the LMA - the MN ID, the access technology type, an 
> interface ID and a Handoff Indicator (HI) field. 
> 	- The MN ID may be the NAI or anything else that 
> identifies the MN uniquely in the PMIP domain (as currently 
> specified in the document).  This is a mandatory field. 
> 	- The access technology type indicates the access 
> technology using which the MN connects to the MAG (e.g., 
> Ethernet, WLAN, IPsec, PPP, LTE, etc.).  This is a mandatory field. 
> 	- The interface ID uniquely identifies the interface of 
> the MN and is typically an L2 identifier (e.g., MAC address, 
> Link ID, etc.).  When no interface ID is available for a 
> given access technology, this field is set to 0 (or omitted, 
> if defined as an option).  When an interface ID is available, 
> it MUST be present in the PBU.  
> 
> - The Handoff Indicator (HI) field** in the PBU indicates if 
> the PBU is meant for an interface that is a handoff from a 
> different interface corresponding to an existing BCE
> 	- When the new MAG is aware of the handover, it sets 
> this field to indicate a "handoff"; when the new MAG knows 
> that this PBU is unrelated to other interfaces of the MN, it 
> sets it to "no handoff" or "distinct interface"; when the new 
> MAG has no information, it sets it to "no information"
> 	- When this field is set to "no information" and the 
> situation is actually a handoff case, the old MAG should send 
> a deregistration PBU with this field set to "handoff" for the 
> LMA to accept the PBU from the new MAG with the same HNP 
> assignment; if not, a new HNP must be assigned for that PBU
> 
> - The LMA, upon receiving a PBU, does the following: 
> 
> Case 1: Interface ID is present in the PBU: 
> 
> 	- If the interface ID contained in the PBU matches the 
> interface ID stored for a given BCE (for a given MN ID), it 
> MUST update that BCE with the new PBU and keep the HNP 
> associated with that BCE
> 	- If the interface ID is different from an existing BCE 
> for a given MN ID and the HI field is set to "no handoff", it 
> MUST assign a new HNP for the interface and create a new BCE 
> for the HNP
> 	- If the interface ID is different from an existing BCE 
> for a given MN ID and the HI field is set to "no 
> information", the LMA SHOULD wait for a deregistration 
> message for an existing BCE before accepting the new PBU with 
> the same HNP; if no deregistration is received within a given 
> time, the LMA SHOULD assign a new prefix for the received 
> PBU.  The LMA MAY assign a new HNP and accept the PBU without 
> waiting for a deregistration message. 
> 	- If the interface ID is different from an existing BCE 
> for a given MN ID and the HI field is set to "handoff", the 
> LMA MUST assign the same HNP associated with the BCE 
> corresponding to the old interface and update the BCE
> 	
> Case 2: No interface ID is present in the PBU: 
> 
> 	- If there is no corresponding BCE for that MN ID with 
> a NULL interface ID value, the LMA MUST assign a new HNP 
> corresponding to the incoming PBU
> 	- If there is a BCE with NULL interface ID value for 
> that MN ID and the HI field is set to "handoff", the LMA MUST 
> assign the same HNP associated with the BCE corresponding to 
> the old interface and update the BCE
> 	- If there is a BCE with NULL interface ID value for 
> that MN ID and the HI field is set to "no handoff", the LMA 
> MUST assign a new HNP corresponding to the incoming PBU
> 	- If there is a BCE with NULL interface ID value for 
> that MN ID and the HI field is set to "no information", the 
> LMA SHOULD wait for a deregistration message for an existing 
> BCE before accepting the new PBU with the same HNP; if no 
> deregistration is received within a given time, the LMA 
> SHOULD assign a new prefix for the received PBU.  The LMA MAY 
> assign a new HNP and accept the PBU without waiting for a 
> deregistration message. 
> 	
> How the LMA is notified about a handoff situation for address 
> continuity is out of scope of the specification.  This may be 
> based on L2 triggers or other means that may be defined by 
> the appropriate SDO or deployment.  With such information, 

s/With/Without

> the LMA must treat it an interface as a "distinct" one, 
> unless there is an exact match of parameters with an existing BCE.  
> 
> One other point to note here is that a given PMIP session is 
> now tied to the tuple {MN-ID, Interface ID, Access technology 
> type} and not just to the MN-ID; there may be only one HNP 
> associated with any unique value of the tuple, but, multiple 
> HNPs (and hence, BCEs) corresponding to the same MN-ID itself. 
> 

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

---

From: "Tsirtsis, George" <[email-masked]>
Date: Tue, 16 Oct 2007 01:32:21 -0700

Vidya, Jonne, Jari et.al.,

I have a serious concern regarding the interaction of PMIPv6 with MIPv6.
Since this group now accepts that PMIPv6 can be used for
inter-technology handoff, the way this protocol interacts with MIPv6
must be very, very clear!

>From inter-technology handoff perspective, I fear that we have so far
focused too much on whether the same HNP should be allocated by the LMA
or not, while we have neglected to deal with the question of how the MAG
decides whether to use PMIP or not in the first place.

Note that in both 3GPP and 3GPP2 (and even more in the Internet at
large), PMIP for inter-technology handoff is defined as one of the
options, typically together with Mobile IP i.e., the routers, in each
technology specific network, acting as a MAG for PMIP, can also act as
normal routers for the purposes of MIPv6.

If I understood correctly from your description, if the MAG does not
know whether a new link is the result of a handoff (i.e., HI = "no
info"), and no matter what the type and IID of that link are, the MAG is
supposed to register to the LMA and the LMA has the option of assigning
the same prefix over to the new MAG (albeit after waiting for
deregistration from oldMAG).

I am sure the thinking here is that this should be ok with "unmodified
hosts". I think this assumption is not safe in the general case for
reasons that have been discussed before e.g., MN disconnecting from the
oldMAG does not immediately imply that the corresponding interface in
the MN is down etc. 

Putting that aside, however, this behavior is entirely unacceptable to
MNs that handle inter-technology mobility with MIPv6! What such a mobile
needs is that each AR it connects to (whether a PMIP MAG or not),
assigns it a new local IP address, so that the MN can handle mobility by
itself. Unless I am missing something, the proposed solution is not
compatible with an "unmodified MIPv6 host", since the solution is
designed to default to using PMIPv6.

Thoughts?

George

-----Original Message-----
From: Narayanan, Vidya [mailto:[email-masked]] 
Sent: Monday, October 15, 2007 10:17 PM
To: Netlmm
Subject: [netlmm] RE: Solution proposal for accommodating multihomed IP
nodesin PMIP6

s/With/Without

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Tue, 16 Oct 2007 09:46:50 -0500

> 
> Putting that aside, however, this behavior is entirely 
> unacceptable to MNs that handle inter-technology mobility 
> with MIPv6! What such a mobile needs is that each AR it 
> connects to (whether a PMIP MAG or not), assigns it a new 
> local IP address, so that the MN can handle mobility by 
> itself. Unless I am missing something, the proposed solution 
> is not compatible with an "unmodified MIPv6 host", since the 
> solution is designed to default to using PMIPv6.
> 
> Thoughts?

Hi George,

How is this different from how PMIPv6 handles the MN initial attach and
inter-MAG handoff within the same technology?

If we accepted how PMIPv6 solution handles the MIPv6 MN in the initial
attach and inter-MAG handoff, then I do not see any issue for the same
concept to work for inter-technology handoff. However, if we have a
problem accepting the original argument, then that is a different story.

> Subject: [netlmm] RE: Solution proposal for accommodating 
> multihomed IP nodesin PMIP6
> 
> > Subject: Solution proposal for accommodating multihomed IP nodes in 
> > PMIP6
> > 
> > 
> > All,
> > Jonne, Jari and myself had a call with some of the key 
> people involved 
> > in the two solution proposals to see if common ground can 
> be achieved.  
> > After discussion, we have settled on a solution that all 
> the people on 
> > the call could agree upon.
> > The following write-up captures that discussion.  Please review and 
> > comment on it.
> > 
> > If there is consensus, we will move forward with 
> documenting this in 
> > the base spec.  Please note that this write-up only captures the 
> > concept in reasonable detail for discussion purposes and 
> the authors 
> > will work on the exact wording and details to be captured in the 
> > document once there is agreement.
> > 
> > Thanks,
> > Vidya
> > 
> > The goal is to limit the assignment of a given prefix to 
> one interface 
> > of an MN at a time.  In other words, when multiple interfaces are 
> > simultaneously in use on an MN, different prefixes should 
> be assigned 
> > to each of those interfaces.
> assigned to a 
> > different interface (with the understanding that the other 
> interface 
> > is either shut down or not using this prefix).
> > 
> > - The MAG carries the following pieces of information in the PBU to 
> > the LMA - the MN ID, the access technology type, an 
> interface ID and a 
> identifies the MN 
> > uniquely in the PMIP domain (as currently specified in the 
> document).  
> > This is a mandatory field.
> technology using 
> > which the MN connects to the MAG (e.g., Ethernet, WLAN, IPsec, PPP, 
> > LTE, etc.).  This is a mandatory field.
> the MN and is 
> > typically an L2 identifier (e.g., MAC address, Link ID, 
> etc.).  When 
> > no interface ID is available for a given access technology, 
> this field 
> > is set to 0 (or omitted, if defined as an option).  When an 
> interface 
> > ID is available, it MUST be present in the PBU.
> > 
> > - The Handoff Indicator (HI) field** in the PBU indicates 
> if the PBU 
> > is meant for an interface that is a handoff from a 
> different interface 
> this field to 
> > indicate a "handoff"; when the new MAG knows that this PBU is 
> > unrelated to other interfaces of the MN, it sets it to "no 
> handoff" or 
> > "distinct interface"; when the new MAG has no information, 
> it sets it 
> > to "no information"
> situation is 
> > actually a handoff case, the old MAG should send a 
> deregistration PBU 
> > with this field set to "handoff" for the LMA to accept the PBU from 
> > the new MAG with the same HNP assignment; if not, a new HNP must be 
> > assigned for that PBU
> > 
> interface ID 
> > stored for a given BCE (for a given MN ID), it MUST update that BCE 
> > with the new PBU and keep the HNP associated with that BCE
> for a given 
> > MN ID and the HI field is set to "no handoff", it MUST assign a new 
> > HNP for the interface and create a new BCE for the HNP
> for a given 
> > MN ID and the HI field is set to "no information", the LMA 
> SHOULD wait 
> > for a deregistration message for an existing BCE before 
> accepting the 
> > new PBU with the same HNP; if no deregistration is received 
> within a 
> > given time, the LMA SHOULD assign a new prefix for the 
> received PBU.  
> > The LMA MAY assign a new HNP and accept the PBU without 
> waiting for a 
> > deregistration message.
> for a given 
> > MN ID and the HI field is set to "handoff", the LMA MUST assign the 
> > same HNP associated with the BCE corresponding to the old interface 
> > and update the BCE
> > 	
> > 	- If there is no corresponding BCE for that MN ID with a NULL 
> > interface ID value, the LMA MUST assign a new HNP 
> corresponding to the 
> > incoming PBU
> that MN ID and 
> > the HI field is set to "handoff", the LMA MUST assign the same HNP 
> > associated with the BCE corresponding to the old interface 
> and update 
> > the BCE
> that MN ID and 
> > the HI field is set to "no handoff", the LMA MUST assign a new HNP 
> that MN ID and 
> > the HI field is set to "no information", the LMA SHOULD wait for a 
> > deregistration message for an existing BCE before accepting the new 
> > PBU with the same HNP; if no deregistration is received 
> within a given 
> > time, the LMA SHOULD assign a new prefix for the received PBU.  The 
> > LMA MAY assign a new HNP and accept the PBU without waiting for a 
> > deregistration message.
> > 	
> > continuity is out of scope of the specification.  This may 
> be based on 
> > L2 triggers or other means that may be defined by the 
> appropriate SDO 
> > or deployment.  With such information,
> 
> s/With/Without
> 
> unless there 
> > is an exact match of parameters with an existing BCE.
> > 
> > One other point to note here is that a given PMIP session 
> is now tied 
> > to the tuple {MN-ID, Interface ID, Access technology type} and not 
> > just to the MN-ID; there may be only one HNP associated with any 
> > unique value of the tuple, but, multiple HNPs (and hence, BCEs) 
> > corresponding to the same MN-ID itself.
> > 
> 
>

---

From: "Tsirtsis, George" <[email-masked]>
Date: Tue, 16 Oct 2007 08:28:09 -0700

Hi Ahmad,

I believe the application of PMIPv6 as intra-technology and
inter-technology mobility management mechanisms presents different
challenges.

In the intra-technology case, it is common that a single mobility
management mechanism is defined on a per technology basis. The only
potential issue in this case is multi-homing using the same technology
interface in the same PMIP domain.

In the inter-technology case, the only available mobility management
mechanism that has been available for long time is Mobile IP. With the
introduction of PMIPv6, there is an issue of how mobiles and networks
figure out what is going to be used and when.

The issue I am raising with the latest solution is that it assumes that
PMIP is always used to interconnect a MAG to the LMA, and then some
logic defines whether the HNP is assigned to the MN again or not. This
is clearly not ideal if the MN supports Mobile IP, in which case the
address assigned should come from the MAG rather than the LMA.

To solve this problem, for example, the logic described by Vidya
earlier, when no specific knowledge exists at the MAG WRT to PMIP
support in the MN, should "default" to not running PMIP at all, but
instead the MAG should allocate a new local prefix to the MN.

Regards
George

-----Original Message-----
From: Ahmad Muhanna [mailto:[email-masked]] 
Sent: Tuesday, October 16, 2007 3:47 PM
To: Tsirtsis, George; Narayanan, Vidya; Netlmm
Subject: RE: [netlmm] RE: Solution proposal for accommodating multihomed
IP nodesin PMIP6

Hi George,

---

From: Vijay Devarapalli <[email-masked]>
Date: Tue, 16 Oct 2007 08:51:22 -0700

Hi George,

> designed to default to using PMIPv6.

Please take a look at scenario B in 
draft-giaretta-netlmm-mip-interactions-01.

    In this scenario there are two types of nodes in the access network:
    some nodes support Mobile IPv6 while some others do not.  The
    rationale behind such a scenario is that the nodes implementing
    Mobile IPv6 may prefer to manage their own mobility.  Obviously,
    nodes that do not implement MIPv6 must rely on the network to manage
    their mobility: therefore Proxy MIPv6 is used for those nodes.

and

    However, in case there are nodes that implement Mobile IPv6 and want
    to use this protocol, the network must offer MIPv6 service to them.
    In such case the MAG should not emulate the home link.  Therefore,
    instead advertising the HNP, the MAG should advertise the
    topologically correct IP prefix, i.e. the prefix belonging to the
    MAG, so that the MN detects an IP movement, configures a new CoA and
    sends a MIPv6 Binding Update based on [RFC3775].

What we are missing in draft-giaretta-netlmm-mip-interactions-01 is
some kind of indication to the MAG/AR that the mobile node wants to
use MIPv6 and not PMIPv6. In discussions offline we have considered
some indications at L2, modifying router solictations/advertisements,
etc... Good think there are already a few drafts on this.

What you want should not achieved by trying to limit PMIPv6
applicability. Thats the wrong thing to do. This is more dependent
on how you want to configure your access network. If the mobile node
wants to use MIPv6 (and indicates the same to the MAG/AR), you can
configure your MAG/AR to allocate a prefix from the MAG/AR's local
prefix pool.

Vijay

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Tue, 16 Oct 2007 11:34:31 -0500

Hi George,
Please see comments inline.

Regards,
Ahmad

> Subject: RE: [netlmm] RE: Solution proposal for accommodating 
> inter-technology mobility management mechanisms presents 
> different challenges.
> 
> In the intra-technology case, it is common that a single 
> mobility management mechanism is defined on a per technology 
> basis. The only potential issue in this case is multi-homing 
> using the same technology interface in the same PMIP domain.
> 
> In the inter-technology case, the only available mobility 
> management mechanism that has been available for long time is 
> Mobile IP. With the introduction of PMIPv6, there is an issue 
> of how mobiles and networks figure out what is going to be 
> used and when.
> 
> The issue I am raising with the latest solution is that it 
> assumes that PMIP is always used to interconnect a MAG to the 
> LMA, and then some logic defines whether the HNP is assigned 
> to the MN again or not. This is clearly not ideal if the MN 
> supports Mobile IP, in which case the address assigned should 
> come from the MAG rather than the LMA.
> 
> To solve this problem, for example, the logic described by 
> Vidya earlier, when no specific knowledge exists at the MAG 
> WRT to PMIP support in the MN, should "default" to not 
> running PMIP at all, but instead the MAG should allocate a 
> new local prefix to the MN.

[Ahmad]
I am not sure if this is a problem. My understanding is that PMIPv6
always assumes that the MAG is aware whether to offer PMIPv6 to the MN
or not based on User profile, policy, etc..

> Subject: RE: [netlmm] RE: Solution proposal for accommodating 
> unacceptable to 
> > MNs that handle inter-technology mobility with MIPv6! What such a 
> > mobile needs is that each AR it connects to (whether a PMIP MAG or 
> > not), assigns it a new local IP address, so that the MN can handle 
> > mobility by itself. Unless I am missing something, the proposed 
> > solution is not compatible with an "unmodified MIPv6 host", 
> since the 
> How is this different from how PMIPv6 handles the MN initial 
> attach and inter-MAG handoff within the same technology?
> 
> If we accepted how PMIPv6 solution handles the MIPv6 MN in 
> the initial attach and inter-MAG handoff, then I do not see 
> any issue for the same concept to work for inter-technology 
> handoff. However, if we have a problem accepting the original 
> argument, then that is a different story.
> 
> > 
> > George
> > 
> > 
> review and 
> PBU.  The

---

From: Basavaraj Patil <[email-masked]>
Date: Tue, 16 Oct 2007 12:57:29 -0500

Hi George,

Just as an FYI, I do believe that it makes sense to let the MN know if the
AR that it is attaching to is a MAG (PMIP6 capable) via the RA. By doing so
a MIP6 capable MN can choose to request a prefix which is local to the AR
and use that as the CoA in a BU.
Please refer to I-D: draft-damic-netlmm-pmip6-ind-discover-01.txt

The issue that you are raising is orthogonal to the original problem of
dealing with multihomed hosts. There is no assumption that PMIP6 is always
used or available in every MAG/AR to support mobility. The default fallback
to support mobility for a host is Mobile IP. Network based mobility would
only be applicable in networks that have MAG functionality in the AR and are
associated with an LMA which may also be the HA for the MN.

-Raj

---

From: "Tsirtsis, George" <[email-masked]>
Date: Wed, 17 Oct 2007 01:19:52 -0700

inline

-----Original Message-----
From: Basavaraj Patil [mailto:[email-masked]] 
Sent: Tuesday, October 16, 2007 6:57 PM
To: Tsirtsis, George; Ahmad Muhanna; Narayanan, Vidya; Netlmm
Subject: Re: [netlmm] RE: Solution proposal for accommodating multihomed
IP nodesin PMIP6

Hi George,

Just as an FYI, I do believe that it makes sense to let the MN know if
the
AR that it is attaching to is a MAG (PMIP6 capable) via the RA. By doing
so
a MIP6 capable MN can choose to request a prefix which is local to the
AR
and use that as the CoA in a BU.
Please refer to I-D: draft-damic-netlmm-pmip6-ind-discover-01.txt

GT> Good, I agree that MAG capabilities need to be advertised to end
nodes, but why would the MIP6 capable MN need to request the obvious?
MIPv6 has no need for the MAG functionally and the default behavior of
an AR is to provide a local prefix. If MAG is viewed as a "service" then
MAG services must be requested by entities that need it. Expecting
entities that do not need MAG services to indicate that fact is
backwards logic, and backwards incompatible. 

The issue that you are raising is orthogonal to the original problem of
dealing with multihomed hosts. There is no assumption that PMIP6 is
always
used or available in every MAG/AR to support mobility. The default
fallback
to support mobility for a host is Mobile IP. Network based mobility
would
only be applicable in networks that have MAG functionality in the AR and
are
associated with an LMA which may also be the HA for the MN.

GT> Yes, I understand that the base specification defines what happens
when PMIPv6 IS used, without saying WHEN it is used. I think this is
dangerous since it makes protocol misuse very easy, but I understand
that this is how the work has been split. 

-Raj

> Subject: RE: [netlmm] RE: Solution proposal for accommodating
multihomed

---

From: "Soininen Jonne (NSN - FI/Espoo)" <[email-masked]>
Date: Wed, 17 Oct 2007 15:03:28 +0300

Geoge et al.,

I understand the worry of using PMIP in a situation, which may cause 
suboptimal performance for the  MN, would be an issue. However, I don't 
see that it would currently break anything. Or at least I couldn't find 
anything in your mail that would suggest that something wouldn't work.

I think we can solve further optimization issues in future work. I would 
hope that the proposal on multihoming, which has gotten at least some 
support on the list, could be incorporated to the base draft, and we 
could move forward towards a WG LC.

Cheers,

Jonne.
ext Tsirtsis, George wrote:
>> The issue I am raising with the latest solution is that it assumes
>>     
> that
>   
>> How is this different from how PMIPv6 handles the MN initial attach
>>     
> and
>   
>> problem accepting the original argument, then that is a different
>>     
> story.
>   
>>> George
>>>
>>>
>>> interface ID and a
>>>> Handoff Indicator (HI) field.
>>> different interface
>>>> corresponding to an existing BCE
>>> waiting for a 
>>> corresponding to the
>>>> incoming PBU