Re: regarding the re-chartering..

"Sri Gundavelli (sgundave)" <[email protected]>
Newsgroups gmane.ietf.nemo
Message-ID <D035B45D.162A1A%[email protected]>
Yes. Currently, the MNID is if the nai format and is overloaded. The MNID
in 3GPP specs is the IMSI-NAI (IMSI@REALM), its based on the IMSI. Ex:
"<IMSI>@epc.mnc<MNC>.mcc<MCC>.3gppnetwork.org²

We also have MAC48@REALM;

We also have approaches to transform MAC to Pseudo IMSI, and then carry
IMSI-NAI as the MN-ID.


So, we need unique sub-types for each of the types/sources.

MN-Id based on IMSI, MSISDN, IMEI, MAC ..

Also, do we need to distinguish between IMSI and IMSI-NAI ?

Sri



On 9/10/14 6:29 AM, "Marco Liebsch" <[email protected]> wrote:

>It seems the MNID is somehow overloaded to carry both, node-specific IDs,
>e.g. MAC, as well as subscriber IDs, which is the IMSI.
>There may be value in adding the IMEI to the list of possible types of
>node-specific IDs.
>
>marco
>
>>-----Original Message-----
>>From: dmm [mailto:[email protected]] On Behalf Of Sri Gundavelli
>>(sgundave)
>>Sent: Dienstag, 9. September 2014 23:30
>>To: Sri Gundavelli (sgundave); Charlie Perkins; [email protected]
>>Cc: Vijay Devarapalli
>>Subject: Re: [DMM] regarding the re-chartering..
>>
>>Two more comments.
>>
>>
>>
>>4.) I'd also use sub-type value of (2) for IMSI. Just to align with the
>>sub-types
>>defined for MN Id defined for ICMP. I suspect there are some
>>implementations
>>already using sub-type (2). Please see the other thread.
>>
>>
>>5.) For each of the sub-types, we need text including examples and some
>>explanation on how they are used.
>>
>>
>>Sri
>>
>>
>>
>>On 9/9/14 2:20 PM, "Sri Gundavelli (sgundave)" <[email protected]>
>>wrote:
>>
>>>Hi Charlie,
>>>
>>>This is good. Thanks.
>>>
>>>
>>>1.) If EUI-48 and EUI-64 addresses are derived of a 48-bit IEEE 802.2
>>>address, why do we need to two sub-types ? Why not have just one
>>>sub-type for mac based identifiers ?
>>>
>>>2.) Sub type value (1) is currently used. Its currently overloaded for
>>>IMSI-NAI (3GPP specs) and generic NAI based identifiers. Given the
>>>definition of new sub-types, we need some text explaining the
>>>motivation
>>>
>>>3.) Proposed Sub-type value of (2) for IPv6 address. What exactly is
>>>this ? Are these CGA-based IPv6 addresses ?
>>>
>>>
>>>
>>>
>>>                     New Mobile Node Identifier Types
>>>
>>>               +-----------------+------------------------+
>>>               | Identifier Type | Identifier Type Number |
>>>               +-----------------+------------------------+
>>>               | IPv6 Address    | 2                      |
>>>               |                 |                        |
>>>               | IMSI            | 3                      |
>>>               |                 |                        |
>>>               | P-TMSI          | 4                      |
>>>               |                 |                        |
>>>               | EUI-48 address  | 5                      |
>>>               |                 |                        |
>>>               | EUI-64 address  | 6                      |
>>>               |                 |                        |
>>>               | GUTI            | 7                      |
>>>               +-----------------+------------------------+
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>Regards
>>>Sri
>>>PS: Good to see Vijay back
>>>
>>>
>>>On 9/9/14 1:28 PM, "Charlie Perkins" <[email protected]>
>>>wrote:
>>>
>>>>
>>>>Hello folks,
>>>>
>>>>Here's the last Internet Draft that we did, long ago expired:
>>>>http://www.ietf.org/archive/id/draft-perkins-mext-4283mnids-01.txt
>>>>
>>>>I'll resubmit it with a few updates as a personal draft to dmm.
>>>>
>>>>Regards,
>>>>Charlie P.
>>>
>>>_______________________________________________
>>>dmm mailing list
>>>[email protected]
>>>https://www.ietf.org/mailman/listinfo/dmm
>>
>>_______________________________________________
>>dmm mailing list
>>[email protected]
>>https://www.ietf.org/mailman/listinfo/dmm
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.