Re: [DMM] MNID Types

"Charles E. Perkins" <charliep@computer.org> Fri, 26 September 2014 05:46 UTC

Return-Path: <charliep@computer.org>
X-Original-To: dmm@ietfa.amsl.com
Delivered-To: dmm@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 532E61A0218 for <dmm@ietfa.amsl.com>; Thu, 25 Sep 2014 22:46:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.234
X-Spam-Level:
X-Spam-Status: No, score=-1.234 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_SOFTFAIL=0.665] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TK_Ja1myDm_L for <dmm@ietfa.amsl.com>; Thu, 25 Sep 2014 22:46:26 -0700 (PDT)
Received: from elasmtp-spurfowl.atl.sa.earthlink.net (elasmtp-spurfowl.atl.sa.earthlink.net [209.86.89.66]) by ietfa.amsl.com (Postfix) with ESMTP id C6A691A02BA for <dmm@ietf.org>; Thu, 25 Sep 2014 22:46:25 -0700 (PDT)
Received: from [99.51.72.196] (helo=[192.168.1.80]) by elasmtp-spurfowl.atl.sa.earthlink.net with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.67) (envelope-from <charliep@computer.org>) id 1XXOMI-0006Od-VT; Fri, 26 Sep 2014 01:46:23 -0400
Message-ID: <5424FDAD.609@computer.org>
Date: Thu, 25 Sep 2014 22:46:21 -0700
From: "Charles E. Perkins" <charliep@computer.org>
Organization: Blue Skies
User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: Hakima Chaouchi <hakima.chaouchi@telecom-sudparis.eu>, dmm@ietf.org
References: <D04A103F.166DDC%sgundave@cisco.com> <1478038645.11626223.1411705901240.JavaMail.zimbra@telecom-sudparis.eu>
In-Reply-To: <1478038645.11626223.1411705901240.JavaMail.zimbra@telecom-sudparis.eu>
Content-Type: multipart/alternative; boundary="------------010706010500060108060603"
X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956527bd5036cbc8ac70d7c97b3520082a6932aa9f5a7611eae350badd9bab72f9c350badd9bab72f9c
X-Originating-IP: 99.51.72.196
Archived-At: http://mailarchive.ietf.org/arch/msg/dmm/GUjh_YBVovPTCV48KA2fdEOjNG8
Cc: Vijay Devarapalli <dvijay@rocketmail.com>
Subject: Re: [DMM] MNID Types
X-BeenThere: dmm@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Distributed Mobility Management Working Group <dmm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dmm>, <mailto:dmm-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dmm/>
List-Post: <mailto:dmm@ietf.org>
List-Help: <mailto:dmm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dmm>, <mailto:dmm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 26 Sep 2014 05:46:29 -0000

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)" <sgundave@cisco.com>
> *À: *"Charles E. Perkins" <charliep@computer.org>
> *Cc: *"Vijay Devarapalli" <dvijay@rocketmail.com>, dmm@ietf.org
> *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" <charliep@computer.org 
> <mailto:charliep@computer.org>>
> Organization: Blue Skies
> Date: Thursday, September 25, 2014 1:42 PM
> To: Sri Gundavelli <sgundave@cisco.com <mailto:sgundave@cisco.com>>
> Cc: "dmm@ietf.org <mailto:dmm@ietf.org>" <dmm@ietf.org 
> <mailto:dmm@ietf.org>>, Vijay Devarapalli <dvijay@rocketmail.com 
> <mailto:dvijay@rocketmail.com>>
> 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 <hakima.chaouchi@telecom-sudparis.eu
>     <mailto:hakima.chaouchi@telecom-sudparis.eu>>
>     Date: Sunday, September 21, 2014 8:11 AM
>     To: Sri Gundavelli <sgundave@cisco.com <mailto:sgundave@cisco.com>>
>     Cc: Charlie Perkins <charles.perkins@earthlink.net
>     <mailto:charles.perkins@earthlink.net>>, Marco Liebsch
>     <Marco.Liebsch@neclab.eu <mailto:Marco.Liebsch@neclab.eu>>,
>     "dmm@ietf.org <mailto:dmm@ietf.org>" <dmm@ietf.org
>     <mailto:dmm@ietf.org>>, Vijay Devarapalli <dvijay@rocketmail.com
>     <mailto:dvijay@rocketmail.com>>
>     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)" <sgundave@cisco.com
>     <mailto:sgundave@cisco.com>>
>     *À: *"Charlie Perkins" <charles.perkins@earthlink.net
>     <mailto:charles.perkins@earthlink.net>>, "Marco Liebsch"
>     <Marco.Liebsch@neclab.eu <mailto:Marco.Liebsch@neclab.eu>>,
>     dmm@ietf.org <mailto:dmm@ietf.org>, "Vijay Devarapalli"
>     <dvijay@rocketmail.com <mailto:dvijay@rocketmail.com>>
>     *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 <charles.perkins@earthlink.net
>     <mailto:charles.perkins@earthlink.net>>
>     Date: Thursday, September 11, 2014 2:46 PM
>     To: Sri Gundavelli <sgundave@cisco.com
>     <mailto:sgundave@cisco.com>>, Marco Liebsch
>     <Marco.Liebsch@neclab.eu <mailto:Marco.Liebsch@neclab.eu>>,
>     "dmm@ietf.org <mailto:dmm@ietf.org>" <dmm@ietf.org
>     <mailto:dmm@ietf.org>>, Vijay Devarapalli <dvijay@rocketmail.com
>     <mailto:dvijay@rocketmail.com>>
>     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)"<sgundave@cisco.com>  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"<Marco.Liebsch@neclab.eu>  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:sgundave@cisco.com]
>                     Sent: Donnerstag, 11. September 2014 00:42
>                     To: Charlie Perkins; Marco Liebsch;dmm@ietf.org
>                     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"<charles.perkins@earthlink.net>
>                     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"<Marco.Liebsch@neclab.eu>  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:dmm-bounces@ietf.org] On Behalf Of Sri Gundavelli
>                                     (sgundave)
>                                     Sent: Dienstag, 9. September 2014 23:30
>                                     To: Sri Gundavelli (sgundave); Charlie Perkins;dmm@ietf.org
>                                     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)"<sgundave@cisco.com>
>                                     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"
>                                         <charles.perkins@earthlink.net>
>                                         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
>                                         dmm@ietf.orghttps://www.ietf.org/mailman/listinfo/dmm
>
>                                     _______________________________________________
>                                     dmm mailing list
>                                     dmm@ietf.orghttps://www.ietf.org/mailman/listinfo/dmm
>
>             _______________________________________________
>             dmm mailing list
>             dmm@ietf.orghttps://www.ietf.org/mailman/listinfo/dmm
>
>         _______________________________________________
>         dmm mailing list
>         dmm@ietf.orghttps://www.ietf.org/mailman/listinfo/dmm
>
>
>
>     _______________________________________________
>     dmm mailing list
>     dmm@ietf.org <mailto:dmm@ietf.org>
>     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
> dmm@ietf.org
> 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.