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

From: h chan <[email-masked]>
Date: Tue, 5 Jun 2012 17:12:46 +0000

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-masked] [mailto:[email-masked]] On Behalf Of h chan
Sent: Wednesday, May 23, 2012 7:51 PM
To: Peter McCann; jouni korhonen
Cc: [email-masked]
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-masked]
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-masked]
>> https://www.ietf.org/mailman/listinfo/dmm
> 
> _______________________________________________
> dmm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dmm

_______________________________________________
dmm mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dmm

---

From: "Charles E. Perkins" <[email-masked]>
Date: Tue, 05 Jun 2012 15:39:06 -0700

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

I think it should be possible for the user of a device to set which behavior
is to be considered the default behavior for all applications on that 
device.

This would leave open the possibility that, unless the user specifies 
otherwise,
the device would be configured to have "unstable" addressing as default.

-- 
Regards,
Charlie P.

---

From: [email-masked]
Date: Wed, 6 Jun 2012 13:55:53 +0800

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 the sentence？

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-masked]> 
发件人:  [email-masked]
2012/06/06 01:12

收件人
"[email-masked]" <[email-masked]>, Peter McCann <[email-masked]>, 
jouni korhonen <[email-masked]>
抄送

主题
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-masked] [mailto:[email-masked]] On Behalf Of h 
chan
Sent: Wednesday, May 23, 2012 7:51 PM
To: Peter McCann; jouni korhonen
Cc: [email-masked]
Subject: Re: [DMM] draft requirement REQ-2: Transparency to Upper Layers

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-masked]
Subject: RE: [DMM] draft requirement REQ-2: Transparency to Upper Layers

Hi, Jouni,

 

-Pete

---

From: h chan <[email-masked]>
Date: Wed, 6 Jun 2012 16:24:09 +0000

How about the following change:

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

-----Original Message-----
From: Charles E. Perkins [mailto:[email-masked]] 
Sent: Tuesday, June 05, 2012 5:39 PM
To: h chan
Cc: [email-masked]; Peter McCann; jouni korhonen
Subject: Re: [DMM] draft requirement REQ-2: Transparency to Upper Layers

-- 
Regards,
Charlie P.

---

From: h chan <[email-masked]>
Date: Wed, 6 Jun 2012 16:32:56 +0000

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:

H Anthony Chan

From: [email-masked] [mailto:[email-masked]]
Sent: Wednesday, June 06, 2012 12:56 AM
To: h chan
Cc: [email-masked]; [email-masked]; 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 the sentence？

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.

Thanks
Luowen

2012/06/06 01:12

收件人

"[email-masked]" <[email-masked]>, Peter McCann <[email-masked]>, jouni korhonen <[email-masked]>

抄送

主题

Revise as follows:

H Anthony Chan

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of h chan
Sent: Wednesday, May 23, 2012 7:51 PM
To: Peter McCann; jouni korhonen
Cc: [email-masked]
Subject: Re: [DMM] draft requirement REQ-2: Transparency to Upper Layers

RELEVANT problem:

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: [email-masked]
Date: Fri, 8 Jun 2012 09:40:08 +0800

Hi Anthony,

In my mind, the DMM shall provides transparency when needed. But I think, 
since the network can not know when will the mobile node need the 
transparency support, so it seems that the network should always get ready 
in advance for providing the transparency support. 

Anyway, I am OK with your new suggestion, since it is "MAY". This could 
leave space for people to develop some better solutions.

BR
Luowen

2012/06/07 00:32

收件人
"[email-masked]" <[email-masked]>
抄送
"[email-masked]" <[email-masked]>, "[email-masked]" 
<[email-masked]>, jouni korhonen <[email-masked]>, Peter 
McCann <[email-masked]>
主题
RE: Re: [DMM] draft requirement REQ-2: Transparency to Upper Layers

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-masked] [mailto:[email-masked]] 
Sent: Wednesday, June 06, 2012 12:56 AM
To: h chan
Cc: [email-masked]; [email-masked]; jouni korhonen; Peter McCann
Subject: 答复: Re: [DMM] draft requirement REQ-2: Transparency to Upper 
Layers

Hi Anthony: 

Thanks 
Luowen 

收件人

主题

Revise as follows:

H Anthony Chan

-----Original Message-----

RELEVANT problem:

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: Fri, 15 Jun 2012 02:21:04 +0000

Changed SHALL to MUST
Clean up text:
   REQ2:  Transparency to Upper Layers when needed

          The DMM solutions MUST provide transparency above the IP layer
          when needed.  Such transparency is needed, when the mobile
          hosts or entire mobile networks [RFC3963] 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.

          Motivation: The motivation 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.

   This requirement addresses the problems PS5 as well as the other
   related problem O-PS1.

         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.

           Wasting resources when mobility signaling (e.g., maintenance
           of the tunnel, keep alive, etc.) is not turned off for peer-
           to-peer communication.

H Anthony Chan

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of h chan
Sent: Wednesday, June 06, 2012 12:24 PM
To: Charles E. Perkins
Cc: Peter McCann; [email-masked]
Subject: Re: [DMM] draft requirement REQ-2: Transparency to Upper Layers

H Anthony Chan

-----Original Message-----
From: Charles E. Perkins [mailto:[email-masked]] 
Sent: Tuesday, June 05, 2012 5:39 PM
To: h chan
Cc: [email-masked]; Peter McCann; jouni korhonen
Subject: Re: [DMM] draft requirement REQ-2: Transparency to Upper Layers

-- 
Regards,
Charlie P.