Re: [DMM] MNID Types

["Templin, Fred L" <[e-mail]>]

Hi Charlie,

I guess I have to say “I don’t know” to both questions. MNIDs are a fairly new subject
for me, and I think others would be better qualified to answer. Just thought I would
offer what I do know in case it might be of some help.

Thanks - Fred

From: Charles E. Perkins [mailto:[e-mail]]
Sent: Thursday, September 25, 2014 2:08 PM
To: Templin, Fred L; Sri Gundavelli (sgundave)
Cc: Vijay Devarapalli; [e-mail]
Subject: Re: [DMM] MNID Types


Hello Fred,

I can include DUID-UUID as an identifier type, and cite RFC 4122.  Is this
sufficient, or do I need to also do something related to DHCPv6 DUID?

I did not see any specific connection between this type of identifier and
the RFID discussion.  Is there something that relates the two types?

Regards,
Charlie P.


On 9/25/2014 2:00 PM, Templin, Fred L wrote:
Hi Charlie,

I am interested in node IDs that can be represented in a DHCPv6 DUID. There is
RFC6355 which encodes a node ID based on DUID-UUID (Universally Unique
IDentifier). AFAICT, the UUID is a 128-bit container formatted per RFC4122
specifications that includes a time portion and a node ID portion. Any chance
this would satisfy what you are looking for?

Thanks - Fred

From: dmm [mailto:[e-mail]] On Behalf Of Charles E. Perkins
Sent: Thursday, September 25, 2014 1:43 PM
To: Sri Gundavelli (sgundave)
Cc: Vijay Devarapalli; [e-mail]<mailto:[e-mail]>
Subject: Re: [DMM] MNID Types


Hello Sri,

Is the DoD-96 identifier for a special kind of RFID, or is it
valid for all the RFID devices that would be of interest?

Regards,
Charlie P.


On 9/21/2014 9:59 AM, Sri Gundavelli (sgundave) wrote:
Hi Hakima,

That is a good idea. We should register a type for the Dod-96 identifier as well.


Regards
Sri


From: Hakima Chaouchi <[e-mail]<mailto:[e-mail]>>
Date: Sunday, September 21, 2014 8:11 AM
To: Sri Gundavelli <[e-mail]<mailto:[e-mail]>>
Cc: Charlie Perkins <[e-mail]<mailto:[e-mail]>>, Marco Liebsch <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>, Vijay Devarapalli <[e-mail]<mailto:[e-mail]>>
Subject: Re: [DMM] MNID Types

Hello Folks,

Do you think that considering specific but needed technologies for moving objects in  Internet of Things  such as RFID (Radio Frequency Identifier) with 96 bits identifiers will be also relevent to Charlie's current draft and the efforts related to MNID?

Regards,

Hakima


________________________________
De: "Sri Gundavelli (sgundave)" <[e-mail]<mailto:[e-mail]>>
À: "Charlie Perkins" <[e-mail]<mailto:[e-mail]>>, "Marco Liebsch" <[e-mail]<mailto:[e-mail]>>, [e-mail]<mailto:[e-mail]>, "Vijay Devarapalli" <[e-mail]<mailto:[e-mail]>>
Envoyé: Jeudi 11 Septembre 2014 23:57:11
Objet: Re: [DMM] MNID Types

Hi Charlie,

Few more reviews/discussions and capturing the consensus in the base version will help. But, I'm ok either way …


Regards
Sri

From: Charlie Perkins <[e-mail]<mailto:[e-mail]>>
Date: Thursday, September 11, 2014 2:46 PM
To: Sri Gundavelli <[e-mail]<mailto:[e-mail]>>, Marco Liebsch <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>, Vijay Devarapalli <[e-mail]<mailto:[e-mail]>>
Subject: Re: [DMM] MNID Types


Hello folks,

I propose to submit the ....-00.txt document as it is to the Internet
Drafts directory, and then to go about making updates according to
the discussion on this list.  Do you think this is reasonable?

Regards,
Charlie P.



On 9/11/2014 7:21 AM, Sri Gundavelli (sgundave) wrote:

<Changing the subject line to reflect the MNId discussion>





Marco,





Thinking further on the complementary identifier option.



- There is already the link-layer identifier option that can be used for

carrying the Mac address

- IMEI and MSISDN are already defined in 29.275 as a 3GPP VSE's



In some sense, the complementary identifiers are already present.



Sri











