Hi Xiangsong,
On Aug 29, 2009, at 4:16 AM, Xiangsong Cui wrote:
Hi Jouni,
Please see inline.
Regards
Xiangsong
----- Original Message ----- From: "jouni korhonen"
<jouni.nospam at gmail.com
>
To: "Xiangsong Cui" <Xiangsong.Cui at huawei.com>
Cc: "Vijay Devarapalli" <vijay at wichorus.com>; <netlmm at ietf.org>
Sent: Friday, August 28, 2009 6:56 PM
Subject: Re: [netlmm] I-D Action:draft-ietf-netlmm-lma- discovery-01.txt
Hi,
On Aug 28, 2009, at 12:19 PM, Xiangsong Cui wrote:
Hi Jouni,
And what's the problem with that if it is part of the normal lower
layer attach procedure? The MN has a blob of information that it
knows what to do with to get an access, but does not know/care about
its content. Yet, we have not changed anything in the MN that it
would do normally in any case.
I don't know what kind of MN or OS can achieve this operation,
maybe you can give me some example.
As I said in an earlier mail, this procedure is analogous to 3G/EPS
attach procedure under certain conditions. There's a bunch of such MNs
out there.. but that is not relevant from the I-D point of view.
Even the MN exists, you are now designing a new container, and putting
Hmm.. If such MN & lower layer exists then I could not possibly be
designing any new container as it is already there.
We need some existing examples for this. The solution can not depend on
any nonexistent assumption.
If it makes folks happy, we can add a reference to one example of such
functionality.
The solution described in this section is similar to the solution
discussed in Section 3.1. Instead of deriving the LMA FQDN from the
MN identity, the MAG receives a LMA FQDN or an IP address information
from lower layers, for example, as a part of the normal lower layer
signaling when the MN attaches to the network. One existing example
of such lower layer functionality is the Access Point Name
Information Element (APN IE) in 3GPP radio's network access signaling
capable of carrying a FQDN [3GPP.24.008]. However, in general this
means the MN is also the originator of the LMA information. The LMA
information content as such can be transparent to the MN, meaning the
MN has no knowledge it being anything LMA related.
special new information block in it, the MN must read and include the
If the information blob were transparent to the MN, the MN would not
see anything special in it.
The precondition is a problem, another problem is that the MN does do
the action related to mobility management.
Even the action (i.e. offering LMA information ) is not in the
consciousness of the MN, the fact does still exist,
the action is done by the MN and the MN is involved in the mobility
management.
The principle of NETLMM WG is "MN not *involved* in the mobility
management", but not "MN not *active* in the mobility management",
right?
Well.. the charter talks about "specifying any changes to mobile hosts is
out of scope", which in most cases realizes to no host involvement or
similar that would require code changes etc. However, in this particular
case, when we talk about MNs that have desired capabilities at lower
layers (e.g. in network access signaling), we are not changing the mobile
host but just taking advantage of the existing functionality on the
_network_ side.
From my side, I am done now ;)
Cheers,
Jouni
newly-added additional information block in the signal message.
And the MN would do the same even if PMIP was not deployed.
Does it not need extension or enhancement?
Cheers,
Jouni
Regards
Xiangsong
----- Original Message ----- From: "jouni korhonen"
<jouni.nospam at gmail.com
>
To: "Xiangsong Cui" <Xiangsong.Cui at huawei.com>
Cc: "Vijay Devarapalli" <vijay at wichorus.com>; <netlmm at ietf.org>
Sent: Friday, August 28, 2009 4:44 PM
Subject: Re: [netlmm] I-D Action:draft-ietf-netlmm-lma-
discovery-01.txt
Hi,
On Aug 28, 2009, at 11:25 AM, Xiangsong Cui wrote:
Hi,
please see inline.
Regards/Xiangsong
----- Original Message ----- From: "jouni korhonen"
<jouni.nospam at gmail.com
>
To: "Xiangsong Cui" <Xiangsong.Cui at huawei.com>
Cc: "Vijay Devarapalli" <vijay at wichorus.com>; <netlmm at ietf.org>
Sent: Friday, August 28, 2009 4:05 PM
Subject: Re: [netlmm] I-D Action:draft-ietf-netlmm-lma-
discovery-01.txt
Hi,
On Aug 28, 2009, at 5:11 AM, Xiangsong Cui wrote:
Hi Jouni,
However, the LMA information content as such can be transparent
to
the MN, meaning the MN has no knowledge it being anything LMA
related.
If the MN don't know what the information is, why does it include
the
content in the transmitted message?
It can be part of a lower layer attach procedure and the MN does
what it is specified to do.
I can't understand this situation: some information content is
included
in the signal message, but the origin and the destination do take
different
comprehension on this content.
For example, the MN has some operator provisioned information that
the MN knows it needs to signal to the network during the attach
procedure
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
In these cases, MN knows what the information is, and knows the
information should be transimitted to the network, and then it does
signal
the information to the network.
And what's the problem with that if it is part of the normal lower
layer attach procedure? The MN has a blob of information that it
knows what to do with to get an access, but does not know/care about
its content. Yet, we have not changed anything in the MN that it
would do normally in any case.
Jouni
in order to get access & reach certain desired service. The
information happens to be in a FQDN format that maps to a specific
LMA. The MAG knows this fact but the MN does not care/ know about
it. This is analogous to 3G/EPC attach procedure under certain
conditions.
Cheers,
Jouni
Regards
Xiangsong
----- Original Message ----- From: "jouni korhonen"
<jouni.nospam at gmail.com
>
To: "Xiangsong Cui" <Xiangsong.Cui at huawei.com>
Cc: "Vijay Devarapalli" <vijay at wichorus.com>; <netlmm at ietf.org>
Sent: Thursday, August 27, 2009 9:12 PM
Subject: Re: [netlmm] I-D Action:draft-ietf-netlmm-lma-
discovery-01.txt
Hi,
On Aug 27, 2009, at 11:57 AM, Xiangsong Cui wrote:
Hi Jouni,
Let's take a precise analyse on this issue.
You said such information may come from lower layers,
but who generate this information?
Does lower layer generate the LMA information or the
LMA information does depend on the link type?
I think it is not.
Maybe it is the user who configures the LMA information
in the mobile node (i.e. the device), but in the MAG
perspective,
the initiator of the message which contains the LMA information,
the initiator is the MN, the MAG gets the LMA information from
the mobile node.
For example, the MAG gets LMA information from AAA server,
and the LMA information in AAA server is configured by the
administrator.
We can say MAG gets LMA information from AAA server but nobody
says MAG gets LMA information from the administrator.
So I think it is a MN-assist solution.
The MN is only doing what it would do independent of PMIP being
deployed or not and the MAG just makes advantage of it. Some
existing systems & MNs already do this.
Based on the discussion we have had I think it is now worth
keeping this solution in the I-D. I would, however, reword it
like:
The solution described in this section is similar to the solution
discussed in Section 3.1. Instead of deriving the LMA FQDN
from the
MN identity, the MAG receives explicit LMA FQDN or IP address
information from lower layers, for example, as a part of the
normal
lower layer signaling when the MN attaches to the network. This
usually means the MN is also the originator of the LMA
information.
However, the LMA information content as such can be transparent
to
the MN, meaning the MN has no knowledge it being anything LMA
related.
Cheers,
Jouni
Regards/Xiangsong
----- Original Message ----- From: "jouni korhonen"
<jouni.nospam at gmail.com
>
To: "Xiangsong Cui" <Xiangsong.Cui at huawei.com>
Cc: "Vijay Devarapalli" <vijay at wichorus.com>; <netlmm at ietf.org>
Sent: Thursday, August 27, 2009 4:15 PM
Subject: Re: [netlmm] I-D Action:draft-ietf-netlmm-lma-
discovery-01.txt
Hi,
On Aug 27, 2009, at 5:11 AM, Xiangsong Cui wrote:
Hi Vijay,
I think I got your point, but I still have some questions.
1, NETLMM WG is about mobility management, so the item
of LMA discovery is of course in scope of mobility management,
is it right?
ok.
2, MN provides LMA information to MAG, is a *MN-assistant*
LMA discovery, is it right?
We are a bit on a grey area here. Like the text says such
information may come from lower layers. If such information
delivery is e.g. part of the normal L2 attach procedure
independent whether there is PMIP or not, I would not call it
in that case MN assisted LMA discovery.
3, MN-assistant LMA discovery means MN involves in the
mobility
management, is it right?
Continuing from the above. If the information that MN provides
is configured into MNs and this configuration is independent
whether there is PMIP or not, I would not say that MN is
involved in the mobility management. The content of the
configuration data might then be different depending whether
PMIP is used but that is transparent to MNs.
Cheers,
Jouni
Regards
Xiangsong
----- Original Message ----- From: "Vijay Devarapalli"
<vijay at wichorus.com
>
To: "Xiangsong Cui" <Xiangsong.Cui at huawei.com>; "jouni
korhonen" <jouni.nospam at gmail.com
>
Cc: <netlmm at ietf.org>
Sent: Thursday, August 27, 2009 8:32 AM
Subject: RE: [netlmm] I-D Action:draft-ietf-netlmm-lma-
discovery-01.txt
You are right. I am not disagreeing that the mobile node
knows that
PMIPv6 is being used in the network when it sends the LMA
information to
the MAG. But we have a sort of working assumption that the MN
is able to
supply certain information to the MAG at L2, for example,
attach versus
handover indication. This would be similar to that.
Vijay
-----Original Message-----
From: Xiangsong Cui [mailto:Xiangsong.Cui at huawei.com]
Sent: Monday, August 24, 2009 7:13 PM
To: Vijay Devarapalli; jouni korhonen
Cc: netlmm at ietf.org
Subject: Re: [netlmm] I-D
Action:draft-ietf-netlmm-lma-discovery-01.txt
Hi Vijay,
In my understanding, LMA is a functional element of mobility
management, the mobile node with only simple IP stack can't
recognize the information of LMA and can't transmit it to
MAG.
If the mobile node can't send this information to MAG,
MAG can't receive this information from mobile node.
Regards/Xiangsong
----- Original Message ----- From: "Vijay Devarapalli"
<vijay at wichorus.com
>
To: "jouni korhonen" <jouni.nospam at gmail.com>; "Xiangsong
Cui"
<Xiangsong.Cui at huawei.com>
Cc: <netlmm at ietf.org>
Sent: Tuesday, August 25, 2009 1:47 AM
Subject: Re: [netlmm] I-D
Action:draft-ietf-netlmm-lma-discovery-01.txt
Hello,
On 8/24/09 1:56 AM, "jouni korhonen" wrote:
>> Section 3.2,
>> " This usually means the MN is the
>> originator of the LMA information and explicitly
participates to the
>> mobility management signaling "
>>
>> In NETLMM, the principle is that the MN should not be
involved
in
>> mobility management, right?
>> So the solution "Receiving LMA FQDN or IP Address"
should be
>> deleted in the netlmm WG draft.
>
> I would be fine deleting this section. Others?
I disagree. The section explicitly says the MAG receives the
LMA FQDN or IP
address from the MN in the lower layers. This is not the same
as the MN
doing mobility management.
Vijay