Subject: RE: [mobile-ip] Multiple flows with single NAI

From: "Haseeb Akhtar" <[email-masked]>
Date: Thu, 10 May 2001 17:31:10 -0500

Madhavi,

> We were thinking along the lines of a Binding ID...an ID to identify
> the particular binding/flow using a single NAI.  The FA and HA 
> will then use the (NAI, Binding ID) as the identifier to distinguish
> the different bindings/flows.
> 
> We've been debating on what form the Binding ID should take...
> - globally unique - can be used directly as the ClientID to a DHCP/DNS
> server...(but, how do you ensure uniqueness).
> - index - tied to NAI for interpretation (requires some sort of
> Binding ID management on the MN to know which indices have been used,
> etc.)
> - index-marker - again, tied to NAI for interpretation, but each
> device uses a particular index-marker, and the HA does a mapping of
> this index-marker and authorizes the Binding ID.

Why does FA has to do anything different? The HA will have the tuple
of (USER NAI, DEVICE NAI, IP Address, COA) to tunnel the data to the COA
of the devices tied to that particular NAI.

The FA will just de-tunnel and forward the packet to the device.

> -Madhavi

Haseeb

---

From: Madhavi Subbarao <[email-masked]>
Date: Fri, 11 May 2001 12:13:33 -0400

Hi Haseeb,

> of the devices tied to that particular NAI.

The FA should maintain pending registrations by 
(USER NAI, Binding ID)...because it cannot rely just on NAI for
identification anymore.

> The FA will just de-tunnel and forward the packet to the device.

Yes, this stays the same.  Basically, the change is in identifying a
MIP flow.

-Madhavi

---

From: Pat Calhoun <[email-masked]>
Date: Fri, 11 May 2001 09:10:12 -0700

> (USER NAI, Binding ID)...because it cannot rely just on NAI for

I've been disconnected from this thread since it began, but have one
question that may have already been asked.

Why can't a device have a single NAI per binding? This seems like a
simple approach, and doesn't require any protocol changes.

PatC

---

From: Madhavi Subbarao <[email-masked]>
Date: Fri, 11 May 2001 16:14:45 -0400

Pat,

> simple approach, and doesn't require any protocol changes.

Yes, theoretically you can assign different NAI's per device/binding.
But, realistically, many service providers don't want to issue
multiple NAIs and maintain all of the management that comes along with
it.  In fact, this deployment issue was brought to light by Sprint. 

-Madhavi

---

From: Kent Leung <[email-masked]>
Date: Fri, 11 May 2001 13:24:47 -0700

Hi Pat.

I can understand why the question.  We asked the same question
when the issue first appeared about a year and a half ago.

It would be nice and simple to support a single NAI per binding.
But wireless service providers such as Sprint asked for support
of multiple bindings per NAI.  That's why we originally came out
with the dynamic mechanism to support this.  But some service
providers couldn't even wait for that, and wanted a static mechanism
as well.  So seems like the demand from service providers is
there.  They wanted separation of function, NAI for authentication
and Binding ID for address mapping.

Kent

---

From: Gopal Dommety <[email-masked]>
Date: Fri, 11 May 2001 14:20:02 -0700

Pat,

What the operators want is to be able to have a single NAI and allow 
multiple devices to
be on the network at the same time based on that NAI. Basically the same 
security Key, and
possibly accounting will be used for all of the devices. In order to 
distinguish one  device from
another during registration/address allocation, we need the Binding ID.

One way of solving the problem is , as you suggested, by using different 
NAIs. The reason that the operators
do not want to do that is that of  operations, management, and billing. 
Since all these devices are with the
same account, they want to have one NAI, one Key, and billing etc.

This operator request is similar to that of in the dial-up world of having 
multiple sessions. In that space people
use the NAS Port to be able to distinguish (I am sure you are aware of the 
ugliness of this solution).

Thanks
Gopal