Hello folks,
It seems to me that we may be perhaps arriving at a good point for a new
draft.
However, there are still some points of discussion that are perhaps
worthy to
be resolved (for example, in my email earlier this week).
Maybe we should fire up the issue tracker...?
Regards,
Charlie P.
On 6/7/2012 12:04 PM, Behcet Sarikaya wrote:
Hi Jouni,
What are the plans on DMM requirements? I see lots of mails and never
ending discussions.
Isn't it the time to get the draft out, thank Anthony for his hard
work and move on?
Regards,
Behcet
On Wed, Jun 6, 2012 at 11:32 AM, h chan <[email protected]
<mailto:[email protected]>> wrote:
Yes, the second and third sentences are not additional
requirements, but rather explanations of the requirement in the
first sentence. Does the rewrite sound better now:
REQ-2: Transparency to Upper Layers
The DMM solutions SHALL provide transparency above the IP layer
when needed. Such transparency is needed, when the mobile hosts or
entire mobile networks change their point of attachment to the
Internet, for the application flows that cannot cope with a change
of IP address. Otherwise the support to maintain a stable home IP
address or prefix during handover may be declined.
H Anthony Chan
*From:*[email protected] <mailto:[email protected]>
[mailto:[email protected] <mailto:[email protected]>]
*Sent:* Wednesday, June 06, 2012 12:56 AM
*To:* h chan
*Cc:* [email protected] <mailto:[email protected]>; [email protected]
<mailto:[email protected]>; jouni korhonen; Peter McCann
*Subject:* ??: Re: [DMM] draft requirement REQ-2: Transparency to
Upper Layers
Hi Anthony:
The last part of the sentence (i.e. /but the need to maintain a
stable home IP address or prefix SHOULD NOT be taken as default/.)
seems a littel strange to me. REQ-2 just describes under what
circumstances the transparency is needed (i.e. /when the mobile
hosts or entire mobile networks change their point of attachment
to the Internet, for the application flows that cannot cope with a
change of IP address/), that means automatically, otherwise the
transparency is not needed. So why bother to write the last part
of thesentence?
Besides, when mobile node attaches to its home network, it will
obviously get a home IP address/prefix from its home network. The
IP address/prefix can be considered as stable IP, as long as the
mobile does not change its point of attachment. The last part of
the sentence will just exclude this scenario.
If I make any mistake, please correct me.
Thanks
Luowen
*h chan <[email protected]
<mailto:[email protected]>>*
? ??: [email protected] <mailto:[email protected]>
2012/06/06 01:12
???
"[email protected] <mailto:[email protected]>" <[email protected]
<mailto:[email protected]>>, Peter McCann <[email protected]
<mailto:[email protected]>>, jouni korhonen
<[email protected] <mailto:[email protected]>>
??
??
Re: [DMM] draft requirement REQ-2: Transparency to Upper Layers
Revise as follows:
REQ-2: Transparency to Upper Layers
The DMM solutions SHALL provide transparency above the IP layer
when needed. Such transparency is needed, when the mobile hosts or
entire mobile networks change their point of attachment to the
Internet, for the application flows that cannot cope with a change
of IP address, but the need to maintain a stable home IP address
or prefix SHOULD NOT be taken as default.
REQ-2M (Motivation for REQ-2)
The goal of this requirement is to enable more efficient use of
network resources and more efficient routing by not maintaining a
stable IP home IP address when there is no such need.
H Anthony Chan
-----Original Message-----
From: [email protected] <mailto:[email protected]>
[mailto:[email protected] <mailto:[email protected]>] On
Behalf Of h chan
Sent: Wednesday, May 23, 2012 7:51 PM
To: Peter McCann; jouni korhonen
Cc: [email protected] <mailto:[email protected]>
Subject: Re: [DMM] draft requirement REQ-2: Transparency to Upper
Layers
An attempt to clean up the text so far:
REQ-2: Transparency to Upper Layers
The DMM solutions SHALL provide transparency above the IP layer
when needed. Such transparency is needed, when the mobile hosts or
entire mobile networks change their point of attachment to the
Internet, for the application flows that cannot cope with a change
of IP address, but SHOULD NOT be taken as the default behavior.
REQ-2M (Motivation for REQ-2)
The goal of this requirement is to enable more efficient use of
network resources and more efficient routing when mobility support
is implemented by not invoking it for the application flows and
nodes that do not need it.
RELEVANT problem:
PS5: Wasting resources to support mobile nodes not needing
mobility support
IP mobility support is not always required. For example, some
applications do not need a stable IP address during handover, i.e.
IP session continuity. Sometimes, the entire application session
runs while the terminal does not change the point of attachment.
In these situations that do not require IP mobility support,
network resources are wasted when including additional info to the
mobility context to support the change the point of attachment.
Network resources are also wasted when the via routes are set up
for many MNs that do not require IP mobility support.
OTHER related problem
O-PS1: Mobility signaling overhead with peer-to-peer communication
While mobility management enables a mobile host to be reachable,
the hosts may then communicate directly so that the mobility
support is no longer needed. Taking the need of mobility support
as the default behavior will waste network resources.
O-PS2: Lack of user-centricity
Centralized deployment compared with distributed mobility
management may be less capable to support user-centricity. Example
in the lack of user-centricity is to provide mobility support to
all mobile nodes by default regardless of whether the user needs
it or not.
H Anthony Chan
-----Original Message-----
From: Peter McCann
Sent: Friday, May 18, 2012 9:35 AM
To: jouni korhonen; h chan
Cc: [email protected] <mailto:[email protected]>
Subject: RE: [DMM] draft requirement REQ-2: Transparency to Upper
Layers
Hi, Jouni,
jouni korhonen wrote:
>
> Few comments/questions here:
>
> On May 7, 2012, at 8:58 PM, h chan wrote:
>
>> REQ-2: Transparency to Upper Layers
>> The DMM solutions SHALL enable transparency above the IP layer.
Such
>> transparency is needed for the application flows that cannot
cope with
>> a change of IP address and when mobile hosts or entire mobile
networks
>> change their point of attachment to the Internet, but SHOULD NOT be
>> taken as the default behavior.
>
> "SHALL enable" but "SHOULD NOT be taken as the default behavior"
seem
> to conflict. So, what is really meant here? Does this mean something
> like "MUST implement, SHOULD use" type of solution? Or can one leave
> transparency completely away if the applications/hosts just
don't care
> whether IP changes or not?
I think the latter. If the applications don't care about
transparency,
then we don't need to pay for it with state and signaling in the
network.
However, we know that some applications do care, so it SHALL be
possible
to provide it.
>> REQ-2M (Motivation for REQ-2)
>> The goal of this requirement is to
>> enable more efficient use of network resources and more efficient
>> routing by not invoking mobility support when there is no such
need.
>
> Does this still mean the mobility support must be implement even
if it
> is not used?
We need some strategy for keeping an IP address through some amount of
mobility. However, we needn't optimize the network for this case
as it
might be rather uncommon to keep an address for a very long period of
time.
>> RELEVANT problem:
>> PS5: Wasting resources to support mobile nodes not needing mobility
>> support IP mobility support is not always required. For example,
>> some
>> applications do not need a stable IP address during handover,
i.e. IP
>> session continuity. Sometimes, the entire application session runs
>> while the terminal does not change the point of attachment. In
these
>> situations that do not require IP mobility support, network
resources
>> are wasted when mobility context is set up. Network resources
are also
>> wasted when the via routes are set up for many MNs that do not
require
>> IP mobility support.
>>
>> OTHER related problem
>> O-PS1: Mobility signaling overhead with peer-to-peer communication
>> While mobility management enables a mobile host to be
reachable, the
>> hosts may then communicate directly so that the mobility
support is no
>> longer needed. Taking the need of mobility support as the default
>> behavior will waste network resources.
>> O-PS2: Lack of user-centricity
>> Centralized deployment compared with distributed mobility
management
>> may be less capable to support user-centricity. Example in the
lack of
>> user-centricity is to provide mobility support to all mobile
nodes by
>> default regardless of whether the user needs it or not.
>
> I have issues to parse O-PS2.. the motivation makes sense though but
> the title "lack of user-centricity" is somewhat confusing.. what
does
> forced/always-on mobility support has to do with user centricity?
I think Anthony just meant that we should tailor the mobility
management
to the needs of the user. I wouldn't mind seeing this explanatory
text
re-worded.
-Pete
>
> - Jouni
>
>
>>
>> (The above has been drafted with contributions, inputs and
discussions
>> from various people. Additional contributions and comments are most
>> welcome.)
>>
>> H Anthony Chan
>>
>>
>> _______________________________________________
>> 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
_______________________________________________
dmm mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dmm
--
Regards,
Charlie P.
_______________________________________________
dmm mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dmm
