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

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

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, 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: "Ved Kafle" <[email-masked]>
Date: Tue, 16 Oct 2007 10:41:39 +0900

The solution looks promising.
Please find a comment inline. 

> -----Original Message-----
> From: Narayanan, Vidya [mailto:[email-masked]] 
> Sent: Tuesday, October 16, 2007 6:12 AM
> To: Netlmm
> Subject: [netlmm] Solution proposal for accommodating 
> multihomed IP nodes inPMIP6
> 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 
> - 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
> 
> 	- 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. 

This point (and similar point below) may need further clarification.
Like, (1) how long/when the LMA SHOULD wait for a deregistration, (2)
when the LMA MAY assign a new HNP without waiting for a dereg.

- Ved Kafle

> 	- 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
> 	
> 	- If there is no corresponding BCE for that MN ID with 
> a NULL interface ID value, the LMA MUST assign a new HNP 
> 	- 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, 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. 
> 
>

---

From: "Alper Yegin" <[email-masked]>
Date: Tue, 16 Oct 2007 11:49:34 +0300

Do we still have to deal with a "logic" like this if we perform HNP
assignment only via AAA? 

Alper

> Sent: Tuesday, October 16, 2007 12:12 AM
> To: Netlmm
> Subject: [netlmm] Solution proposal for accommodating multihomed IP nodes
> inPMIP6
> 
> 
> All,