Re: MNID Types
"Charles E. Perkins" <[email protected]>
| Newsgroups | gmane.ietf.nemo |
|---|---|
| Organization | Blue Skies |
| Message-ID | <[email protected]> |
Hello folks, Now we have two kinds of identifiers that could reasonably be grouped as a type plus subtypes. I could specify this by writing another section of the new draft that lays out another subtype field after the MNID subtype field from 4283. I guess it would be a "subsubtype" field if we are following the nomenclature for the fields as shown in RFC 4283. Or, alternatively, I could specify that for some types (e.g., DUID and RFID), the first eight bits of the identifier is the a field that we might call the "identifier subtype". Maybe that is cleaner. A third option would be to update RFC 4283, but that seems to be a bit heavy-handed. Comments? Or other options? Regards, Charlie P. On 9/25/2014 9:31 PM, Hakima Chaouchi wrote: > Hi, > > For RFID we refer to the EPC standards. > > "The /Electronic Product Code/ (EPC) is an identification scheme for > universally identifying physical objects by using Radio Frequency > Identification (RFID) tags. > The standardized EPC tag encoding consists of an EPC Identifier that > uniquely identifies an individual object, and may also include a > filter value if the filter is needed to enable effective and efficient > reading of the EPC tags. The EPC Identifier is a meta-coding scheme > designed to support the needs of various industries by accommodating > existing coding schemes where possible and by defining new schemes > where necessary." > > "EPC supports several encoding systems or schemes including GID > (Global Identifier), SGTIN (Serialized Global Trade Item Number), SSCC > (Serial Shipping Container), GLN (Global Location Number), GRAI > (Global Returnable Asset Identifier), DOD (Department of Defense) and > GIAI (Global Individual Asset Identifier). > > For each scheme except GID, there are two variations—a 64-bit scheme > (for example, GLN-64) and a 96-bit scheme (GLN-96). GID has only a > 96-bit scheme. > > Within each scheme, an EPC identifier can be represented in a binary > form or other forms such as URI ..etc". > > May be we need some subtyping. > > Cheers, > > Hakima > > > ------------------------------------------------------------------------ > *De: *"Sri Gundavelli (sgundave)" <[email protected]> > *À: *"Charles E. Perkins" <[email protected]> > *Cc: *"Vijay Devarapalli" <[email protected]>, [email protected] > *Envoyé: *Vendredi 26 Septembre 2014 03:36:01 > *Objet: *Re: [DMM] MNID Types > > Hi Charlie, > > > 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? > > I do not know the answer for this question. I assumed DOD-96 is a > mandated standard for RFID encoding, but looks like there are other > formats like GID-96 ..etc. May be this may end up needing subtypes. We > can defer this question to Hakima and learn some details on this, she > seems to have written many books on RFID. > > > Regards > Sri > > > > From: "Charles E. Perkins" <[email protected] > <mailto:[email protected]>> > Organization: Blue Skies > Date: Thursday, September 25, 2014 1:42 PM > To: Sri Gundavelli <[email protected] <mailto:[email protected]>> > Cc: "[email protected] <mailto:[email protected]>" <[email protected] > <mailto:[email protected]>>, Vijay Devarapalli <[email protected] > <mailto:[email protected]>> > 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 <[email protected] > <mailto:[email protected]>> > Date: Sunday, September 21, 2014 8:11 AM > To: Sri Gundavelli <[email protected] <mailto:[email protected]>> > Cc: Charlie Perkins <[email protected] > <mailto:[email protected]>>, Marco Liebsch > <[email protected] <mailto:[email protected]>>, > "[email protected] <mailto:[email protected]>" <[email protected] > <mailto:[email protected]>>, Vijay Devarapalli <[email protected] > <mailto:[email protected]>> > 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)" <[email protected] > <mailto:[email protected]>> > *À: *"Charlie Perkins" <[email protected] > <mailto:[email protected]>>, "Marco Liebsch" > <[email protected] <mailto:[email protected]>>, > [email protected] <mailto:[email protected]>, "Vijay Devarapalli" > <[email protected] <mailto:[email protected]>> > *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 <[email protected] > <mailto:[email protected]>> > Date: Thursday, September 11, 2014 2:46 PM > To: Sri Gundavelli <[email protected] > <mailto:[email protected]>>, Marco Liebsch > <[email protected] <mailto:[email protected]>>, > "[email protected] <mailto:[email protected]>" <[email protected] > <mailto:[email protected]>>, Vijay Devarapalli <[email protected] > <mailto:[email protected]>> > 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)"<[email protected]> 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"<[email protected]> 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:[email protected]] > Sent: Donnerstag, 11. September 2014 00:42 > To: Charlie Perkins; Marco Liebsch;[email protected] > 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"<[email protected]> > 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"<[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]://www.ietf.org/mailman/listinfo/dmm > > _______________________________________________ > dmm mailing list > [email protected]://www.ietf.org/mailman/listinfo/dmm > > _______________________________________________ > dmm mailing list > [email protected]://www.ietf.org/mailman/listinfo/dmm > > _______________________________________________ > dmm mailing list > [email protected]://www.ietf.org/mailman/listinfo/dmm > > > > _______________________________________________ > dmm mailing list > [email protected] <mailto:[email protected]> > 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. > > _______________________________________________ > dmm mailing list > [email protected] > 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. _______________________________________________ dmm mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmm