Subject: [Mip4] NAI-based dynamic home address assignment draft

From: Kent Leung <[email-masked]>
Date: Thu, 25 Mar 2004 18:10:53 -0800

FYI.

To: IETF-Announce: ;
Subject: I-D ACTION:draft-paulkandasamy-mobileip-nai-based-home-addres-00.txt

A New Internet-Draft is available from the on-line Internet-Drafts directories.

	Title		: Mobile IPv4 NAI-based Home Address Assignment
	Author(s)	: N. PaulKandasamy, K. Leung
	Filename	: draft-paulkandasamy-mobileip-nai-based-home-addres-00.txt
	Pages		: 21
	Date		: 2004-3-25
	
With the introduction of NAIs for identifying Mobile Nodes, RFC
     2794 also enabled the Home Agents to be able to assign IP addresses
     to the Mobile Nodes during the initial registration. Though the
     concept of NAI-based home address assignment is referenced in both
     RFC 2794 and RFC 3344, a comprehensive procedure for achieving such
     a NAI-based home address assignment has not been outlined. More
     particularly, the Home Agent and Mobile Node behaviors including
     the error recovery mechanisms for various scenarios related to NAI-
     based home address assignment have not yet been specified. This
     document specifies a procedure that the Mobile IP entities should
     follow in order to facilitate NAI-based home address assignment
     under various circumstances.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-paulkandasamy-mobileip-nai-based-home-addres-00.txt

To remove yourself from the IETF Announcement list, send a message to
ietf-announce-request with the word unsubscribe in the body of the message.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-paulkandasamy-mobileip-nai-based-home-addres-00.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE 
/internet-drafts/draft-paulkandasamy-mobileip-nai-based-home-addres-00.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.
Content-Type: text/plain
Content-ID:	<[email-masked]>

ENCODING mime
FILE /internet-drafts/draft-paulkandasamy-mobileip-nai-based-home-addres-00.txt

<ftp://ftp.ietf.org/internet-drafts/draft-paulkandasamy-mobileip-nai-based-home-addres-00.txt>

-- 
Mip4 mailing list: [email-masked]
    Web interface: https://www.ietf.org/mailman/listinfo/mip4
     Charter page: http://www.ietf.org/html.charters/mip4-charter.html
Supplemental site: http://www.mip4.org/

---

From: "O'Neill Alan" <[email-masked]>
Date: Tue, 30 Mar 2004 03:23:14 -0500

Hi Naveen, Kent.

So I read the draft and think the HA processing is great given present
circumstances. One aspect of the model I didn't like was having both a Static
and Dynamic MN Capability. I would rather we had one Dynamic MN Capability,
that distances us from RFC2794 and RFC3344. This then leaves knowledge of the
addressing policy for each MN on the HA, eliminates some error cases, and
enables static and dynamic addresses to converge as a dynamic address with a
lease-time between;
 
       0(address release)...X(dynamic)...infinity(static).

The impact of this direction on your model is shown in the converged table
below, where D1-7 are your dynamic cases from section 6.1, and S1-3 are the
static cases from section 6.2. The table is a slight rearrangement of those
in the draft so that binding state and addressing state in the HA are clearly
separated. Note that I modified S2/D2 cases so that the HoA is described as
being assigned to a different NAI rather than a different MN, due to the
potentially multiplicity of mappings between MNs and NAIs). 

In this table, if there is a binding (NAI,HoA) then by definition the HoA is
assigned to that NAI for some lease-time (not shown) which for present
implementations is equal to either the binding lifetime (dynamic) or infinity
(static). I hope this table shows how the two models come together nicely.

     +----------+----------------+---------------------------+------+ 
     | MIP RREQ |HA Binding State|HA Address Management State| Case |
     +----------+----------------+---------------------------+------+ 
     |          |                |  RREQ(HoA) is Unassigned  |  D1  | 
     |          |                +---------------------------+------+ 
     |          |                |  RREQ(HoA) Not Allowed    |      | 
     |          |                |            OR             |  D2  | 
     |          |   No Binding   | RREQ(HoA) is assigned to  |  S2  | 
     |          |  for RRQ(NAI)  |      a different NAI      |      | 
     |          |                +---------------------------+------|
     |RREQ(NAI, |                |       RREQ(HoA) is        |  S1  |
     |     HoA) |                |    assigned to RREQ(NAI)  |      |
     |          +----------------+---------------------------+------+ 
     |          |RRQ(NAI,HoA) == |       RREQ(HoA) is        |  D3  | 
     |          |Binding(NAI,HoA)|    assigned to RREQ(NAI)  |  S1  | 
     |          +----------------+---------------------------+------+ 
     |          |  RRQ(NAI) ==   |   RRQ(HoA) is Unassigned  |  D4  | 
     |          | Binding(NAI)   |                           |  S2  |
     |          |     &&         +---------------------------+------+ 
     |          |  RRQ(HoA) !=   |   RREQ(HoA) Not Allowed   |      |
     |          | Binding(HoA)   |            OR             |  D5  |
     |          |                |  RRQ(HoA) is assigned to  |  S2  | 
     |          |                |      a different NAI      |      | 
     +----------+----------------+---------------------------+------+
     |          |                |          A HoA is         |  D6  | 
     |          |  No Binding    |    assigned to RREQ(NAI)  |  S3  | 
     |          | for RRQ(NAI)   +---------------------------+------|
     |          |                |          No HoA is        |  D6  |
     |RREQ(NAI, |                |    assigned to RREQ(NAI)  |  S3  | 
     | 0.0.0.0) +----------------+---------------------------+----- + 
     |          |  RRQ(NAI) ==   |                           |      |
     |          | Binding(NAI)   |      Binding(HoA) is      |  D7  |
     |          |     with       |    assigned to RREQ(NAI)  |  S3  |
     |          | Binding(HoA)   |                           |      |
     +----------+----------------+---------------------------+------+

