Re: [MEXT] Requirements of DMM

[h chan <[e-mail]>]

Rute,

You are welcome to join the DMM discussions and contribute to the work, especially as your research is so relevant to it. However, DMM has become part of MEXT so that the DMM discussions need to use the mext mailing list. 

If you have not subscribed to the mext mailing list, you can subscribe now and then you can send email directly to [e-mail] .

If you are not on the mext mailing list, I can forward to the mext so that the other mext members can see your comments. 

Here I take the liberty of copying one important point in your suggestion to the MEXT mailing list: 

Lack of user-centricity
The mobility anchor point, as the main element of a mobility management system, has been object of intensive studies in order to create more distributed and decentralized systems. Accordingly, its role, its functionalities and the location it should take in the network (e.g. router, server, etc) are not a consensus. Depending on the architecture, on the network characteristics and on the functionalities we have in the mobility anchor element, its location may vary, and its function in the whole system may change. Considering that user-centric networks present particular characteristics (e.g. there is no clear splitting between network elements and end-devices), the current centralized standards may not be suitable. Thus, a novel mobility management approach should be designed for such networks, considering all its particularities and following this trend of rethinking the mobility anchor point element.

These aspects reinforce the need for distributed and dynamic mobility mechanisms. Positioning the anchor-point in network elements closer to the end user provides the capability to have a more flexible mobility management service, with (potentially) more control in terms of users expectations; it also assists the access operation by lowering the operation complexity. For instance, traffic locality can be more easily achieved by having mobility management functionality deployed in elements that are closer to customer premises, or on the edges of the access network.

H Anthony Chan