On 9/11/14 6:58 AM, "Sri Gundavelli (sgundave)" <[e-mail]><mailto:[e-mail]> wrote:

I do not see a reason why multiple MN-Id instances need to be present in a

single message ? In my experience, this is strictly a deployment

consideration, when to use what type of identifiers.



Assuming the backend system can tie all the MN-Id's to a single

subscription, any presented identifier can be sufficient for the gateway

to do the BCE lookup.



If multiple instances can be present, then we need to deal with more error

cases. Is that really needed ?





I am wondering if it would not be more appropriate to go for a different

container option to carry such information. Something like a

complementary identifier option.

Sounds interesting. Are you suggesting we leave the current MN-ID as it

is, but use a new complementary option ? But, if the requirement is for a

Mac based identifiers, what will be there in the current MN-Id option ? We

still need to have identifier there ?









Sri











On 9/11/14 2:03 AM, "Marco Liebsch" <[e-mail]><mailto:[e-mail]> wrote:



No issue with logical vs. physical ID. But I am wondering about two

things:



Operation is clear to me in case a single MNID is present in a message

and I see the value in being

flexible to choose from different sub-types. If multiple MNIDs with

different sub-types are present in

a single message, which one should e.g. the LMA take for the BC lookup..

No big problem to solve, but

to be considered in implementations.



If the reason for multiple present MNIDs with different sub-types is to

do other things than identifying

the node or using the ID as key for a lookup, I am wondering if it would

not be more appropriate

to go for a different container option to carry such information.

Something like a complementary

identifier option.



marco



-----Original Message-----

From: Sri Gundavelli (sgundave) [mailto:[e-mail]]

Sent: Donnerstag, 11. September 2014 00:42

To: Charlie Perkins; Marco Liebsch; [e-mail]<mailto:[e-mail]>

Cc: Vijay Devarapalli

Subject: Re: [DMM] regarding the re-chartering..



Hello Charlie,



Agree with that. MN-Id as its defined today is a logical identifier. It

does not

require the identifier to be bound to a physical device or a interface

identity.

But, we have clearly seen requirements where the need is for generating

identifiers based on some physical identifiers. Those physical

identifiers include

IMSI, MSISDN, IMEI, MAC ..etc. If we can define a type for each of the

source

and the rules for generating MN-ID based using those sources, the sender

and

receiver will have clear guidance on how to use the spec. Some pointers,

explanation and examples for each of those identifiers will greatly help

avoid

inter-op issues.





Regards

Sri















On 9/10/14 3:21 PM, "Charlie Perkins" <[e-mail]><mailto:[e-mail]>

wrote:



Hello folks,



I think it's best to consider the MNID as simply living in a space of

identifiers, and not worry too much about whether it's a logical

identifier or a physical identifier.  If the former, then somewhere

(perhaps below the network layer) the logical identifier has been bound

to something in the physical interface, but that's not our problem.



The number space for types of MNIDs is likely to stay pretty empty, so

I'd say we could add as many types as would be convenient for the

software designers.  So, we could conceivably have several MNIDs

defined that all "looked like" NAIs (which, themselves, "look like"

FQDNs).



Regards,

Charlie P.







On 9/10/2014 8:11 AM, Sri Gundavelli (sgundave) wrote:

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" <[e-mail]><mailto:[e-mail]> 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:[e-mail]] On Behalf Of Sri Gundavelli

(sgundave)

Sent: Dienstag, 9. September 2014 23:30

To: Sri Gundavelli (sgundave); Charlie Perkins; [e-mail]<mailto:[e-mail]>

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)" <[e-mail]><mailto:[e-mail]>

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"

<[e-mail]><mailto:[e-mail]>

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

[e-mail]<mailto:[e-mail]>https://www.ietf.org/mailman/listinfo/dmm

_______________________________________________

dmm mailing list

[e-mail]<mailto:[e-mail]>https://www.ietf.org/mailman/listinfo/dmm

_______________________________________________

dmm mailing list

[e-mail]<mailto:[e-mail]>https://www.ietf.org/mailman/listinfo/dmm

_______________________________________________

dmm mailing list

[e-mail]<mailto:[e-mail]>https://www.ietf.org/mailman/listinfo/dmm


_______________________________________________
dmm mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/dmm


--
---------------------------------
Hakima Chaouchi
Professor
Telecom Sud Paris
Institut Mines Telecom
9 rue Charles Fourier
91011 Evry
0160764443






--

Regards,

Charlie P.



--

Regards,

Charlie P.