RE: [802.21] Discussion thread for MIHF ID
Michael,
Comments in-line preceded by [KAN]...
Best regards,
--kan--
--
Kevin A. Noll, CCIE
Sr. Wireless Engineer
Time Warner Cable
13241 Woodland Park
Herndon, VA 20171
o: +1-703-345-3666
m: +1-717-579-4738
AIM: knollpoi
-----Original Message-----
From: Michael G Williams [mailto:Michael.G.Williams@NOKIA.COM]
Sent: Thursday, March 06, 2008 1:07 PM
To: STDS-802-21@LISTSERV.IEEE.ORG
Subject: Re: [802.21] Discussion thread for MIHF ID
Hi Kevin,
Thanks for the thoughful reply.
[KAN] Thank you for being patient with my partial ignorance :-)
There is a pending comment against the curent wording of the text... So
we cannot leave it simply as it is, an example with FQDN and NAI without
realm. We have to make a finite list of the possible MIHF IDs (by
specifically calling out the list of options.)
[KAN] I suppose I can understand the need/desire to call out all of the
possible options, but do we think it's practical to do so? Surely, as
soon as we think we have a complete list, someone will come along and
suggest something new.
One proposition is that we are OK if we limit the scope of the MIHF ID's
uniqueness to an administrative domain. If we don't intend to support
handover between administrative domains, that seems reasonable. The
example of an NAI without realm was used as a non unique ID space which
would however be unique within an administrative domain. IP address was
also another example.
[KAN] I think you bring up a critical question that I haven't seen
discussed (perhaps it has been, but I've missed it)... do we intend to
support handovers between domains? Our answer to this question has a
direct impact on the question of what can be used as an MIH ID.
[KAN] I think we also need to be careful in our use of language here...
in this context, I believe we are discussing handover in the MIH domain
which is different than handovers in the media-domain.
Regarding the use of MAC address as an MIHF ID, that is possible,
however there was a thought that for devices with add-on or
interchangeable IEEE interfaces, the MAC address on one of the
interfaces might change or disappear. This goes against the requirements
and the current spec.
Regarding use of IP address, that can also change, even within an
administrative domain, while a MN is already in a registered MIH
session. An example is when the MN moves from one link type to another.
In general using addresses as ID's is a bad idea for many reasons.
[KAN] I completely agree with your statements on using MAC and IP
addresses.
Regarding the concern of global uniqueness being overy difficult or
constraining, that was discussed at the ad hoc. Difficulties with
assigning and maintaining FQDN's for mobile nodes were discussed. Since
we are considering adopting existing globally unique ID's for the MIHF
ID, there is no difficulty to find many infinite ID spaces that already
have that property.
The concern with non-unique ID spaces, is that there will be collisions
in the inter-domain case, and potentially within a domain (see IP
address example above). To resolve these will require one of two
approaches. One is to change something in the protocol to handle the
collisions when they occur. The other is a change to existing business
practice, so there is an administrative agreement on avoiding the
collisions. Today, there is no such negotiation between domains to avoid
duplication of the user's ID or device ID's.
[KAN] So are you assuming here that handoff between MIH domains is
supported?
[KAN] Regarding the business practice, I would argue (perhaps it's just
semantics) that there is administrative agreement on avoiding collisions
- use IMEI, or use MAC address, etc...
[KAN] Our problem is that we are dealing with multiple technologies, so
no one of these existing agreements is adequate.
So one proposal is to limit the list of ID spaces to be NAI with realm,
FQDN, and IMEI. These are unique and will support current roaming
models, and will not require additional changes to the protocol.
[KAN] You can never be guaranteed that a platform is going to have a
technology-specific address. For example, an IMEI doesn't exist on a
laptop unless it happens to have a cellular data card in it, which might
be removed by the user at anytime causing the IMEI to become
inaccessible.
[KAN] I can see problems in the FQDN space... but you've already
discussed that.
[KAN] In my opinion, the only thing that can be globally unique and
useable on virtually any platform is NAI with realm, with the NAI
derived from the device characteristics or assigned by the "home"
administrative domain.
I also proposed a compromise which was to allow for fixed nodes to have
non-unique MIHF ID, while mobile nodes would require globally unique
MIHF ID's, to support handover between domains, and to ease the problem
of discovery of the fixed node MIHFs.
If not, we also proposed including something in the protocol to resolve
collisions, if we accept NAI without realm or IP address as components
of the MIHF ID.
[KAN] I think you're potentially adding a lot of extra work to allow
non-unique IDs and require the protocol to *resolve* collisions. [KAN]
You should definitely specify what the protocol entities do in the event
they *detect* a collision.
[KAN] Of course, I get to this point and realize that I haven't looked
at *how* an MIHF ID is assigned to a device. If it's done "manually" at
the time of initial configuration of the device, then most of my
questions/comments are valid. If it's done dynamically as the device is
booted or moves around in the network, then I think a lot of my comments
are not well founded. :-(
[KAN] I *REALLY* need to read the latest draft again! :-(
What do you think?
Best Regards,
Michael
This E-mail and any of its attachments may contain Time Warner
Cable proprietary information, which is privileged, confidential,
or subject to copyright belonging to Time Warner Cable. This E-mail
is intended solely for the use of the individual or entity to which
it is addressed. If you are not the intended recipient of this
E-mail, you are hereby notified that any dissemination,
distribution, copying, or action taken in relation to the contents
of and attachments to this E-mail is strictly prohibited and may be
unlawful. If you have received this E-mail in error, please notify
the sender immediately and permanently delete the original and any
copy of this E-mail and any printout.