[MEXT] Requirements of DMM

h chan <h.anthony.chan@huawei.com> Mon, 24 October 2011 17:42 UTC

Return-Path: <h.anthony.chan@huawei.com>
X-Original-To: mext@ietfa.amsl.com
Delivered-To: mext@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6DCED11E80B7 for <mext@ietfa.amsl.com>; Mon, 24 Oct 2011 10:42:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level:
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JKRgVqkqgNPy for <mext@ietfa.amsl.com>; Mon, 24 Oct 2011 10:42:53 -0700 (PDT)
Received: from szxga04-in.huawei.com (szxga04-in.huawei.com [119.145.14.67]) by ietfa.amsl.com (Postfix) with ESMTP id 940CA11E80AA for <mext@ietf.org>; Mon, 24 Oct 2011 10:42:53 -0700 (PDT)
Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LTK00LF4ZVG41@szxga04-in.huawei.com> for mext@ietf.org; Tue, 25 Oct 2011 01:42:52 +0800 (CST)
Received: from szxrg01-dlp.huawei.com ([172.24.2.119]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LTK00ANNZVG5N@szxga04-in.huawei.com> for mext@ietf.org; Tue, 25 Oct 2011 01:42:52 +0800 (CST)
Received: from szxeml206-edg.china.huawei.com ([172.24.2.119]) by szxrg01-dlp.huawei.com (MOS 4.1.9-GA) with ESMTP id AEQ45935; Tue, 25 Oct 2011 01:42:52 +0800
Received: from SZXEML404-HUB.china.huawei.com (10.82.67.59) by szxeml206-edg.china.huawei.com (172.24.2.58) with Microsoft SMTP Server (TLS) id 14.1.270.1; Tue, 25 Oct 2011 01:42:50 +0800
Received: from SZXEML505-MBS.china.huawei.com ([169.254.2.127]) by szxeml404-hub.china.huawei.com ([::1]) with mapi id 14.01.0270.001; Tue, 25 Oct 2011 01:42:42 +0800
Date: Mon, 24 Oct 2011 17:42:41 +0000
From: h chan <h.anthony.chan@huawei.com>
In-reply-to: <CA5CBB8E.23279%sgundave@cisco.com>
X-Originating-IP: [10.192.11.138]
To: mext <mext@ietf.org>
Message-id: <6E31144C030982429702B11D6746B98C1927B7F1@SZXEML505-MBS.china.huawei.com>
MIME-version: 1.0
Content-type: text/plain; charset=us-ascii
Content-language: en-US
Content-transfer-encoding: 7BIT
Accept-Language: en-US, zh-CN
Thread-topic: Requirements of DMM
Thread-index: AcxQwhfLnuKfCPPY3k6t02z05yDwwQAAVYhPD+puflA=
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-cr-hashedpuzzle: PxA= Sc0= ARjJ Aew4 A+Th DC+E EhGq FNu3 GEl+ G7Lk HrwM H3+V Igoh IyfG JY/x JoB4; 1; bQBlAHgAdABAAGkAZQB0AGYALgBvAHIAZwA=; Sosha1_v1; 7; {A2338C7E-93FF-4475-9731-68F39DAE0EC9}; aAAuAGEAbgB0AGgAbwBuAHkALgBjAGgAYQBuAEAAaAB1AGEAdwBlAGkALgBjAG8AbQA=; Mon, 24 Oct 2011 17:42:37 GMT; UgBlAHEAdQBpAHIAZQBtAGUAbgB0AHMAIABvAGYAIABEAE0ATQA=
x-cr-puzzleid: {A2338C7E-93FF-4475-9731-68F39DAE0EC9}
X-CFilter-Loop: Reflected
References: <CA5CB950.23275%sgundave@cisco.com> <CA5CBB8E.23279%sgundave@cisco.com>
Subject: [MEXT] Requirements of DMM
X-BeenThere: mext@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Mobile IPv6 EXTensions WG <mext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mext>, <mailto:mext-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/mext>
List-Post: <mailto:mext@ietf.org>
List-Help: <mailto:mext-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mext>, <mailto:mext-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 24 Oct 2011 17:42:58 -0000

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: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] On Behalf Of Sri Gundavelli
Sent: Monday, August 01, 2011 10:23 PM
To: Seok-Joo Koh; Charles E. Perkins; mext
Cc: dino@cisco.com
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" <sgundave@cisco.com> 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" <sjkoh@knu.ac.kr> 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
MEXT@ietf.org
https://www.ietf.org/mailman/listinfo/mext