Subject: [DMM] draft requirement REQ-2: Transparency to Upper Layers

From: h chan <[email-masked]>
Date: Mon, 7 May 2012 17:58:02 +0000

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.

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.

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.

(The above has been drafted with contributions, inputs and discussions from various people. Additional contributions and comments are most welcome.)

H Anthony Chan

---

From: [email-masked]
Date: Wed, 9 May 2012 09:23:40 +0800

Hi Antony:

The last part of PS-5, does the sentence " Network resources are also 
wasted when the via routes are set up for many MNs that do not require IP 
mobility support." implicitly indicate the scenario which similar with 
MIP/PMIP? 
When I read this sentence, the MIP/PMIP tunnel appears in my mind, and 
yes, if MNs do not require IP mobiliy support, the  MIP/PMIP tunnel will 
waste network resources.

Cheers.

h chan <[email-masked]> 
发件人:  [email-masked]
2012/05/08 01:58

收件人
"[email-masked]" <[email-masked]>
抄送

主题
[DMM] draft requirement REQ-2: Transparency to Upper Layers

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.
 
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.
 
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.
 
(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-masked]
https://www.ietf.org/mailman/listinfo/dmm

---

From: [email-masked]
Date: Mon, 14 May 2012 15:31:33 -0700

Dear Anthony, 

I share the same concern as Luowen does for PS5, but also several info for 
associated with this requirements.  Please my comments inline below. 

Thanks. 

[email-masked] 
Sent by: [email-masked]
05/08/2012 06:23 PM

To
h chan <[email-masked]>
cc
[email-masked], "[email-masked]" <[email-masked]>
Subject
[DMM] 答复:  draft requirement REQ-2: Transparency to Upper Layers

Hi Antony: 

Cheers. 

收件人

主题

>>>>>> Comments
(1) What scenario is that "entire mobile networks change their point of 
attachment to the internet"?

RELEVANT problem: 
>>>>>> Comments
(1) I have the same concern as LuoWen does.  We should be more clear what 
are we referring to for the term "mobility context" here?  It is because, 
there would always be context set up for the mobile node attaching to the 
network regardless if the IP mobility is required or not, such as per-MN 
localization information and security context.  I believe that the 
"specific" mobility context that you're referring here is the context info 
that supports the MN for changing their point of attachment to the network 
such as the mobility tunneling info. 
>>>>> Proposed new text 
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 changing 
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 

H Anthony Chan

--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others.
This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender.
This message has been scanned for viruses and Spam by ZTE Anti-Spam system.

---

From: jouni korhonen <[email-masked]>
Date: Fri, 18 May 2012 02:56:55 +0300

Few comments/questions here:

> 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 mo…

"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?

> 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?

> 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 mob…

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?

- Jouni

---

From: Rajeev Koodli <[email-masked]>
Date: Thu, 17 May 2012 17:14:15 -0700

Hi Jouni, All,

Sorry if this has been captured before..

Shouldn't there be a very basic requirement that should first outline why
MIP6 and derivatives could not be deployed in scenarios suitable for DMM? I
reckon this assumes a clear description of what DMM is exists.

Thanks.

-Rajeev

On 5/17/12 4:56 PM, "jouni korhonen" <[email-masked]> wrote:

>> 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.
> 
>> enable more efficient use of network resources and more efficient routing by
>> not invoking mobility support when there is no such need.
> 
>> 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
>> 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.
> 
>> (The above has been drafted with contributions, inputs and discussions from
>> various people. Additional contributions and comments are most welcome.)
>>  
>> H Anthony Chan
>> 
>>

---

From: Peter McCann <[email-masked]>
Date: Fri, 18 May 2012 14:34:43 +0000

Hi, Jouni,

jouni korhonen wrote:
>> 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.
 
>> 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.

>> 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
>> 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.
>> Centralized deployment compared with distributed mobility management
>> may be less capable to support user-centricity. Example in the lack of

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

---

From: Peter McCann <[email-masked]>
Date: Fri, 18 May 2012 14:36:42 +0000

Hi,

I think MIP6 and derivatives could very well be a part of the solution.
However, we need to place them into scenarios where the anchors are
allocated dynamically on an as-needed basis and garbage collected when
they are no longer needed.  This may introduce some new requirements.

-Pete

Rajeev Koodli wrote:
> Shouldn't there be a very basic requirement that should first outline
> why MIP6 and derivatives could not be deployed in scenarios suitable for
> DMM? I reckon this assumes a clear description of what DMM is exists.
> 
> Thanks.
> 
> -Rajeev
> 
> 
> 
>>> 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.
>> 
>>> 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.
>> 
>> the title "lack of user-centricity" is somewhat confusing.. what
>> does forced/always-on mobility support has to do with user centricity?
>> 
>> - Jouni
>> 
>> 
>>> 
>>> (The above has been drafted with contributions, inputs and
>>> discussions from various people. Additional contributions and
>>> comments are most welcome.)
>>> 
>>> H Anthony Chan
>>> 
>>>

---

From: Jouni <[email-masked]>
Date: Sat, 19 May 2012 12:09:03 +0300

We got a charter item for what Rajeev is asking for

  Aug 2012 - Submit I-D 'Practices and Gap Analysis' as a working
             group document. To be Informational RFC.

What is though in my head (in Finnish we have saying with pun 
intended that translates as "I was thinking while being drunk" ;)
is that we need a set of requirements that folks has and then
project them into a gap analysis which should be exactly what 
Rajeev is asking for, right? So, we could have a set of requirements
documented and then gap analysis concluding there is nothing
what (H|F|DS)MIP6 would do with a tweak or two or none.