In particular, note that S3 still crops up in all cases of RREQ(0.0.0.0) when
the MN is able to include the Static MN Capability as per the existing draft.

Now I would suggest we get the following benefits with a single Dynamic MN
Capability, as shown in the following table extract update, which also aligns
quite nicely with being 'liberal in what you receive'. It is assumed here
that we are replacing the static procedure (S1-S3) with the equivalent
dynamic procedure

     |          |                |          A HoA is         |  D6  | 
     |          |  No Binding    |    assigned to RREQ(NAI)  |      | 
     |          | for RRQ(NAI)   +---------------------------+------|
     |          |                |          No HoA is        |  D6  |
     |RREQ(NAI, |                |    assigned to RREQ(NAI)  |      | 
     | 0.0.0.0) +----------------+---------------------------+----- + 
     |          |  RRQ(NAI) ==   |                           |      |
     |          | Binding(NAI)   |      Binding(HoA) is      |  D7  |
     |          |     with       |    assigned to RREQ(NAI)  |      |
     |          | Binding(HoA)   |                           |      |
     +----------+----------------+---------------------------+------+ 

We can now get the MN connected by resorting to S1==D6 behaviour instead of
S3 behaviour, if a HoA is assigned (ie MN should have sent RREQ(HoA)).
Similarly, we can get the MN connected by resorting to D6/D7 instead of S3,
if no HoA is assigned (because with no Static MN Capability, the
RREQ(0.0.0.0) is always valid and we rely on the HA policy to merely control
the lease-time granted. Essentially, we have stripped out a number of error
cases in the merge because now the parameters in the RREQ() can now never
internally conflict, and are less likely to conflict with the HA address
management state/policy.

In the case of the lease-time = binding lifetime (ie no HALG extension), then
the MN knows it got a dynamic address. With a HALG included, the MN gets to
know that it has a lease-time greater than the MIP binding, potentially
including an infinite lifetime (static), and could also be told how to
release the static address (ie HALR) and how to maintain the address on
returning home (ie DHCP v HALR v etc). Having the distinction made in the
downlink rather than uplink signaling is preferable on wireless links due to
the asymmetry, and avoiding RREQ() refusals is also generally preferable to
avoid connectivity delays and wasted air-link resources.

I am still checking the impact on all your signaling cases to make sure I
haven't lost something important, so if you can see them more quickly then
please save me the effort. But I would appreciate your thoughts on the model
?

Alan.

========================================================
This email may contain confidential and privileged material for the sole
use of the intended recipient.  Any review or distribution by others is 
strictly prohibited.  If you are not the intended recipient please contact
the sender and delete all copies.
========================================================

---

From: "O'Neill Alan" <[email-masked]>
Date: Wed, 31 Mar 2004 02:49:30 -0500

Kent/Naveen,

I checked through the tables and processing thoroughly and think they are all
ok. I also noted the following points / benefits.

i) For case D2/S2, instead of needing to respond with S2 when the MN signals
static capability RREQ(HoA) for an HoA that is not allowed, the MN just sends
dynamic capability and the HA processing just defaults to D2. In addition, if
the MN has a static HoA which is different to the RREQ(HoA), then rather than
using the S2 response, it is clearly better if we instead return the static
HoA to the MN via D2 processing. If the MN does not have a static HoA, then a
dynamic address is assigned via D1 or D2 depending on the availability of the
RREQ(HoA). These seamless transitions between static and dynamic models is
made possible with the converged MN Capability.

ii) For case D7, the binding (HoA) is preferred given a RREQ(0.0.0.0), so we
should do similarly for case D5, where the existence of a binding(HoA) should
cause the HA to return the binding(HoA) to the MN.

iii) To reduce the chances of case D2 occurring, an address should not be
returned to the unassigned pool until after a short reboot safety timer has
expired, following binding deletion. A MN sending RREQ(NAI,HoA) is then much
more likely to avoid the HA having assigned RREQ(HoA) to another NAI during
the HA reboot. This model of course assumes that address state survives
reboot (persistent storage and/or outside HA) and only binding state is lost.

Regards, Alan.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of O'Neill
Alan
Sent: Tuesday, March 30, 2004 5:53 PM
To: [email-masked]
Subject: RE: [Mip4] NAI-based dynamic home address assignment draft

Hi Naveen, Kent.

     |          |                |          A HoA is         |  D6  | 

Alan.