Subject: Re: [MOBILE-IP] Multiple IP addresses per NAI

From: Mohamed Khalil <[email-masked]>
Date: Tue, 4 Jan 2000 16:53:06 -0600

Hi Pete,

> -----Original Message-----
> From: Pete McCann [SMTP:[email-masked]]
> Sent: Tuesday, January 04, 2000 2:49 PM
> To:   [email-masked]
> Subject:      Re: [MOBILE-IP] Multiple IP addresses per NAI
>
> Hi, Kent,
>
> "Kent K. Leung" <[email-masked]> (KKL) writes:
>
> >> I think the correct and clean way to allow any user to have multiple
> devices
> >> is to have each device owned by a user to send a new extension during
> the
> >> registration phase called a  Device Extension. This extension may be
>
> KKL> I agree with this approach.
>
> But what about a mobile device with two different interfaces of two
> different technologies - wouldn't it be nice to be able to continue a
> session from, say, CDMA to Ethernet?  I don't think we need to pin
> down the device's link-layer address (maybe Mohamed's extension
> doesn't quite do that, but it at least gives the specific technology.
> This may preclude handoff from one technology to another).  A logical
> session identifier seems more appropriate.  This could just be a
> single (small) integer, and it should be independent of the
> link-layer technology in use.
>
        [MK>]  The device id is actually an id which is offered by the ISP
when the user obtained the service. It could be something like
mci-phone-214-78-9898
        or it could be an integer #. The User NAI and the device id will be
used by the mobile agent to uniquely identify the device. The device could
support multiple technologies but it is still have one device id. If the
user's device needs to re-register because it has changed technology, it
should use the same device id in the registration request. if the device has
already assigned an IP by the home subnetwork, it will not be reassigned
another IP because it has changed technology. I did not understand how this
proposal will preclude handoff from one technology to another technology.

> >> > Re-registrations will presumably have valid Home Address fields in
> the
> >> > registration request.  New registrations will have 0.0.0.0.
>
> KKL> I think part of the problem is that address allocation has not been
> KKL> sufficiently covered by any drafts.  The NAI draft does not explain
> KKL> the meaning when NAI extension exist and home address is non-zero.
> KKL> Does this always happen for re-registrations?   Re-registrations
> KKL> may have zero home address field.
>
> KKL> My interpretation is that the HA could use this ip address as a hint
> KKL> for address allocation even for new registrations (similar to dial
> KKL> environment).  But if address is used, then HA will return a new ip
> KKL> address.  But some maybe the MN really wanted that address for some
> KKL> reason.  In that case, MN should deregister that address after being
> KKL> accepted.  Anyways, it's ambiguous on how HA deal with registrations
> KKL> with NAI ext and non-zero Home Address.
>
> Perhaps whatever new extension is defined could clarify these issues.
> My feeling is that if the MN gives an address, it expects to have that
> address assigned to it.  We need to preserve compatibility with nodes
> that don't do dynamic address assignment.
>
> >> > Maybe so, but I don't think we should necessarily augment the NAI
> >> > extension itself - that would slow down too many other efforts.
> Maybe
> >> > a new Session ID extension should be created.
>
> KKL> I don't have problem with that.  Not all cases require further
> KKL> NAI subidentification.
>
> -Pete

---

From: Pete McCann <[email-masked]>
Date: Tue, 4 Jan 2000 17:21:50 -0600

Mohamed Khalil (MK) writes:

MK>  The device id is actually an id which is offered by the ISP when
MK> the user obtained the service. It could be something like
MK> mci-phone-214-78-9898 or it could be an integer #. The User NAI
MK> and the device id will be used by the mobile agent to uniquely
MK> identify the device. The device could support multiple
MK> technologies but it is still have one device id. If the user's
MK> device needs to re-register because it has changed technology, it
MK> should use the same device id in the registration request. if the
MK> device has already assigned an IP by the home subnetwork, it will
MK> not be reassigned another IP because it has changed technology. I
MK> did not understand how this proposal will preclude handoff from
MK> one technology to another technology.

Hi, Mohamed,

I must have misunderstood your intention, then.  Your extension had
these two fields:

    Sub-Type             1   ETHERNET_DEV.
                         2   TDMA_DEV.
                         3   CDMA_DEV.

    device parameters  this section defines the device parameters
                       which is requested by the mobile node. this
                       section MAY be modified by the home agent
                       or foreign agent to match the current operating
                       capability of the network and the services
                       which is allowed for the user. The structure
                       of this section depends on the type of the device.

   device id  It is the device identification.
              example MCI-LAPTOP-193.193.193.20

Since the Sub-Type gave the specific link-layer technology, I was
assuming that device parameters contained a link-layer address and
that this was used to distinguish sessions.  I can see now that you
didn't actually say that.

Still, this extension seems overly complicated to me.  For one thing,
the HA needs to know the semantics of each Sub-Type to properly find
the device id (since device parameters is variable length).  I just
don't think it's necessary to give any information about the
link-layer interface to solve the multiple-sessions-per-NAI problem.
All we need is one integer called a "session id".  If you want to send
link-layer interface information, that could be accomplished with a
separate extension (note that there may be more than one session id
per interface!  That's another reason not to couple these two things
together in one extension).

-Pete