- Jouni

---

From: h chan <[email-masked]>
Date: Tue, 22 May 2012 22:25:29 +0000

Tricci and Luo,

The scenario of entire networks changing their POA is nemo.

PS5 is a problem statement on existing deployment (MIP/PMIP). So I think mobility context here is referring to the additional information when a mobile node attaches to the network in anticipation of possible change of POA compared with what are needed when a fixed node attaches to the network. Nowadays, many people are using the wireless connection with laptop and mobile phones at fixed locations (home or office) not because they anticipate change of POA but rather for the convenience of being cordless. When so many MN are not changing POA, whatever that was set up to prepare for possible change of POA is becoming a waste.
Yet what information is essential and what is wasted could mean different things to different people. Your suggested text to clarify PS5 looks good to me.

H Anthony Chan

From: [email-masked] [mailto:[email-masked]]
Sent: Monday, May 14, 2012 5:32 PM
To: [email-masked]
Cc: [email-masked]; h chan
Subject: Re: [DMM] 答复: draft requirement REQ-2: Transparency to Upper Layers

Dear Anthony,

I share the same concern as Luowen does for PS5, but also several info for associated with this requirements.  Please my comments inline below.

Thanks.

[email-masked]

05/08/2012 06:23 PM

To

cc

Subject

Hi Antony:

The last part of PS-5, does the sentence " Network resources are also wasted when the via routes are set up for many MNs that do not require IP mobility support." implicitly indicate the scenario which similar with MIP/PMIP?
When I read this sentence, the MIP/PMIP tunnel appears in my mind, and yes, if MNs do not require IP mobiliy support, the  MIP/PMIP tunnel will waste network resources.

Cheers.

2012/05/08 01:58

收件人

抄送

主题

>>>>>> Comments
(1) What scenario is that "entire mobile networks change their point of attachment to the internet"?

RELEVANT problem:
>>>>>> Comments
(1) I have the same concern as LuoWen does.  We should be more clear what are we referring to for the term "mobility context" here?  It is because, there would always be context set up for the mobile node attaching to the network regardless if the IP mobility is required or not, such as per-MN localization information and security context.  I believe that the "specific" mobility context that you're referring here is the context info that supports the MN for changing their point of attachment to the network such as the mobility tunneling info.
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 changing 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

H Anthony Chan

---

From: h chan <[email-masked]>
Date: Thu, 24 May 2012 00:08:32 +0000

------------------------------
Regarding the above comment, we probably need to reword this requirement. The intention of this requirement may better be explained with an example. The assumption is that there is a mix of different applications and nodes. Some applications need session continuity support and the nodes does change POA during the application session. Others don't. So one SHOULD not assume every case is the former. 

To the former, a mobility management solution SHALL meet their need. If a solution does not meet their need, we probably cannot call it a mobility management solution. Therefore SHALL is used here. 

How about the following:
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.

H Anthony Chan

-----Original Message-----
From: Peter McCann 
Sent: Friday, May 18, 2012 9:35 AM
To: jouni korhonen; h chan
Cc: [email-masked]
Subject: RE: [DMM] draft requirement REQ-2: Transparency to Upper Layers

Hi, Jouni,

 

-Pete

---

From: h chan <[email-masked]>
Date: Thu, 24 May 2012 00:36:35 +0000

Rute,

Can you explain why it is necessary to introduce the term user centricity here? 

For the following comment, user centricity is a term used by some researcher in a sense analogous to the terms scalability, backward compatibility, etc. Yet I don't know whether the use of this term is considered essential to most people. If people are not convinced, we will remove user centricity. I will leave to Rute to do the explanation. 

H Anthony Chan

> 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 mob…

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?

-----Original Message-----
From: jouni korhonen [mailto:[email-masked]] 
Sent: Thursday, May 17, 2012 6:57 PM
To: h chan
Cc: [email-masked]
Subject: Re: [DMM] draft requirement REQ-2: Transparency to Upper Layers

- Jouni

---

From: h chan <[email-masked]>
Date: Thu, 24 May 2012 00:46:25 +0000

---------------
For the above comment, those existing networks with fixed nodes only would not need to implement MIP. We can clarify as follows:

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. 

H Anthony Chan

-----Original Message-----
From: Peter McCann 
Sent: Friday, May 18, 2012 9:35 AM
To: jouni korhonen; h chan
Cc: [email-masked]
Subject: RE: [DMM] draft requirement REQ-2: Transparency to Upper Layers

Hi, Jouni,

 

-Pete

---

From: h chan <[email-masked]>
Date: Thu, 24 May 2012 00:51:17 +0000

An attempt to clean up the text so far:

RELEVANT problem:
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.

H Anthony Chan

-----Original Message-----
From: Peter McCann 
Sent: Friday, May 18, 2012 9:35 AM
To: jouni korhonen; h chan
Cc: [email-masked]
Subject: RE: [DMM] draft requirement REQ-2: Transparency to Upper Layers

Hi, Jouni,

 

-Pete

---

From: Rajeev Koodli <[email-masked]>
Date: Tue, 22 May 2012 16:48:16 -0700

Hi Pete,

So, those are two requirements:

REQ-xx: Assess why MIP6 and derivatives could not be part of the DMM
solution.

REQ-yy: Assess how the MIP6 and derivative solutions could be dynamically
instantiated and subsequently revoked in DMM environments.

Could we please capture this?

Thanks.

-Rajeev