>> ----- Original Message -----
>> From: "Rute Sofia"<[e-mail]> To:<[e-mail]>
>> Sent: Monday, July 04, 2011 6:41 AM
>> Subject: DMM, Mext relation and potential contribution to the draft 
>> on problem statement
>>
>>
>> Hello Anthony,
>>
>> we have been following some work concerning DMM in Mext.
>>
>> We have a project which focus on most of these aspects (UMM:
>> user-centric mobility management, 2009-2012, see 
>> http://siti.ulusofona.pt/~umm). It is focused not only on 
>> decentralization of mobility functionality but also on the potential 
>> decoupling. this is a Portuguese project, developed between two R&D
>> units: SITI, my unit (http://siti.ulusofona.pt) and the Instituto of 
>> Telecomunicações in Aveiro.
>> Some initial publications:
>>
>> http://siti.ulusofona.pt/aigaion/index.php/keywords/single/12
>> http://siti.ulusofona.pt/aigaion/index.php/publications/show/43
>>
>>
>> I have checked the problem statement draft
>> (draft-chan-distributed-mobility-ps-01) and would like to know if you 
>> are still open to input. We believe that there is valuable input to 
>> the current draft...
>>
>> Best Regards,
>> Rute Sofia
>>
>>
>
>
> --
> Rute Sofia, PhD ([e-mail]) Scientific Director for 
> Technology Research Unit in Informatics Systems and Technologies 
> (SITI) Coordinator of the Internet Architecture and Networking Lab 
> (IAN Lab) University Lusofona, Portugal [e-mail]
>
> http://siti.ulusofona.pt
> Tel.: [phone] Fax: [phone]
> .......................................................
>
>

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On Behalf Of h chan
Sent: Wednesday, October 26, 2011 1:22 PM
To: Seok-Joo Koh; mext
Subject: Re: [MEXT] Requirements of DMM

Seok-Joo,

I agree that the distinguishing feature of DMM needs to be clarified, but I don't know whether we can call that local MM.  
If the first part of the sentence is taken alone:
"The mobility management functions in interconnecting networks may be distributed over a number of smaller networks,"
One can possibly "disintegrate" into that in a number of smaller networks which support mobility independently. Then the MM in each network may or may not be local depending on which protocol is used. Yet if each network has its own HA using the host-based MIP, the range to which the MN can move is still global. 

The distinction of DMM is in the second part of the sentence:
"and the mobility anchor for a session in a mobile node may be moved from one network to another network to avoid unnecessarily long route as the node moves."

If seems that the problem of triangle route is of highest interest. I think Raj had emphasized on this problem in his draft. 

If we don't want limiting to "to avoid unnecessarily long route,"
we can add other things such as "to minimize traffic overhead."
But then there are other things it can achieve. 
An example is to enable the capability to better support mobility in the flat network by having a mobility anchor closer to the access network to which the MN is attached, (as pointed out in Sri's email)

An alternative is not to mention the advantage at all. 

The second part of the sentence will simply be
"and the mobility anchor for a session in a mobile node may be moved from one network to another network as the node moves."

The advantages can then be mentioned separately, but not part of the concise requirement statement. 

H Anthony Chan

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On Behalf Of Seok-Joo Koh
Sent: Monday, October 24, 2011 6:57 PM
To: mext
Subject: Re: [MEXT] Requirements of DMM

Anthony,

Good initiation for discussion.

As for the Distributed MM, it seems that some people are still confused with "Distributed MM" and 
"Local MM".
What is the difference between them ?
In the current sentence, it seems that the objective of DMM is "for route optimization"..
Does it include "minimization of the traffic overhead in the control and data plane ?

I think it is helpful to clarify the following issues..
- Terms (or definitions) of Distributed, Localized, Dynamic..
- Route optimization, minimization of traffic overhead, resource utilization,...

Regards,

*************************
Seok-Joo Koh
http://protocol.knu.ac.kr/
*************************

----- Original Message ----- 
From: "h chan" <[e-mail]>
To: "mext" <[e-mail]>
Sent: Tuesday, October 25, 2011 2:42 AM
Subject: [MEXT] Requirements of DMM


>
> There were discussions on the requirements of DMM in July.
>
> I think the email from Sri on the thread "LISP as a solution for some part of the DMM requirement" 
> (which is also attached below) has also elaborated the DMM requirements.
>
> Let me try to rephrase in the following:
>
>   1.  Distributed mobility requirement: The mobility management
>       functions in interconnecting networks may be distributed over a
>       number of smaller networks, and the mobility support for a
>       session in a mobile node may be moved from one network to another
>       network to avoid unnecessarily long route as the node moves.
>
>   2.  Dynamic mobility requirement: A network supporting a mix of
>       mobile nodes some of which may be stationary for extended time
>       while others may be actively mobile may optimize its resources to
>       avoid unnecessary mobility support.
>
> Comments please.
>
> H Anthony Chan
>
> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On Behalf Of Sri Gundavelli
> Sent: Monday, August 01, 2011 10:23 PM
> To: Seok-Joo Koh; Charles E. Perkins; mext
> Cc: [e-mail]
> Subject: Re: [MEXT] LISP as a solution for some part of the DMM requirement
>
> With respect to the solutions, there are multiple approaches that are on the
> table. To me, to achieve a flat distributed model, we need:
>
> - the ability to select a mobility anchor closer to the access network where
> the mobile node is attached. 3GPP Rel-10 has done quite a few enhancements
> on the aspects of gateway selection. Using the parameters eNB, APN, RNC-ID,
> BSC-ID, ...etc
>
> - the ability to re-anchor a session, or create a new session on a new
> anchor closer to the new attachment point
>
> - the ability to allow the mobile node to identify the assigned IP address
> properties, distinguish between an address assigned in the previous access
> network, from an address assigned in the current access network, so it can
> continue to use the new address for new sessions and phase out the older
> address/mobility session on the previous anchor over a period of time. In
> other words, enhancing the SAS rules with mobility awareness will give the
> needed session re-anchoring capabilities
>
> This approach gives me the gateway selection closer to the access network
> where the mobile node is attached and the needed optimized routing path. So,
> I'm trying to understand what are the expectation from the DMM efforts,
> beyond this.
>
>
> Sri
>
>
>
>
> On 8/1/11 8:13 PM, "Sri Gundavelli" <[e-mail]> wrote:
>
>> Hi Charlie,
>>
>> I agree, we have to look at other approaches and bring any value added
>> features to MIPv6/PMIPv6 protocols that its missing today. But, I've to say,
>> I'm still trying to understand the DMM problem statement and what DMM should
>> translate to:
>>
>> - Is it about optimized routing path ? This is very subjective and the
>> requirement may vary based on the use-case. Very much depends on the placement
>> of the anchor point. No solution on the table can ever solve this, unless we
>> assume the target site where the CN is located, or the ISP above is providing
>> some new location functions. This new location function, sure, can be a proxy
>> home agent at the global internet level too, for the argument sake, providing
>> direct path to the access network where the MN is currently attached. We also
>> have talked some time back on the Global HAHA, as an approach of session
>> re-anchoring.
>>
>> - Is it about moving from a centralized one box model to more distributed
>> zillion box model ? This sounds very promising on the paper. But, as we
>> discussed during the DMM BOF, rolling out a zillion pizza box type box anchors
>> sounds very cool. Sure, but we bring back ten-fold complexity in the form of
>> building distributed charging, Legal Intercept, DPI, Inline services,
>> hotlining, high-availability ...etc etc, which are now part of that one
>> central anchor box. It is to be noted, we have not seen a true distributed
>> service deployed in the internet today, other than DNS.  But, I agree, if this
>> about building a true internet, who the heck cares about all of these
>> functions, in the true spirit.
>>
>> Either way, I assumed any of the new solution will be bound by the following
>> parameters:
>>
>> - The signaling protocol will continue to be based on MIPv6/PMIPv6 signaling
>> semantics.
>>
>> - We will not introduce a new client, what is now MIP client struggling to
>> make it to every variants of operating systems.
>>
>> - Any client-based solution will be an extension on top of DSMIP. Any
>> network-based solution will be an extension to PMIPv6
>>
>>
>>
>> I hope we can discuss the solution approaches in the next meeting and bring
>> new extension to MIPv6/PMIPv6 protocols.
>>
>>
>>
>>
>> Regards
>> Sri
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> On 8/1/11 4:50 PM, "Seok-Joo Koh" <[e-mail]> wrote:
>>
>>> Dear Charles,
>>>
>>> I think the LISP can also be considered as a promising candidate
>>> in the design of DMM solutions. Several works are being progressed
>>> to use or extend the LISP for mobility support, which inlcude LISP-MN draft
>>> and many research papers. Actually, I am also considering how to extend
>>> the LISP scheme in the DMM perspective.
>>>
>>> LISP is a network-based ID-LOC separation scheme and thus it may give some
>>> advantages for effective mobility support. On the other hand, it is noted
>>> that
>>> the current version of LISP and LISP-MN may need to be more enhanced
>>> in terms of scalability in the mobile environment. For example, one concern
>>> of
>>> LISP
>>> is that the LISP EIDs may not be aggregated anymore in the mobile networks,
>>> since
>>> each mobile node will have its own distinctive EIDs that do not conform the
>>> concerned mobile domain.
>>> This may decrease the scaling benefits of original LISP.
>>> We may need to design a new enhanced EID structure to be used for mobile
>>> environment.
>>> Nontheless, it is worthwhile to consider LISP as a promisng candidate in the
>>> disign of DMM, I think.
>>>
>>> By the way, as I already said in this IETF DMM ad hoc meeting, the urgent
>>> action item of DMM is
>>> to make one or more introductory I-Ds with WG consensus, which may include
>>> the problem statements and requirements for DMM, use cases/scenarios, and
>>> comparison matrix, etc.
>>>
>>> Regards,
>>>
>>> *************************
>>> Seok-Joo Koh
>>> http://protocol.knu.ac.kr/
>>> *************************
>>>
>
> _______________________________________________
> MEXT mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mext
> _______________________________________________
> MEXT mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mext 

_______________________________________________
MEXT mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/mext
_______________________________________________
MEXT mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/mext