Re: [DMM] MNID Types

"Sri Gundavelli (sgundave)" <sgundave@cisco.com> Fri, 26 September 2014 05:54 UTC

Return-Path: <sgundave@cisco.com>
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 A23121A1A23 for <dmm@ietfa.amsl.com>; Thu, 25 Sep 2014 22:54:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -15.286
X-Spam-Level:
X-Spam-Status: No, score=-15.286 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.786, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
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 wX-xsEGxnE0r for <dmm@ietfa.amsl.com>; Thu, 25 Sep 2014 22:54:56 -0700 (PDT)
Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A65D41A0158 for <dmm@ietf.org>; Thu, 25 Sep 2014 22:54:55 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=53434; q=dns/txt; s=iport; t=1411710895; x=1412920495; h=from:to:cc:subject:date:message-id:in-reply-to: mime-version; bh=XVpx7CsHdsTCcwzm0aA77Fmn8ek9y5+bEn/n6iR0Nb8=; b=Tr/8h2AW795Bux0S9PyxfOmhLz4kna/oNkTGp+5/kHNTPbB6kPe6CHos dyYNp0nT32YzOjORDola28l7XucE4wcKMMGI+VOe8UVfyLZrJWegfT2Oe oxkjd3vT7osKAGyCaR4obpA4ptzYej1en98FJnIawKKD3MOUYR8WKfBhy k=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AkUFAMz+JFStJV2Z/2dsb2JhbABXCYJIRlNXBIJ9xywBCYdOAhhsFgF7hAMBAQEDAQEBARcJSwsFBwYBCBEDAQEBDhMBBgMCBCULFAkIAgQOBQmIIQMJCA2rNo5cG4cWAReNXhCBVTAJBwoHBgQGAQIEgnKBUwWGJokighiLQ5VWg2NsAYFHgQIBAQE
X-IronPort-AV: E=Sophos; i="5.04,603,1406592000"; d="scan'208,217"; a="81383219"
Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by alln-iport-1.cisco.com with ESMTP; 26 Sep 2014 05:54:54 +0000
Received: from xhc-aln-x11.cisco.com (xhc-aln-x11.cisco.com [173.36.12.85]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id s8Q5ssV0030122 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 26 Sep 2014 05:54:54 GMT
Received: from xmb-aln-x03.cisco.com ([169.254.6.21]) by xhc-aln-x11.cisco.com ([173.36.12.85]) with mapi id 14.03.0195.001; Fri, 26 Sep 2014 00:54:54 -0500
From: "Sri Gundavelli (sgundave)" <sgundave@cisco.com>
To: Hakima Chaouchi <hakima.chaouchi@telecom-sudparis.eu>
Thread-Topic: [DMM] MNID Types
Thread-Index: AQHP2U5kVRllY2Aql0WvU4ZtNAqY9A==
Date: Fri, 26 Sep 2014 05:54:53 +0000
Message-ID: <D04A4C12.166E7A%sgundave@cisco.com>
In-Reply-To: <1478038645.11626223.1411705901240.JavaMail.zimbra@telecom-sudparis.eu>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/14.2.3.120616
x-originating-ip: [10.32.246.217]
Content-Type: multipart/alternative; boundary="_000_D04A4C12166E7Asgundaveciscocom_"
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/dmm/GIDOK1isBR8POVHw7WvjztsJUPA
Cc: Vijay Devarapalli <dvijay@rocketmail.com>, "dmm@ietf.org" <dmm@ietf.org>
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:54:59 -0000

Thanks.

Thinking about this further, having the RFID subtype  is probably going to be extremely useful for IOT applications. A MAG/MR can potentially register devices identified with RFID as the NAI; Also, there seems to be some mapping between 64-bit EPC and IPv6 Identifier, allowing device addressability over IPv6 and that makes this interesting and enable some new use-cases.

Regards
Sri




From: Hakima Chaouchi <hakima.chaouchi@telecom-sudparis.eu<mailto:hakima.chaouchi@telecom-sudparis.eu>>
Date: Thursday, September 25, 2014 9:31 PM
To: Sri Gundavelli <sgundave@cisco.com<mailto:sgundave@cisco.com>>
Cc: "Charles E. Perkins" <charliep@computer.org<mailto:charliep@computer.org>>, Vijay Devarapalli <dvijay@rocketmail.com<mailto:dvijay@rocketmail.com>>, "dmm@ietf.org<mailto:dmm@ietf.org>" <dmm@ietf.org<mailto:dmm@ietf.org>>
Subject: Re: [DMM] MNID Types

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<mailto:sgundave@cisco.com>>
À: "Charles E. Perkins" <charliep@computer.org<mailto:charliep@computer.org>>
Cc: "Vijay Devarapalli" <dvijay@rocketmail.com<mailto:dvijay@rocketmail.com>>, dmm@ietf.org<mailto: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><mailto: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><mailto: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<mailto: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><mailto: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><mailto: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<mailto: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><mailto: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><mailto: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.org<mailto:dmm@ietf.org>https://www.ietf.org/mailman/listinfo/dmm

_______________________________________________
dmm mailing list
dmm@ietf.org<mailto:dmm@ietf.org>https://www.ietf.org/mailman/listinfo/dmm

_______________________________________________
dmm mailing list
dmm@ietf.org<mailto:dmm@ietf.org>https://www.ietf.org/mailman/listinfo/dmm

_______________________________________________
dmm mailing list
dmm@ietf.org<mailto:dmm@ietf.org>https://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<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