RE: [802.21] Discussion thread for MIHF ID
Hi Kevin,
Thanks for the thoughful reply.
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.)
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.
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.
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.
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.
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.
What do you think?
Best Regards,
Michael
>-----Original Message-----
>From: ext Noll, Kevin [mailto:kevin.noll@TWCABLE.COM]
>Sent: 06 March, 2008 06:53
>To: STDS-802-21@LISTSERV.IEEE.ORG
>Subject: Re: [802.21] Discussion thread for MIHF ID
>
>Uniqueness needs to have a scope. One can speak of uniqueness
>in terms of administrative domains, global, etc. For example,
>MAC addresses are (supposed to be) globally unique (I know
>there are exceptions to this), but RFC1918 IP addresses are
>*not* globally unique, but are typically unique to an
>administrative domain, or at least to a specific network.
>
>So, what is the scope of the "uniqueness" referred to in and
>required by 8.3.1? Is this defined anywhwere (apologies for
>not reading the latest draft, yet, to find out myself)?
>
>I would argue from a SP's perspective that a globally unique
>ID would be the best approach and that it should be something
>that is already available on the mobile device (e.g., the IMEI
>for a mobile phone, or MAC address for an 802-type device).
>Unfortunately, there is no absolutely common unique identifer
>across all possible platforms that might implement MIH functions.
>
>In fact, in this approach, it's possible that a single device
>may have multiple candidate unique ID's (for example, a laptop
>with a wired 802 interface and a wireless 802 interface).
>
>I think the standard paints itself into a corner if it
>*requires* a globally unique ID. Perhaps the language should
>be clarified that the ID must be unique within an MIH
>administrative domain, and that if administratively different
>networks are connected (which will be a common case), then
>appropriate measures must be taken to guarantee uniqueness
>between the domains.
>
>Beyond this, I think we can make suggestions (as already have
>been), but ultimately it will be up to the industry and
>implementors to figure out the best practice.
>
>--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: Subir Das [mailto:subir@RESEARCH.TELCORDIA.COM]
>Sent: Thursday, March 06, 2008 8:41 AM
>To: STDS-802-21@LISTSERV.IEEE.ORG
>Subject: Re: [802.21] Discussion thread for MIHF ID
>
>Michael,
>Thanks for bringing up the issue on the list. As I mentioned
>during the ad hoc meeting, FQDN and NAI should be sufficient
>for our purpose. NAI can be represented either as 'username'
>or 'username@realm'. In IETF, we also made similar
>assumptions. Also IMO, the current text is good since we
>provide the example of FQDN and NAI.
>
>regards,
>-Subir
>
>
>
>Michael G Williams wrote:
>>
>> Colleagues,
>>
>> In the Santa Clara ad hoc and in previous meetings, we've discussed
>> the definition of the MIHF ID. A commenter in the last SB
>requested a
>> more definite specification for this field. Here is a summary of the
>> issue, to help avoid spending a long time in the upcoming meeting
>> revisiting the details.
>>
>> The discussion has centered around two approaches to
>choosing the MIHF
>
>> ID 'space', let's label them as the unique and non-unique approaches.
>>
>> In the unique approach, the ID space is a finite collection of well
>> known existing spaces that contain only unique elements such
>as FQDN,
>> NAI@realm, IMEI, perhaps even something from 802.1.
>>
>> In the non-unique approach, we have added additional spaces to the
>> above, that might have collisions, such as IP address and NAI.
>>
>> Currently the MIHF ID is mandatory in the PICS and must be
>non null in
>
>> the MIB.
>>
>> 8.3.1 says the MIHF ID is required to uniquely identify the MIHF
>entity.
>>
>> One proposal to resolve the two approaches was to define the MIHF ID
>> to be the FQDN, the NAI with or without realm, the IMEI, or the IP
>> address. This proposal is essentially the non-unique approach as
>> namespaces with collision are included.
>>
>> If we permit collision name spaces as in the non unique
>approach, then
>
>> we should define a way of resolving collisions in the spec.
>>
>> If we disallow collisions as in the unique approach, we can
>leave it
>> to the implementation how to deal with collisions, as it is against
>> the spec for a MN or NN to use such an MIHF ID.
>>
>> Please send comments to the list here, and we can resolve
>the comment
>> by building consensus before the meeting.
>>
>> 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.
>