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:[email protected]] *On Behalf Of *Charles E. Perkins
*Sent:* Thursday, September 25, 2014 1:43 PM
*To:* Sri Gundavelli (sgundave)
*Cc:* Vijay Devarapalli; [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]>
<mailto:[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]>
<mailto:[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]
<mailto:[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]> <mailto:[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]> <mailto:[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] <mailto:[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]> <mailto:[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]>
<mailto:[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]
<mailto:[email protected]>https://www.ietf.org/mailman/listinfo/dmm
_______________________________________________
dmm mailing list
[email protected]
<mailto:[email protected]>https://www.ietf.org/mailman/listinfo/dmm
_______________________________________________
dmm mailing list
[email protected]
<mailto:[email protected]>https://www.ietf.org/mailman/listinfo/dmm
_______________________________________________
dmm mailing list
[email protected]
<mailto:[email protected]>https://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.
