From h.anthony.chan@huawei.com Mon May 7 10:57:33 2012 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DEC1621F8663 for ; Mon, 7 May 2012 10:57:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] 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 ewHqCfGBO2cO for ; Mon, 7 May 2012 10:57:32 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id 32E2221F865F for ; Mon, 7 May 2012 10:57:31 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml201-edg.china.huawei.com) ([172.18.9.243]) by dfwrg02-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AFP18855; Mon, 07 May 2012 13:57:28 -0400 (EDT) Received: from DFWEML407-HUB.china.huawei.com (10.193.5.132) by dfweml201-edg.china.huawei.com (172.18.9.107) with Microsoft SMTP Server (TLS) id 14.1.323.3; Mon, 7 May 2012 10:55:08 -0700 Received: from SZXEML405-HUB.china.huawei.com (10.82.67.60) by dfweml407-hub.china.huawei.com (10.193.5.132) with Microsoft SMTP Server (TLS) id 14.1.323.3; Mon, 7 May 2012 10:55:09 -0700 Received: from SZXEML505-MBS.china.huawei.com ([169.254.2.179]) by szxeml405-hub.china.huawei.com ([::1]) with mapi id 14.01.0323.003; Tue, 8 May 2012 01:55:02 +0800 From: h chan To: "dmm@ietf.org" Thread-Topic: draft requirement REQ-1: Distributed deployment Thread-Index: Ac0seoQMh5NibqhAQRi4w9Ayq3yCPg== Date: Mon, 7 May 2012 17:55:01 +0000 Message-ID: <6E31144C030982429702B11D6746B98C1DDFB507@SZXEML505-MBS.china.huawei.com> Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-cr-hashedpuzzle: wWI= AMx+ ARzw BnsC CAzy CFsh CpMX C4Cf EOs7 GoWj Gwah G+M0 IE8y I260 JJ9v JS8O; 1; ZABtAG0AQABpAGUAdABmAC4AbwByAGcA; Sosha1_v1; 7; {DD6208EC-B419-487C-94D4-6594AB4EEE7E}; aAAuAGEAbgB0AGgAbwBuAHkALgBjAGgAYQBuAEAAaAB1AGEAdwBlAGkALgBjAG8AbQA=; Mon, 07 May 2012 17:54:57 GMT; ZAByAGEAZgB0ACAAcgBlAHEAdQBpAHIAZQBtAGUAbgB0ACAAUgBFAFEALQAxADoAIABEAGkAcwB0AHIAaQBiAHUAdABlAGQAIABkAGUAcABsAG8AeQBtAGUAbgB0AA== x-cr-puzzleid: {DD6208EC-B419-487C-94D4-6594AB4EEE7E} x-originating-ip: [10.47.153.176] Content-Type: multipart/alternative; boundary="_000_6E31144C030982429702B11D6746B98C1DDFB507SZXEML505MBSchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: [DMM] draft requirement REQ-1: Distributed deployment X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 May 2012 17:57:33 -0000 --_000_6E31144C030982429702B11D6746B98C1DDFB507SZXEML505MBSchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable REQ-1: Distributed deployment IP mobility, network access and routing solutions provided by DMM SHALL ena= ble the functions of mobility management of IP sessions to be distributed s= o that the traffic is routed in an optimal manner without relying on centra= lly deployed anchors. REQ-1M (Motivation for REQ-1) The goals of this requirement are to match mobility deployment with current trend in network evolution: more cos= t and resource effective to cache and distribute contents when combining di= stributed anchors with caching systems (e.g., CDN); improve scalability; re= duce signaling overhead; avoid single point of failure; mitigate threats be= ing focused on a centrally deployed anchor, e.g., home agent and local mobi= lity anchor. RELEVANT problems: PS1: Non-optimal routes Routing via a centralized anchor often results in a longer route, and the p= roblem is especially manifested when accessing a local or cache server of a= Content Delivery Network (CDN). PS2: Non-optimality in Evolved Network Architecture The centralized mobility management can become non-optimal as Network archi= tecture evolves and become more flattened. PS3: Low scalability of centralized route and mobility context maintenance Setting up such special routes and maintaining the mobility context for eac= h MN is more difficult to scale in a centralized design with a large number= of MNs. Distributing the route maintenance function and the mobility conte= xt maintenance function among different networks can be more scalable. PS4: Single point of failure and attack Centralized anchoring may be more vulnerable to single point of failure and= attack than a distributed system. (The above is drafted with contributions, inputs and discussions from vario= us people. Additional contributions and comments are most welcome.) H Anthony Chan --_000_6E31144C030982429702B11D6746B98C1DDFB507SZXEML505MBSchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

REQ-1: Distributed deployment

IP mobility, network access and routing solutions pr= ovided by DMM SHALL enable the functions of mobility management of IP sessi= ons to be distributed so that the traffic is routed in an optimal manner wi= thout relying on centrally deployed anchors.

 

REQ-1M (Motivation for REQ-1)

The goals of this requirement are to

match mobility deployment with current trend in netw= ork evolution: more cost and resource effective to cache and distribute con= tents when combining distributed anchors with caching systems (e.g., CDN); = improve scalability; reduce signaling overhead; avoid single point of failure; mitigate threats being focused on= a centrally deployed anchor, e.g., home agent and local mobility anchor.

 

RELEVANT problems:

PS1: Non-optimal routes

Routing via a centralized anchor often results in a = longer route, and the problem is especially manifested when accessing a loc= al or cache server of a Content Delivery Network (CDN).

PS2: Non-optimality in Evolved Network Architecture<= o:p>

The centralized mobility management can become non-o= ptimal as Network architecture evolves and become more flattened.

PS3: Low scalability of centralized route and mobili= ty context maintenance

Setting up such special routes and maintaining the m= obility context for each MN is more difficult to scale in a centralized des= ign with a large number of MNs. Distributing the route maintenance function= and the mobility context maintenance function among different networks can be more scalable.

PS4: Single point of failure and attack <= /p>

Centralized anchoring may be more vulnerable to sing= le point of failure and attack than a distributed system.

 

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

 

H Anthony Chan

 

--_000_6E31144C030982429702B11D6746B98C1DDFB507SZXEML505MBSchi_-- From h.anthony.chan@huawei.com Mon May 7 11:00:27 2012 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F063A21F864E for ; Mon, 7 May 2012 11:00:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] 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 ex6N2YWlHYzk for ; Mon, 7 May 2012 11:00:22 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id 2843821F864D for ; Mon, 7 May 2012 11:00:22 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml201-edg.china.huawei.com) ([172.18.9.243]) by dfwrg02-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AFP19093; Mon, 07 May 2012 14:00:21 -0400 (EDT) Received: from DFWEML407-HUB.china.huawei.com (10.193.5.132) by dfweml201-edg.china.huawei.com (172.18.9.107) with Microsoft SMTP Server (TLS) id 14.1.323.3; Mon, 7 May 2012 10:58:07 -0700 Received: from SZXEML437-HUB.china.huawei.com (10.72.61.72) by dfweml407-hub.china.huawei.com (10.193.5.132) with Microsoft SMTP Server (TLS) id 14.1.323.3; Mon, 7 May 2012 10:58:08 -0700 Received: from SZXEML505-MBS.china.huawei.com ([169.254.2.179]) by szxeml437-hub.china.huawei.com ([10.72.61.72]) with mapi id 14.01.0323.003; Tue, 8 May 2012 01:58:03 +0800 From: h chan To: "dmm@ietf.org" Thread-Topic: draft requirement REQ-2: Transparency to Upper Layers Thread-Index: Ac0sevGTWjZR/F41RF+Fu7fOcGRYbQ== Date: Mon, 7 May 2012 17:58:02 +0000 Message-ID: <6E31144C030982429702B11D6746B98C1DDFB50C@SZXEML505-MBS.china.huawei.com> Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.153.176] Content-Type: multipart/alternative; boundary="_000_6E31144C030982429702B11D6746B98C1DDFB50CSZXEML505MBSchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: [DMM] draft requirement REQ-2: Transparency to Upper Layers X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 May 2012 18:00:27 -0000 --_000_6E31144C030982429702B11D6746B98C1DDFB50CSZXEML505MBSchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable REQ-2: Transparency to Upper Layers The DMM solutions SHALL enable transparency above the IP layer. Such transp= arency is needed for the application flows that cannot cope with a change o= f IP address and when mobile hosts or entire mobile networks change their p= oint 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 b= y 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 no= t change the point of attachment. In these situations that do not require I= P mobility support, network resources are wasted when mobility context is s= et 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 nee= ded. 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-centr= icity is to provide mobility support to all mobile nodes by default regardl= ess 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 --_000_6E31144C030982429702B11D6746B98C1DDFB50CSZXEML505MBSchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

REQ-2: Transparency= to Upper Layers

The DMM solutions S= HALL enable transparency above the IP layer. Such transparency is needed fo= r the application flows that cannot cope with a change of IP address and wh= en 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 m= ore efficient routing by not invoking mobility support when there is no suc= h need.

 

RELEVANT problem:

PS5: Wasting resour= ces to support mobile nodes not needing mobility support<= /p>

IP mobility support is not always required. For exam= ple, some applications do not need a stable IP address during handover, i.e= . IP session continuity. Sometimes, the entire application session runs whi= le the terminal does not change the point of attachment. In these situations that do not require IP mobility s= upport, network resources are wasted when mobility context is set up. Netwo= rk resources are also wasted when the via routes are set up for many MNs th= at 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 b= e reachable, the hosts may then communicate directly so that the mobility s= upport is no longer needed. Taking the need of mobility support as the defa= ult behavior will waste network resources.

O-PS2: Lack of user-centricity

Centralized deployment compared with distributed mob= ility management may be less capable to support user-centricity. Example in= the lack of user-centricity is to provide mobility support to all mobile n= odes by default regardless of whether the user needs it or not.

 

(The above has been drafted with contributions, inpu= ts and discussions from various people. Additional contributions and commen= ts are most welcome.)

 

H Anthony Chan

 

--_000_6E31144C030982429702B11D6746B98C1DDFB50CSZXEML505MBSchi_-- From h.anthony.chan@huawei.com Mon May 7 11:02:38 2012 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 320F421F866B for ; Mon, 7 May 2012 11:02:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] 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 T1dg8iXfNbxr for ; Mon, 7 May 2012 11:02:37 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id 81B7A21F865F for ; Mon, 7 May 2012 11:02:37 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml201-edg.china.huawei.com) ([172.18.9.243]) by dfwrg02-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AFP19205; Mon, 07 May 2012 14:02:37 -0400 (EDT) Received: from DFWEML404-HUB.china.huawei.com (10.193.5.203) by dfweml201-edg.china.huawei.com (172.18.9.107) with Microsoft SMTP Server (TLS) id 14.1.323.3; Mon, 7 May 2012 11:00:04 -0700 Received: from SZXEML426-HUB.china.huawei.com (10.72.61.34) by dfweml404-hub.china.huawei.com (10.193.5.203) with Microsoft SMTP Server (TLS) id 14.1.323.3; Mon, 7 May 2012 11:00:05 -0700 Received: from SZXEML505-MBS.china.huawei.com ([169.254.2.179]) by szxeml426-hub.china.huawei.com ([10.72.61.34]) with mapi id 14.01.0323.003; Tue, 8 May 2012 02:00:01 +0800 From: h chan To: "dmm@ietf.org" Thread-Topic: draft requirement REQ3: IPv6 deployment Thread-Index: Ac0seoQMh5NibqhAQRi4w9Ayq3yCPgAAIPzQ Date: Mon, 7 May 2012 18:00:01 +0000 Message-ID: <6E31144C030982429702B11D6746B98C1DDFB511@SZXEML505-MBS.china.huawei.com> Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.153.176] Content-Type: multipart/alternative; boundary="_000_6E31144C030982429702B11D6746B98C1DDFB511SZXEML505MBSchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: [DMM] draft requirement REQ3: IPv6 deployment X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 May 2012 18:02:38 -0000 --_000_6E31144C030982429702B11D6746B98C1DDFB511SZXEML505MBSchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable REQ3: IPv6 deployment The DMM solutions SHOULD target IPv6 as primary deployment and SHOULD NOT b= e tailored specifically to support IPv4, in particular in situations where = private IPv4 addresses and/or NATs are used. REQ-3M (Motivation for REQ-3): The motivation for this requirement is to be inline with general orientation of the IETF. Moreover, DMM deployment is fo= reseen in mid-term/long-term; hopefully in an IPv6 world. It is also unnece= ssarily complex to solve this problem for IPv4, as we will not be able to u= se some of the IPv6-specific features/tools. (The above has been drafted with contributions, inputs and discussions from= various people. Additional contributions and comments are most welcome.) H Anthony Chan --_000_6E31144C030982429702B11D6746B98C1DDFB511SZXEML505MBSchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

REQ3: IPv6 deployment

The DMM solutions SHOULD target IPv6 as primary depl= oyment and SHOULD NOT be tailored specifically to support IPv4, in particul= ar in situations where private IPv4 addresses and/or NATs are used.

 

REQ-3M (Motivation for REQ-3):

The motivation for this requirement is to be

inline with general orientation of the IETF. Moreove= r, DMM deployment is foreseen in mid-term/long-term; hopefully in an IPv6 w= orld. It is also unnecessarily complex to solve this problem for IPv4, as w= e will not be able to use some of the IPv6-specific features/tools.

 

 

(The above has<= span style=3D"color:#1F497D"> been drafted with contributions, input= s and discussions from various people. Additional contributions and comment= s are most welcome.)

 

H Anthony Chan

 

--_000_6E31144C030982429702B11D6746B98C1DDFB511SZXEML505MBSchi_-- From Basavaraj.Patil@nokia.com Mon May 7 11:02:43 2012 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9815321F867A for ; Mon, 7 May 2012 11:02:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.565 X-Spam-Level: X-Spam-Status: No, score=-106.565 tagged_above=-999 required=5 tests=[AWL=0.033, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] 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 hfsMqGcwoHCH for ; Mon, 7 May 2012 11:02:42 -0700 (PDT) Received: from mgw-da02.nokia.com (smtp.nokia.com [147.243.128.26]) by ietfa.amsl.com (Postfix) with ESMTP id 50A7721F8672 for ; Mon, 7 May 2012 11:02:42 -0700 (PDT) Received: from vaebh106.NOE.Nokia.com (vaebh106.europe.nokia.com [10.160.244.32]) by mgw-da02.nokia.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q47I21g3005576; Mon, 7 May 2012 21:02:35 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.56]) by vaebh106.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Mon, 7 May 2012 21:02:13 +0300 Received: from 008-AM1MPN1-073.mgdnok.nokia.com ([169.254.3.103]) by 008-AM1MMR1-001.mgdnok.nokia.com ([65.54.30.56]) with mapi id 14.02.0283.004; Mon, 7 May 2012 20:02:12 +0200 From: To: , Thread-Topic: [DMM] draft requirement REQ-1: Distributed deployment Thread-Index: Ac0seoQMh5NibqhAQRi4w9Ayq3yCPv//jMOA Date: Mon, 7 May 2012 18:02:11 +0000 Message-ID: In-Reply-To: <6E31144C030982429702B11D6746B98C1DDFB507@SZXEML505-MBS.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.1.120420 x-originating-ip: [172.19.59.10] Content-Type: multipart/alternative; boundary="_000_CBCD77D01E1AEbasavarajpatilnokiacom_" MIME-Version: 1.0 X-OriginalArrivalTime: 07 May 2012 18:02:13.0077 (UTC) FILETIME=[87930050:01CD2C7B] X-Nokia-AV: Clean Subject: Re: [DMM] draft requirement REQ-1: Distributed deployment X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 May 2012 18:02:43 -0000 --_000_CBCD77D01E1AEbasavarajpatilnokiacom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Anthony, When you refer to " the functions of mobility management " do you implicitl= y assume that to be the Home Agent? Or is there an assumption that there could be new elements as well to enabl= e such distributed mobility? One of the underlying aspects of DMM (AFAICT) is to use Mobile IPv6. And he= nce the question above. -Raj From: ext chan = > Date: Monday, May 7, 2012 12:55 PM To: "dmm@ietf.org" > Subject: [DMM] draft requirement REQ-1: Distributed deployment REQ-1: Distributed deployment IP mobility, network access and routing solutions provided by DMM SHALL ena= ble the functions of mobility management of IP sessions to be distributed s= o that the traffic is routed in an optimal manner without relying on centra= lly deployed anchors. REQ-1M (Motivation for REQ-1) The goals of this requirement are to match mobility deployment with current trend in network evolution: more cos= t and resource effective to cache and distribute contents when combining di= stributed anchors with caching systems (e.g., CDN); improve scalability; re= duce signaling overhead; avoid single point of failure; mitigate threats be= ing focused on a centrally deployed anchor, e.g., home agent and local mobi= lity anchor. RELEVANT problems: PS1: Non-optimal routes Routing via a centralized anchor often results in a longer route, and the p= roblem is especially manifested when accessing a local or cache server of a= Content Delivery Network (CDN). PS2: Non-optimality in Evolved Network Architecture The centralized mobility management can become non-optimal as Network archi= tecture evolves and become more flattened. PS3: Low scalability of centralized route and mobility context maintenance Setting up such special routes and maintaining the mobility context for eac= h MN is more difficult to scale in a centralized design with a large number= of MNs. Distributing the route maintenance function and the mobility conte= xt maintenance function among different networks can be more scalable. PS4: Single point of failure and attack Centralized anchoring may be more vulnerable to single point of failure and= attack than a distributed system. (The above is drafted with contributions, inputs and discussions from vario= us people. Additional contributions and comments are most welcome.) H Anthony Chan --_000_CBCD77D01E1AEbasavarajpatilnokiacom_ Content-Type: text/html; charset="us-ascii" Content-ID: <198CA745E3198844B4F07EAD419DC783@mgd.nokia.com> Content-Transfer-Encoding: quoted-printable

Hi Anthony,

When you refer to " the functions of mobility = management " do you implicitly assume that to be the Home Agent? =
Or is there an assumption that there could be new elemen= ts as well to enable such distributed mobility?

One of the= underlying aspects of DMM (AFAICT) is to use Mobile IPv6. And hence the qu= estion above.

-Raj

From: ext chan <h.anthony.chan@huawei.com>
Date: Monday, May 7, 2012 12:55 PM<= br> To: "dmm@ietf.org" <dmm@ietf.= org>
Subject: [DMM] draft requirement RE= Q-1: Distributed deployment

REQ-1: Distributed deployment

IP mobility, network access and routing solutions pr= ovided by DMM SHALL enable the functions of mobility management of IP sessi= ons to be distributed so that the traffic is routed in an optimal manner wi= thout relying on centrally deployed anchors.

 

REQ-1M (Motivation for REQ-1)

The goals of this requirement are to

match mobility deployment with current trend in netw= ork evolution: more cost and resource effective to cache and distribute con= tents when combining distributed anchors with caching systems (e.g., CDN); = improve scalability; reduce signaling overhead; avoid single point of failure; mitigate threats being focused on= a centrally deployed anchor, e.g., home agent and local mobility anchor.

 

RELEVANT problems:

PS1: Non-optimal routes

Routing via a centralized anchor often results in a = longer route, and the problem is especially manifested when accessing a loc= al or cache server of a Content Delivery Network (CDN).

PS2: Non-optimality in Evolved Network Architecture<= o:p>

The centralized mobility management can become non-o= ptimal as Network architecture evolves and become more flattened.

PS3: Low scalability of centralized route and mobili= ty context maintenance

Setting up such special routes and maintaining the m= obility context for each MN is more difficult to scale in a centralized des= ign with a large number of MNs. Distributing the route maintenance function= and the mobility context maintenance function among different networks can be more scalable.

PS4: Single point of failure and attack <= /p>

Centralized anchoring may be more vulnerable to sing= le point of failure and attack than a distributed system.

 

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

 

H Anthony Chan

 

 --_000_CBCD77D01E1AEbasavarajpatilnokiacom_-- From h.anthony.chan@huawei.com Mon May 7 11:05:54 2012 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4CDEA21F8682 for ; Mon, 7 May 2012 11:05:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001] 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 Hy5Vyw+yusE7 for ; Mon, 7 May 2012 11:05:53 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id 5A83E21F8685 for ; Mon, 7 May 2012 11:05:51 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml202-edg.china.huawei.com) ([172.18.9.243]) by dfwrg02-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AFP19432; Mon, 07 May 2012 14:05:51 -0400 (EDT) Received: from DFWEML405-HUB.china.huawei.com (10.193.5.102) by dfweml202-edg.china.huawei.com (172.18.9.108) with Microsoft SMTP Server (TLS) id 14.1.323.3; Mon, 7 May 2012 11:04:08 -0700 Received: from SZXEML414-HUB.china.huawei.com (10.82.67.153) by dfweml405-hub.china.huawei.com (10.193.5.102) with Microsoft SMTP Server (TLS) id 14.1.323.3; Mon, 7 May 2012 11:04:07 -0700 Received: from SZXEML505-MBS.china.huawei.com ([169.254.2.179]) by SZXEML414-HUB.china.huawei.com ([10.82.67.153]) with mapi id 14.01.0323.003; Tue, 8 May 2012 02:04:04 +0800 From: h chan To: "dmm@ietf.org" Thread-Topic: draft requirement REQ-4: compatibility Thread-Index: Ac0sevGTWjZR/F41RF+Fu7fOcGRYbQAAE8fA Date: Mon, 7 May 2012 18:04:04 +0000 Message-ID: <6E31144C030982429702B11D6746B98C1DDFB532@SZXEML505-MBS.china.huawei.com> Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.153.176] Content-Type: multipart/alternative; boundary="_000_6E31144C030982429702B11D6746B98C1DDFB532SZXEML505MBSchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: [DMM] draft requirement REQ-4: compatibility X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 May 2012 18:05:54 -0000 --_000_6E31144C030982429702B11D6746B98C1DDFB532SZXEML505MBSchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable REQ-4: compatibility The DMM solutions SHALL support existing network deployment with IPv6 (e.g.= existing IPv6 address assignment), be compatible with other mobility proto= cols, and be interoperable with the network or the mobile hosts/routers tha= t do not support the DMM enabling protocol so that the existing network dep= loyments are unaffected. REQ-4M (Motivation for REQ-4) Motivation: The motivation of this requirement is to be able to work with n= etwork architectures of both hierarchical networks and flattened networks, = so that the mobility management protocol possesses enough flexibility to su= pport different networks, and so that the existing networks and hosts are n= ot affected and do not break. OTHER related problem O-PS3: Complicated deployment with too many variants and extensions of MIP Deployment is complicated with many variants and extensions of MIP. When in= troducing new functions which may add to the complicity, existing solutions= are more vulnerable to break. (The above has been drafted with contributions, inputs and discussions from= various people. Additional contributions and comments are most welcome.) H Anthony Chan --_000_6E31144C030982429702B11D6746B98C1DDFB532SZXEML505MBSchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

REQ-4: compatibility

The DMM solutions SHALL support existing network dep= loyment with IPv6 (e.g. existing IPv6 address assignment), be compatible wi= th other mobility protocols, and be interoperable with the network or the m= obile hosts/routers that do not support the DMM enabling protocol so that the existing network deployments are una= ffected.

 

REQ-4M (Motivation for REQ-4)

Motivation: The motivation of this requirement is to= be able to work with network architectures of both hierarchical networks a= nd flattened networks, so that the mobility management protocol possesses e= nough flexibility to support different networks, and so that the existing networks and hosts are not affected and= do not break.

 

OTHER related problem

O-PS3: Complicated deployment with too many variants= and extensions of MIP

Deployment is complicated with many variants and ext= ensions of MIP. When introducing new functions which may add to the complic= ity, existing solutions are more vulnerable to break.

 

(The above has been drafted with contributions, inpu= ts and discussions from various people. Additional contributions and commen= ts are most welcome.)

 

H Anthony Chan

 

--_000_6E31144C030982429702B11D6746B98C1DDFB532SZXEML505MBSchi_-- From h.anthony.chan@huawei.com Mon May 7 11:13:29 2012 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CBB2021F86A1 for ; Mon, 7 May 2012 11:13:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] 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 eSRIBLbKx1Sg for ; Mon, 7 May 2012 11:13:28 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id A186621F869F for ; Mon, 7 May 2012 11:13:27 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml202-edg.china.huawei.com) ([172.18.9.243]) by dfwrg02-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AFP19913; Mon, 07 May 2012 14:13:27 -0400 (EDT) Received: from DFWEML408-HUB.china.huawei.com (10.193.5.134) by dfweml202-edg.china.huawei.com (172.18.9.108) with Microsoft SMTP Server (TLS) id 14.1.323.3; Mon, 7 May 2012 11:11:41 -0700 Received: from SZXEML405-HUB.china.huawei.com (10.82.67.60) by dfweml408-hub.china.huawei.com (10.193.5.134) with Microsoft SMTP Server (TLS) id 14.1.323.3; Mon, 7 May 2012 11:11:40 -0700 Received: from SZXEML505-MBS.china.huawei.com ([169.254.2.179]) by szxeml405-hub.china.huawei.com ([::1]) with mapi id 14.01.0323.003; Tue, 8 May 2012 02:11:38 +0800 From: h chan To: "dmm@ietf.org" Thread-Topic: draft requirement REQ-5: Mobile IP based Thread-Index: Ac0sevGTWjZR/F41RF+Fu7fOcGRYbQAAcoUg Date: Mon, 7 May 2012 18:11:37 +0000 Message-ID: <6E31144C030982429702B11D6746B98C1DDFB537@SZXEML505-MBS.china.huawei.com> Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.153.176] Content-Type: multipart/alternative; boundary="_000_6E31144C030982429702B11D6746B98C1DDFB537SZXEML505MBSchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: [DMM] draft requirement REQ-5: Mobile IP based X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 May 2012 18:13:29 -0000 --_000_6E31144C030982429702B11D6746B98C1DDFB537SZXEML505MBSchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable REQ-5: Mobile IP based The DMM solutions based on existing host- or network-based mobility protoco= ls, such as Mobile IPv6 [RFC6275, 5555], Proxy Mobile IPv6 [RFC5213, 5844] = and NEMO [RFC3963], SHOULD be preferred, unless they fail to meet any of th= e other requirements. REQ-5M (Motivation for REQ-5) The motivation is to reuse the existing protocol first before considering n= ew protocols. (The above has been drafted with contributions, inputs and discussions from= various people. Additional contributions and comments are most welcome.) H Anthony Chan --_000_6E31144C030982429702B11D6746B98C1DDFB537SZXEML505MBSchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

REQ-5: Mobile IP based=

The DMM solutions base= d on existing host- or network-based mobility protocols, such as Mobile IPv= 6 [RFC6275, 5555], Proxy Mobile IPv6 [RFC5213, 5844] and NEMO [RFC3963], SH= OULD be preferred, unless they fail to meet any of the other requirements.

REQ-5M (Motivation for= REQ-5)

The motivation is to r= euse the existing protocol first before considering new protocols.

 

(The above has been drafted with contributions, inpu= ts and discussions from various people. Additional contributions and commen= ts are most welcome.)

 

H Anthony Chan

 

--_000_6E31144C030982429702B11D6746B98C1DDFB537SZXEML505MBSchi_-- From h.anthony.chan@huawei.com Mon May 7 11:16:46 2012 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 83F2621F86B1 for ; Mon, 7 May 2012 11:16:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] 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 RXxcXV7bvq73 for ; Mon, 7 May 2012 11:16:45 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id A359F21F86B0 for ; Mon, 7 May 2012 11:16:45 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml202-edg.china.huawei.com) ([172.18.9.243]) by dfwrg02-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AFP20146; Mon, 07 May 2012 14:16:45 -0400 (EDT) Received: from DFWEML407-HUB.china.huawei.com (10.193.5.132) by dfweml202-edg.china.huawei.com (172.18.9.108) with Microsoft SMTP Server (TLS) id 14.1.323.3; Mon, 7 May 2012 11:14:38 -0700 Received: from SZXEML433-HUB.china.huawei.com (10.72.61.61) by dfweml407-hub.china.huawei.com (10.193.5.132) with Microsoft SMTP Server (TLS) id 14.1.323.3; Mon, 7 May 2012 11:14:34 -0700 Received: from SZXEML505-MBS.china.huawei.com ([169.254.2.179]) by szxeml433-hub.china.huawei.com ([10.72.61.61]) with mapi id 14.01.0323.003; Tue, 8 May 2012 02:14:31 +0800 From: h chan To: "dmm@ietf.org" Thread-Topic: draft requirement REQ-6: authentication and authorization Thread-Index: Ac0sevGTWjZR/F41RF+Fu7fOcGRYbQAAecHQ Date: Mon, 7 May 2012 18:14:31 +0000 Message-ID: <6E31144C030982429702B11D6746B98C1DDFB53C@SZXEML505-MBS.china.huawei.com> Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.153.176] Content-Type: multipart/alternative; boundary="_000_6E31144C030982429702B11D6746B98C1DDFB53CSZXEML505MBSchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: [DMM] draft requirement REQ-6: authentication and authorization X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 May 2012 18:16:46 -0000 --_000_6E31144C030982429702B11D6746B98C1DDFB53CSZXEML505MBSchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable REQ-6: Mutual authentication and authorization to access to the DMM service= . The protocol solutions for DMM SHALL rely on mutual authentication and auth= orization mechanisms that allow a legitimate mobile host/router to access t= o the DMM service. REQ-6M (Motivation and problem statement) Mutual authentication and authorization between a mobile host/router and an= access router providing the DMM service to the mobile host/router are requ= ired to prevent potential attacks in the access network of the DMM service.= Otherwise, various attacks such as impersonation, denial of service, man-i= n-the-middle attacks, etc are present to obtain illegitimate access or to c= ollapse the DMM service. (The above has been drafted with contributions, inputs and discussions from= various people. Additional contributions and comments are most welcome.) H Anthony Chan --_000_6E31144C030982429702B11D6746B98C1DDFB53CSZXEML505MBSchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

REQ-6: Mutual authentication and authorization to ac= cess to the DMM service.

The protocol solutions for DMM SHALL rely on mutual = authentication and authorization mechanisms that allow a legitimate mobile = host/router to access to the DMM service.

 

REQ-6M (Motivation and problem statement)=

Mutual authentication and authorization between a mo= bile host/router and an access router providing the DMM service to the mobi= le host/router are required to prevent potential attacks in the access netw= ork of the DMM service. Otherwise, various attacks such as impersonation, denial of service, man-in-the-middl= e attacks, etc are present to obtain illegitimate access or to collapse the= DMM service.

 

(The above has been drafted with contributions, inpu= ts and discussions from various people. Additional contributions and commen= ts are most welcome.)

 

H Anthony Chan

 

--_000_6E31144C030982429702B11D6746B98C1DDFB53CSZXEML505MBSchi_-- From h.anthony.chan@huawei.com Mon May 7 11:17:49 2012 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 723C721F86C1 for ; Mon, 7 May 2012 11:17:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] 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 LFDjWWnh-tfN for ; Mon, 7 May 2012 11:17:48 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id 691E621F8671 for ; Mon, 7 May 2012 11:17:48 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml201-edg.china.huawei.com) ([172.18.9.243]) by dfwrg02-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AFP20217; Mon, 07 May 2012 14:17:48 -0400 (EDT) Received: from DFWEML407-HUB.china.huawei.com (10.193.5.132) by dfweml201-edg.china.huawei.com (172.18.9.107) with Microsoft SMTP Server (TLS) id 14.1.323.3; Mon, 7 May 2012 11:15:46 -0700 Received: from SZXEML425-HUB.china.huawei.com (10.72.61.33) by dfweml407-hub.china.huawei.com (10.193.5.132) with Microsoft SMTP Server (TLS) id 14.1.323.3; Mon, 7 May 2012 11:15:47 -0700 Received: from SZXEML505-MBS.china.huawei.com ([169.254.2.179]) by szxeml425-hub.china.huawei.com ([10.72.61.33]) with mapi id 14.01.0323.003; Tue, 8 May 2012 02:15:44 +0800 From: h chan To: "dmm@ietf.org" Thread-Topic: draft requirement REQ-7: Signaling message protection Thread-Index: Ac0sevGTWjZR/F41RF+Fu7fOcGRYbQAAlOew Date: Mon, 7 May 2012 18:15:44 +0000 Message-ID: <6E31144C030982429702B11D6746B98C1DDFB541@SZXEML505-MBS.china.huawei.com> Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.153.176] Content-Type: multipart/alternative; boundary="_000_6E31144C030982429702B11D6746B98C1DDFB541SZXEML505MBSchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: [DMM] draft requirement REQ-7: Signaling message protection X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 May 2012 18:17:49 -0000 --_000_6E31144C030982429702B11D6746B98C1DDFB541SZXEML505MBSchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable REQ-7: Signaling message protection Signaling messages of the protocol solutions for DMM SHALL be protected in = terms of authentication, data integrity, and data confidentiality. Data con= fidentiality to signaling messages SHALL be opt-in or opt-out depending on = network environments or user requirements. REQ-7M (Motivation and problem statement) Signaling messages are subject to various attacks since those messages carr= y context of a mobile host/router. For instance, a malicious node can forge= and send a number of signaling messages to redirect traffic to a specific = node. The result of such an attack is both the specific node becomes under = a denial of service attack and other nodes do not receive their traffic. As= signaling messages travel over the Internet, the end-to-end security is re= quired. (The above has been drafted with contributions, inputs and discussions from= various people. Additional contributions and comments are most welcome.) H Anthony Chan --_000_6E31144C030982429702B11D6746B98C1DDFB541SZXEML505MBSchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

REQ-7: Signaling message protection

Signaling messages of the protocol solutions for DMM= SHALL be protected in terms of authentication, data integrity, and data co= nfidentiality. Data confidentiality to signaling messages SHALL be opt-in o= r opt-out depending on network environments or user requirements.

 

REQ-7M (Motivation and problem statement)=

Signaling messages are subject to various attacks si= nce those messages carry context of a mobile host/router. For instance, a m= alicious node can forge and send a number of signaling messages to redirect= traffic to a specific node. The result of such an attack is both the specific node becomes under a denial of serv= ice attack and other nodes do not receive their traffic. As signaling messa= ges travel over the Internet, the end-to-end security is required.

 

 

(The above has been drafted with contributions, inpu= ts and discussions from various people. Additional contributions and commen= ts are most welcome.)

 

H Anthony Chan

 

--_000_6E31144C030982429702B11D6746B98C1DDFB541SZXEML505MBSchi_-- From h.anthony.chan@huawei.com Mon May 7 14:26:21 2012 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4BCA921F86F8 for ; Mon, 7 May 2012 14:26:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] 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 XSF99rm56v3g for ; Mon, 7 May 2012 14:26:20 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id 35C2421F869D for ; Mon, 7 May 2012 14:26:20 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml202-edg.china.huawei.com) ([172.18.9.243]) by dfwrg02-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AFP31149; Mon, 07 May 2012 17:26:20 -0400 (EDT) Received: from DFWEML403-HUB.china.huawei.com (10.193.5.151) by dfweml202-edg.china.huawei.com (172.18.9.108) with Microsoft SMTP Server (TLS) id 14.1.323.3; Mon, 7 May 2012 14:25:07 -0700 Received: from SZXEML403-HUB.china.huawei.com (10.82.67.35) by dfweml403-hub.china.huawei.com (10.193.5.151) with Microsoft SMTP Server (TLS) id 14.1.323.3; Mon, 7 May 2012 14:25:06 -0700 Received: from SZXEML505-MBS.china.huawei.com ([169.254.2.179]) by szxeml403-hub.china.huawei.com ([::1]) with mapi id 14.01.0323.003; Tue, 8 May 2012 05:25:01 +0800 From: h chan To: "Basavaraj.Patil@nokia.com" , "dmm@ietf.org" Thread-Topic: [DMM] draft requirement REQ-1: Distributed deployment Thread-Index: Ac0seoQMh5NibqhAQRi4w9Ayq3yCPv//jMOA//9Tn7A= Date: Mon, 7 May 2012 21:25:01 +0000 Message-ID: <6E31144C030982429702B11D6746B98C1DDFB582@SZXEML505-MBS.china.huawei.com> References: <6E31144C030982429702B11D6746B98C1DDFB507@SZXEML505-MBS.china.huawei.com> In-Reply-To: Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.156.152] Content-Type: multipart/alternative; boundary="_000_6E31144C030982429702B11D6746B98C1DDFB582SZXEML505MBSchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: Re: [DMM] draft requirement REQ-1: Distributed deployment X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 May 2012 21:26:21 -0000 --_000_6E31144C030982429702B11D6746B98C1DDFB582SZXEML505MBSchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Raj, Although many of the proposed solutions are based on Mobile IPv6, I think i= t is not the intension in the requirement REQ-1 to imply which functions ar= e to be defined or distributed. If it sounds so, we should reword it. H Anthony Chan From: Basavaraj.Patil@nokia.com [mailto:Basavaraj.Patil@nokia.com] Sent: Monday, May 07, 2012 1:02 PM To: h chan; dmm@ietf.org Subject: Re: [DMM] draft requirement REQ-1: Distributed deployment Hi Anthony, When you refer to " the functions of mobility management " do you implicitl= y assume that to be the Home Agent? Or is there an assumption that there could be new elements as well to enabl= e such distributed mobility? One of the underlying aspects of DMM (AFAICT) is to use Mobile IPv6. And he= nce the question above. -Raj From: ext chan = > Date: Monday, May 7, 2012 12:55 PM To: "dmm@ietf.org" > Subject: [DMM] draft requirement REQ-1: Distributed deployment REQ-1: Distributed deployment IP mobility, network access and routing solutions provided by DMM SHALL ena= ble the functions of mobility management of IP sessions to be distributed s= o that the traffic is routed in an optimal manner without relying on centra= lly deployed anchors. REQ-1M (Motivation for REQ-1) The goals of this requirement are to match mobility deployment with current trend in network evolution: more cos= t and resource effective to cache and distribute contents when combining di= stributed anchors with caching systems (e.g., CDN); improve scalability; re= duce signaling overhead; avoid single point of failure; mitigate threats be= ing focused on a centrally deployed anchor, e.g., home agent and local mobi= lity anchor. RELEVANT problems: PS1: Non-optimal routes Routing via a centralized anchor often results in a longer route, and the p= roblem is especially manifested when accessing a local or cache server of a= Content Delivery Network (CDN). PS2: Non-optimality in Evolved Network Architecture The centralized mobility management can become non-optimal as Network archi= tecture evolves and become more flattened. PS3: Low scalability of centralized route and mobility context maintenance Setting up such special routes and maintaining the mobility context for eac= h MN is more difficult to scale in a centralized design with a large number= of MNs. Distributing the route maintenance function and the mobility conte= xt maintenance function among different networks can be more scalable. PS4: Single point of failure and attack Centralized anchoring may be more vulnerable to single point of failure and= attack than a distributed system. (The above is drafted with contributions, inputs and discussions from vario= us people. Additional contributions and comments are most welcome.) H Anthony Chan --_000_6E31144C030982429702B11D6746B98C1DDFB582SZXEML505MBSchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Raj,=

 

Although many of the p= roposed solutions are based on Mobile IPv6, I think it is not the intension= in the requirement REQ-1 to imply which functions are to be defined or dis= tributed. If it sounds so, we should reword it.

 

H Anthony Chan

 

From: Basavara= j.Patil@nokia.com [mailto:Basavaraj.Patil@nokia.com]
Sent: Monday, May 07, 2012 1:02 PM
To: h chan; dmm@ietf.org
Subject: Re: [DMM] draft requirement REQ-1: Distributed deployment

 

&nb= sp;

Hi Antho= ny,

&nb= sp;

When you= refer to " the functions of mobility management " = do you implicitly assume that to be the Home Agent? 

Or is there an assumption that there could be new = elements as well to enable such distributed mobility?

&nb= sp;

One of the underlying aspects of DMM (AFAICT) is t= o use Mobile IPv6. And hence the question above.

 =

-Raj

&nb= sp;

From: ext chan <h.anthony.chan@huawei.com>
Date: Monday, May 7, 2012 12:55 PM
To: "dmm@ietf.org" <= ;dmm@ietf.org>
Subject: [DMM] draft requirement REQ-1: Distributed deployment<= /o:p>

&nb= sp;

REQ-1: Distributed deplo= yment

IP mobility, network acc= ess and routing solutions provided by DMM SHALL enable the functions of mob= ility management of IP sessions to be distributed so that the traffic is ro= uted in an optimal manner without relying on centrally deployed anchors.

 =

REQ-1M (Motivation for R= EQ-1)

The goals of this requir= ement are to

match mobility deploymen= t with current trend in network evolution: more cost and resource effective= to cache and distribute contents when combining distributed anchors with c= aching systems (e.g., CDN); improve scalability; reduce signaling overhead; avoid single point of failure; mit= igate threats being focused on a centrally deployed anchor, e.g., home agen= t and local mobility anchor.

 =

RELEVANT problems:<= /o:p>

PS1: Non-optimal routes<= o:p>

Routing via a centralize= d anchor often results in a longer route, and the problem is especially man= ifested when accessing a local or cache server of a Content Delivery Networ= k (CDN).

PS2: Non-optimality in E= volved Network Architecture

The centralized mobility= management can become non-optimal as Network architecture evolves and beco= me more flattened.

PS3: Low scalability of = centralized route and mobility context maintenance

Setting up such special = routes and maintaining the mobility context for each MN is more difficult t= o scale in a centralized design with a large number of MNs. Distributing th= e route maintenance function and the mobility context maintenance function among different networks can be more= scalable.

PS4: Single point of fai= lure and attack

Centralized anchoring ma= y be more vulnerable to single point of failure and attack than a distribut= ed system.

 =

(The above is drafted wi= th contributions, inputs and discussions from various people. Additional co= ntributions and comments are most welcome.)

 =

H Anthony Chan


 =

--_000_6E31144C030982429702B11D6746B98C1DDFB582SZXEML505MBSchi_-- From luo.wen@zte.com.cn Tue May 8 18:24:07 2012 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE00B9E8012; Tue, 8 May 2012 18:24:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -90.19 X-Spam-Level: X-Spam-Status: No, score=-90.19 tagged_above=-999 required=5 tests=[BAYES_50=0.001, CHARSET_FARAWAY_HEADER=3.2, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_DOUBLE_IP_LOOSE=0.76, SARE_SUB_ENC_GB2312=1.345, USER_IN_WHITELIST=-100] 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 LPVldWEqxlcy; Tue, 8 May 2012 18:24:06 -0700 (PDT) Received: from mx5.zte.com.cn (mx6.zte.com.cn [95.130.199.165]) by ietfa.amsl.com (Postfix) with ESMTP id 0AEEA9E800E; Tue, 8 May 2012 18:23:59 -0700 (PDT) Received: from [10.30.17.100] by mx5.zte.com.cn with surfront esmtp id 286202143612382; Wed, 9 May 2012 08:41:17 +0800 (CST) Received: from [10.30.3.20] by [192.168.168.16] with StormMail ESMTP id 35266.2429667467; Wed, 9 May 2012 09:23:45 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse01.zte.com.cn with ESMTP id q491NjSS078385; Wed, 9 May 2012 09:23:45 +0800 (GMT-8) (envelope-from luo.wen@zte.com.cn) In-Reply-To: <6E31144C030982429702B11D6746B98C1DDFB50C@SZXEML505-MBS.china.huawei.com> To: h chan MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.4 March 27, 2005 Message-ID: From: luo.wen@zte.com.cn Date: Wed, 9 May 2012 09:23:40 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.1FP4|July 25, 2010) at 2012-05-09 09:23:46, Serialize complete at 2012-05-09 09:23:46 Content-Type: multipart/alternative; boundary="=_alternative 0007A9F1482579F9_=" X-MAIL: mse01.zte.com.cn q491NjSS078385 Cc: dmm-bounces@ietf.org, "dmm@ietf.org" Subject: [DMM] =?gb2312?b?tPC4tDogIGRyYWZ0IHJlcXVpcmVtZW50IFJFUS0yOiBUcmFu?= =?gb2312?b?c3BhcmVuY3kgdG8gVXBwZXIgTGF5ZXJz?= X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 May 2012 01:24:07 -0000 This is a multipart message in MIME format. --=_alternative 0007A9F1482579F9_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 SGkgQW50b255Og0KDQpUaGUgbGFzdCBwYXJ0IG9mIFBTLTUsIGRvZXMgdGhlIHNlbnRlbmNlICIg TmV0d29yayByZXNvdXJjZXMgYXJlIGFsc28gDQp3YXN0ZWQgd2hlbiB0aGUgdmlhIHJvdXRlcyBh cmUgc2V0IHVwIGZvciBtYW55IE1OcyB0aGF0IGRvIG5vdCByZXF1aXJlIElQIA0KbW9iaWxpdHkg c3VwcG9ydC4iIGltcGxpY2l0bHkgaW5kaWNhdGUgdGhlIHNjZW5hcmlvIHdoaWNoIHNpbWlsYXIg d2l0aCANCk1JUC9QTUlQPyANCldoZW4gSSByZWFkIHRoaXMgc2VudGVuY2UsIHRoZSBNSVAvUE1J UCB0dW5uZWwgYXBwZWFycyBpbiBteSBtaW5kLCBhbmQgDQp5ZXMsIGlmIE1OcyBkbyBub3QgcmVx dWlyZSBJUCBtb2JpbGl5IHN1cHBvcnQsIHRoZSAgTUlQL1BNSVAgdHVubmVsIHdpbGwgDQp3YXN0 ZSBuZXR3b3JrIHJlc291cmNlcy4NCg0KQ2hlZXJzLg0KDQoNCg0KDQpoIGNoYW4gPGguYW50aG9u eS5jaGFuQGh1YXdlaS5jb20+IA0Kt6K8/sjLOiAgZG1tLWJvdW5jZXNAaWV0Zi5vcmcNCjIwMTIv MDUvMDggMDE6NTgNCg0KytW8/sjLDQoiZG1tQGlldGYub3JnIiA8ZG1tQGlldGYub3JnPg0Ks63L zQ0KDQrW98ziDQpbRE1NXSBkcmFmdCByZXF1aXJlbWVudCBSRVEtMjogVHJhbnNwYXJlbmN5IHRv IFVwcGVyIExheWVycw0KDQoNCg0KDQoNCg0KUkVRLTI6IFRyYW5zcGFyZW5jeSB0byBVcHBlciBM YXllcnMNClRoZSBETU0gc29sdXRpb25zIFNIQUxMIGVuYWJsZSB0cmFuc3BhcmVuY3kgYWJvdmUg dGhlIElQIGxheWVyLiBTdWNoIA0KdHJhbnNwYXJlbmN5IGlzIG5lZWRlZCBmb3IgdGhlIGFwcGxp Y2F0aW9uIGZsb3dzIHRoYXQgY2Fubm90IGNvcGUgd2l0aCBhIA0KY2hhbmdlIG9mIElQIGFkZHJl c3MgYW5kIHdoZW4gbW9iaWxlIGhvc3RzIG9yIGVudGlyZSBtb2JpbGUgbmV0d29ya3MgDQpjaGFu Z2UgdGhlaXIgcG9pbnQgb2YgYXR0YWNobWVudCB0byB0aGUgSW50ZXJuZXQsIGJ1dCBTSE9VTEQg Tk9UIGJlIHRha2VuIA0KYXMgdGhlIGRlZmF1bHQgYmVoYXZpb3IuDQogDQpSRVEtMk0gKE1vdGl2 YXRpb24gZm9yIFJFUS0yKQ0KVGhlIGdvYWwgb2YgdGhpcyByZXF1aXJlbWVudCBpcyB0byANCmVu YWJsZSBtb3JlIGVmZmljaWVudCB1c2Ugb2YgbmV0d29yayByZXNvdXJjZXMgYW5kIG1vcmUgZWZm aWNpZW50IHJvdXRpbmcgDQpieSBub3QgaW52b2tpbmcgbW9iaWxpdHkgc3VwcG9ydCB3aGVuIHRo ZXJlIGlzIG5vIHN1Y2ggbmVlZC4NCiANClJFTEVWQU5UIHByb2JsZW06DQpQUzU6IFdhc3Rpbmcg cmVzb3VyY2VzIHRvIHN1cHBvcnQgbW9iaWxlIG5vZGVzIG5vdCBuZWVkaW5nIG1vYmlsaXR5IA0K c3VwcG9ydA0KSVAgbW9iaWxpdHkgc3VwcG9ydCBpcyBub3QgYWx3YXlzIHJlcXVpcmVkLiBGb3Ig ZXhhbXBsZSwgc29tZSBhcHBsaWNhdGlvbnMgDQpkbyBub3QgbmVlZCBhIHN0YWJsZSBJUCBhZGRy ZXNzIGR1cmluZyBoYW5kb3ZlciwgaS5lLiBJUCBzZXNzaW9uIA0KY29udGludWl0eS4gU29tZXRp bWVzLCB0aGUgZW50aXJlIGFwcGxpY2F0aW9uIHNlc3Npb24gcnVucyB3aGlsZSB0aGUgDQp0ZXJt aW5hbCBkb2VzIG5vdCBjaGFuZ2UgdGhlIHBvaW50IG9mIGF0dGFjaG1lbnQuIEluIHRoZXNlIHNp dHVhdGlvbnMgdGhhdCANCmRvIG5vdCByZXF1aXJlIElQIG1vYmlsaXR5IHN1cHBvcnQsIG5ldHdv cmsgcmVzb3VyY2VzIGFyZSB3YXN0ZWQgd2hlbiANCm1vYmlsaXR5IGNvbnRleHQgaXMgc2V0IHVw LiBOZXR3b3JrIHJlc291cmNlcyBhcmUgYWxzbyB3YXN0ZWQgd2hlbiB0aGUgdmlhIA0Kcm91dGVz IGFyZSBzZXQgdXAgZm9yIG1hbnkgTU5zIHRoYXQgZG8gbm90IHJlcXVpcmUgSVAgbW9iaWxpdHkg c3VwcG9ydC4NCiANCk9USEVSIHJlbGF0ZWQgcHJvYmxlbQ0KTy1QUzE6IE1vYmlsaXR5IHNpZ25h bGluZyBvdmVyaGVhZCB3aXRoIHBlZXItdG8tcGVlciBjb21tdW5pY2F0aW9uDQpXaGlsZSBtb2Jp bGl0eSBtYW5hZ2VtZW50IGVuYWJsZXMgYSBtb2JpbGUgaG9zdCB0byBiZSByZWFjaGFibGUsIHRo ZSBob3N0cyANCm1heSB0aGVuIGNvbW11bmljYXRlIGRpcmVjdGx5IHNvIHRoYXQgdGhlIG1vYmls aXR5IHN1cHBvcnQgaXMgbm8gbG9uZ2VyIA0KbmVlZGVkLiBUYWtpbmcgdGhlIG5lZWQgb2YgbW9i aWxpdHkgc3VwcG9ydCBhcyB0aGUgZGVmYXVsdCBiZWhhdmlvciB3aWxsIA0Kd2FzdGUgbmV0d29y ayByZXNvdXJjZXMuIA0KTy1QUzI6IExhY2sgb2YgdXNlci1jZW50cmljaXR5DQpDZW50cmFsaXpl ZCBkZXBsb3ltZW50IGNvbXBhcmVkIHdpdGggZGlzdHJpYnV0ZWQgbW9iaWxpdHkgbWFuYWdlbWVu dCBtYXkgDQpiZSBsZXNzIGNhcGFibGUgdG8gc3VwcG9ydCB1c2VyLWNlbnRyaWNpdHkuIEV4YW1w bGUgaW4gdGhlIGxhY2sgb2YgDQp1c2VyLWNlbnRyaWNpdHkgaXMgdG8gcHJvdmlkZSBtb2JpbGl0 eSBzdXBwb3J0IHRvIGFsbCBtb2JpbGUgbm9kZXMgYnkgDQpkZWZhdWx0IHJlZ2FyZGxlc3Mgb2Yg d2hldGhlciB0aGUgdXNlciBuZWVkcyBpdCBvciBub3QuDQogDQooVGhlIGFib3ZlIGhhcyBiZWVu IGRyYWZ0ZWQgd2l0aCBjb250cmlidXRpb25zLCBpbnB1dHMgYW5kIGRpc2N1c3Npb25zIA0KZnJv bSB2YXJpb3VzIHBlb3BsZS4gQWRkaXRpb25hbCBjb250cmlidXRpb25zIGFuZCBjb21tZW50cyBh cmUgbW9zdCANCndlbGNvbWUuKQ0KIA0KSCBBbnRob255IENoYW4NCg0KIF9fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpkbW0gbWFpbGluZyBsaXN0DQpkbW1A aWV0Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vZG1tDQoNCg0K --=_alternative 0007A9F1482579F9_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkhpIEFudG9ueTo8L2ZvbnQ+DQo8 YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPlRoZSBsYXN0IHBhcnQgb2Yg UFMtNSwgZG9lcyB0aGUgc2VudGVuY2UNCiZxdW90OzwvZm9udD48Zm9udCBzaXplPTIgZmFjZT0i Q2FsaWJyaSI+PGk+IE5ldHdvcmsgcmVzb3VyY2VzIGFyZSBhbHNvDQp3YXN0ZWQgd2hlbiB0aGUg dmlhIHJvdXRlcyBhcmUgc2V0IHVwIGZvciBtYW55IE1OcyB0aGF0IGRvIG5vdCByZXF1aXJlDQpJ UCBtb2JpbGl0eSBzdXBwb3J0LiZxdW90OyA8L2k+PC9mb250Pjxmb250IHNpemU9MiBmYWNlPSJz YW5zLXNlcmlmIj5pbXBsaWNpdGx5DQppbmRpY2F0ZSB0aGUgPC9mb250Pjxmb250IHNpemU9MiBm YWNlPSJDYWxpYnJpIj5zY2VuYXJpbyB3aGljaCBzaW1pbGFyDQp3aXRoIE1JUC9QTUlQPyA8L2Zv bnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9IkNhbGlicmkiPldoZW4gSSByZWFkIHRoaXMgc2Vu dGVuY2UsIHRoZSBNSVAvUE1JUA0KdHVubmVsIGFwcGVhcnMgaW4gbXkgbWluZCwgYW5kIHllcywg aWYgTU5zIGRvIG5vdCByZXF1aXJlIElQIG1vYmlsaXkgc3VwcG9ydCwNCnRoZSAmbmJzcDtNSVAv UE1JUCB0dW5uZWwgd2lsbCB3YXN0ZSBuZXR3b3JrIHJlc291cmNlcy48L2ZvbnQ+DQo8YnI+DQo8 YnI+PGZvbnQgc2l6ZT0yIGZhY2U9IkNhbGlicmkiPkNoZWVycy48L2ZvbnQ+DQo8YnI+DQo8YnI+ DQo8YnI+DQo8YnI+DQo8dGFibGUgd2lkdGg9MTAwJT4NCjx0ciB2YWxpZ249dG9wPg0KPHRkIHdp ZHRoPTQwJT48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+PGI+aCBjaGFuICZsdDtoLmFu dGhvbnkuY2hhbkBodWF3ZWkuY29tJmd0OzwvYj4NCjwvZm9udD4NCjxicj48Zm9udCBzaXplPTEg ZmFjZT0ic2Fucy1zZXJpZiI+t6K8/sjLOiAmbmJzcDtkbW0tYm91bmNlc0BpZXRmLm9yZzwvZm9u dD4NCjxwPjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj4yMDEyLzA1LzA4IDAxOjU4PC9m b250Pg0KPHRkIHdpZHRoPTU5JT4NCjx0YWJsZSB3aWR0aD0xMDAlPg0KPHRyIHZhbGlnbj10b3A+ DQo8dGQ+DQo8ZGl2IGFsaWduPXJpZ2h0Pjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj7K 1bz+yMs8L2ZvbnQ+PC9kaXY+DQo8dGQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPiZx dW90O2RtbUBpZXRmLm9yZyZxdW90OyAmbHQ7ZG1tQGlldGYub3JnJmd0OzwvZm9udD4NCjx0ciB2 YWxpZ249dG9wPg0KPHRkPg0KPGRpdiBhbGlnbj1yaWdodD48Zm9udCBzaXplPTEgZmFjZT0ic2Fu cy1zZXJpZiI+s63LzTwvZm9udD48L2Rpdj4NCjx0ZD4NCjx0ciB2YWxpZ249dG9wPg0KPHRkPg0K PGRpdiBhbGlnbj1yaWdodD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+1vfM4jwvZm9u dD48L2Rpdj4NCjx0ZD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+W0RNTV0gZHJhZnQg cmVxdWlyZW1lbnQgUkVRLTI6IFRyYW5zcGFyZW5jeQ0KdG8gVXBwZXIgTGF5ZXJzPC9mb250Pjwv dGFibGU+DQo8YnI+DQo8dGFibGU+DQo8dHIgdmFsaWduPXRvcD4NCjx0ZD4NCjx0ZD48L3RhYmxl Pg0KPGJyPjwvdGFibGU+DQo8YnI+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9IkNhbGli cmkiPlJFUS0yOiBUcmFuc3BhcmVuY3kgdG8gVXBwZXIgTGF5ZXJzPC9mb250Pg0KPGJyPjxmb250 IHNpemU9MiBmYWNlPSJDYWxpYnJpIj5UaGUgRE1NIHNvbHV0aW9ucyBTSEFMTCBlbmFibGUgdHJh bnNwYXJlbmN5DQphYm92ZSB0aGUgSVAgbGF5ZXIuIFN1Y2ggdHJhbnNwYXJlbmN5IGlzIG5lZWRl ZCBmb3IgdGhlIGFwcGxpY2F0aW9uIGZsb3dzDQp0aGF0IGNhbm5vdCBjb3BlIHdpdGggYSBjaGFu Z2Ugb2YgSVAgYWRkcmVzcyBhbmQgd2hlbiBtb2JpbGUgaG9zdHMgb3IgZW50aXJlDQptb2JpbGUg bmV0d29ya3MgY2hhbmdlIHRoZWlyIHBvaW50IG9mIGF0dGFjaG1lbnQgdG8gdGhlIEludGVybmV0 LCBidXQgU0hPVUxEDQpOT1QgYmUgdGFrZW4gYXMgdGhlIGRlZmF1bHQgYmVoYXZpb3IuPC9mb250 Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJDYWxpYnJpIj4mbmJzcDs8L2ZvbnQ+DQo8YnI+PGZv bnQgc2l6ZT0yIGZhY2U9IkNhbGlicmkiPlJFUS0yTSAoTW90aXZhdGlvbiBmb3IgUkVRLTIpPC9m b250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJDYWxpYnJpIj5UaGUgZ29hbCBvZiB0aGlzIHJl cXVpcmVtZW50IGlzIHRvIDwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0iQ2FsaWJyaSI+ ZW5hYmxlIG1vcmUgZWZmaWNpZW50IHVzZSBvZiBuZXR3b3JrIHJlc291cmNlcw0KYW5kIG1vcmUg ZWZmaWNpZW50IHJvdXRpbmcgYnkgbm90IGludm9raW5nIG1vYmlsaXR5IHN1cHBvcnQgd2hlbiB0 aGVyZQ0KaXMgbm8gc3VjaCBuZWVkLjwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0iQ2Fs aWJyaSI+Jm5ic3A7PC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJDYWxpYnJpIj5SRUxF VkFOVCBwcm9ibGVtOjwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0iQ2FsaWJyaSI+UFM1 OiBXYXN0aW5nIHJlc291cmNlcyB0byBzdXBwb3J0IG1vYmlsZQ0Kbm9kZXMgbm90IG5lZWRpbmcg bW9iaWxpdHkgc3VwcG9ydDwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0iQ2FsaWJyaSI+ SVAgbW9iaWxpdHkgc3VwcG9ydCBpcyBub3QgYWx3YXlzIHJlcXVpcmVkLg0KRm9yIGV4YW1wbGUs IHNvbWUgYXBwbGljYXRpb25zIGRvIG5vdCBuZWVkIGEgc3RhYmxlIElQIGFkZHJlc3MgZHVyaW5n IGhhbmRvdmVyLA0KaS5lLiBJUCBzZXNzaW9uIGNvbnRpbnVpdHkuIFNvbWV0aW1lcywgdGhlIGVu dGlyZSBhcHBsaWNhdGlvbiBzZXNzaW9uIHJ1bnMNCndoaWxlIHRoZSB0ZXJtaW5hbCBkb2VzIG5v dCBjaGFuZ2UgdGhlIHBvaW50IG9mIGF0dGFjaG1lbnQuIEluIHRoZXNlIHNpdHVhdGlvbnMNCnRo YXQgZG8gbm90IHJlcXVpcmUgSVAgbW9iaWxpdHkgc3VwcG9ydCwgbmV0d29yayByZXNvdXJjZXMg YXJlIHdhc3RlZCB3aGVuDQptb2JpbGl0eSBjb250ZXh0IGlzIHNldCB1cC4gTmV0d29yayByZXNv dXJjZXMgYXJlIGFsc28gd2FzdGVkIHdoZW4gdGhlDQp2aWEgcm91dGVzIGFyZSBzZXQgdXAgZm9y IG1hbnkgTU5zIHRoYXQgZG8gbm90IHJlcXVpcmUgSVAgbW9iaWxpdHkgc3VwcG9ydC48L2ZvbnQ+ DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9IkNhbGlicmkiPiZuYnNwOzwvZm9udD4NCjxicj48Zm9u dCBzaXplPTIgZmFjZT0iQ2FsaWJyaSI+T1RIRVIgcmVsYXRlZCBwcm9ibGVtPC9mb250Pg0KPGJy Pjxmb250IHNpemU9MiBmYWNlPSJDYWxpYnJpIj5PLVBTMTogTW9iaWxpdHkgc2lnbmFsaW5nIG92 ZXJoZWFkIHdpdGgNCnBlZXItdG8tcGVlciBjb21tdW5pY2F0aW9uPC9mb250Pg0KPGJyPjxmb250 IHNpemU9MiBmYWNlPSJDYWxpYnJpIj5XaGlsZSBtb2JpbGl0eSBtYW5hZ2VtZW50IGVuYWJsZXMg YSBtb2JpbGUNCmhvc3QgdG8gYmUgcmVhY2hhYmxlLCB0aGUgaG9zdHMgbWF5IHRoZW4gY29tbXVu aWNhdGUgZGlyZWN0bHkgc28gdGhhdCB0aGUNCm1vYmlsaXR5IHN1cHBvcnQgaXMgbm8gbG9uZ2Vy IG5lZWRlZC4gVGFraW5nIHRoZSBuZWVkIG9mIG1vYmlsaXR5IHN1cHBvcnQNCmFzIHRoZSBkZWZh dWx0IGJlaGF2aW9yIHdpbGwgd2FzdGUgbmV0d29yayByZXNvdXJjZXMuIDwvZm9udD4NCjxicj48 Zm9udCBzaXplPTIgZmFjZT0iQ2FsaWJyaSI+Ty1QUzI6IExhY2sgb2YgdXNlci1jZW50cmljaXR5 PC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJDYWxpYnJpIj5DZW50cmFsaXplZCBkZXBs b3ltZW50IGNvbXBhcmVkIHdpdGggZGlzdHJpYnV0ZWQNCm1vYmlsaXR5IG1hbmFnZW1lbnQgbWF5 IGJlIGxlc3MgY2FwYWJsZSB0byBzdXBwb3J0IHVzZXItY2VudHJpY2l0eS4gRXhhbXBsZQ0KaW4g dGhlIGxhY2sgb2YgdXNlci1jZW50cmljaXR5IGlzIHRvIHByb3ZpZGUgbW9iaWxpdHkgc3VwcG9y dCB0byBhbGwgbW9iaWxlDQpub2RlcyBieSBkZWZhdWx0IHJlZ2FyZGxlc3Mgb2Ygd2hldGhlciB0 aGUgdXNlciBuZWVkcyBpdCBvciBub3QuPC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJD YWxpYnJpIj4mbmJzcDs8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9IkNhbGlicmkiPihU aGUgYWJvdmUgaGFzIGJlZW4gZHJhZnRlZCB3aXRoIGNvbnRyaWJ1dGlvbnMsDQppbnB1dHMgYW5k IGRpc2N1c3Npb25zIGZyb20gdmFyaW91cyBwZW9wbGUuIEFkZGl0aW9uYWwgY29udHJpYnV0aW9u cyBhbmQNCmNvbW1lbnRzIGFyZSBtb3N0IHdlbGNvbWUuKTwvZm9udD4NCjxicj48Zm9udCBzaXpl PTIgZmFjZT0iQ2FsaWJyaSI+Jm5ic3A7PC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJD YWxpYnJpIj5IIEFudGhvbnkgQ2hhbjxicj4NCjwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFj ZT0iQ2FsaWJyaSI+Jm5ic3A7PC9mb250Pjxmb250IHNpemU9Mj48dHQ+X19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQpkbW0gbWFpbGluZyBsaXN0PGJy Pg0KZG1tQGlldGYub3JnPGJyPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m by9kbW08YnI+DQo8L3R0PjwvZm9udD4NCjxicj4NCg== --=_alternative 0007A9F1482579F9_=-- From tso@zteusa.com Mon May 14 15:31:55 2012 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D4D521F8912 for ; Mon, 14 May 2012 15:31:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.933 X-Spam-Level: *** X-Spam-Status: No, score=3.933 tagged_above=-999 required=5 tests=[AWL=-5.691, BAYES_40=-0.185, CHARSET_FARAWAY_HEADER=3.2, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_DOUBLE_IP_LOOSE=0.76, SARE_SUB_ENC_GB2312=1.345] 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 7CVsXj8QorJU for ; Mon, 14 May 2012 15:31:54 -0700 (PDT) Received: from mx5.zte.com.cn (mx6.zte.com.cn [95.130.199.165]) by ietfa.amsl.com (Postfix) with ESMTP id E95F021F890B for ; Mon, 14 May 2012 15:31:52 -0700 (PDT) Received: from [10.30.17.100] by mx5.zte.com.cn with surfront esmtp id 286201057192640; Tue, 15 May 2012 05:47:50 +0800 (CST) Received: from [10.30.3.20] by [192.168.168.16] with StormMail ESMTP id 16702.1343247725; Tue, 15 May 2012 06:31:42 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse01.zte.com.cn with ESMTP id q4EMVahT078292; Tue, 15 May 2012 06:31:40 +0800 (GMT-8) (envelope-from tso@zteusa.com) In-Reply-To: References: <6E31144C030982429702B11D6746B98C1DDFB50C@SZXEML505-MBS.china.huawei.com> To: luo.wen@zte.com.cn MIME-Version: 1.0 X-KeepSent: C0ABCBED:FB4EC922-882579FE:0010EBC4; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.5.1 September 28, 2009 Message-ID: From: tso@zteusa.com Date: Mon, 14 May 2012 15:31:33 -0700 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.1FP4|July 25, 2010) at 2012-05-15 06:31:40, Serialize complete at 2012-05-15 06:31:40 Content-Type: multipart/alternative; boundary="=_alternative 007BBE4E882579FE_=" X-MAIL: mse01.zte.com.cn q4EMVahT078292 Cc: "dmm@ietf.org" Subject: Re: [DMM] =?gb2312?b?tPC4tDogIGRyYWZ0IHJlcXVpcmVtZW50IFJFUS0yOiBUcmFu?= =?gb2312?b?c3BhcmVuY3kgdG8gVXBwZXIgTGF5ZXJz?= X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 May 2012 22:31:55 -0000 This is a multipart message in MIME format. --=_alternative 007BBE4E882579FE_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 RGVhciBBbnRob255LCANCg0KSSBzaGFyZSB0aGUgc2FtZSBjb25jZXJuIGFzIEx1b3dlbiBkb2Vz IGZvciBQUzUsIGJ1dCBhbHNvIHNldmVyYWwgaW5mbyBmb3IgDQphc3NvY2lhdGVkIHdpdGggdGhp cyByZXF1aXJlbWVudHMuICBQbGVhc2UgbXkgY29tbWVudHMgaW5saW5lIGJlbG93LiANCg0KVGhh bmtzLiANCg0KDQoNCg0KbHVvLndlbkB6dGUuY29tLmNuIA0KU2VudCBieTogZG1tLWJvdW5jZXNA aWV0Zi5vcmcNCjA1LzA4LzIwMTIgMDY6MjMgUE0NCg0KVG8NCmggY2hhbiA8aC5hbnRob255LmNo YW5AaHVhd2VpLmNvbT4NCmNjDQpkbW0tYm91bmNlc0BpZXRmLm9yZywgImRtbUBpZXRmLm9yZyIg PGRtbUBpZXRmLm9yZz4NClN1YmplY3QNCltETU1dILTwuLQ6ICBkcmFmdCByZXF1aXJlbWVudCBS RVEtMjogVHJhbnNwYXJlbmN5IHRvIFVwcGVyIExheWVycw0KDQoNCg0KDQoNCg0KDQpIaSBBbnRv bnk6IA0KDQpUaGUgbGFzdCBwYXJ0IG9mIFBTLTUsIGRvZXMgdGhlIHNlbnRlbmNlICIgTmV0d29y ayByZXNvdXJjZXMgYXJlIGFsc28gDQp3YXN0ZWQgd2hlbiB0aGUgdmlhIHJvdXRlcyBhcmUgc2V0 IHVwIGZvciBtYW55IE1OcyB0aGF0IGRvIG5vdCByZXF1aXJlIElQIA0KbW9iaWxpdHkgc3VwcG9y dC4iIGltcGxpY2l0bHkgaW5kaWNhdGUgdGhlIHNjZW5hcmlvIHdoaWNoIHNpbWlsYXIgd2l0aCAN Ck1JUC9QTUlQPyANCldoZW4gSSByZWFkIHRoaXMgc2VudGVuY2UsIHRoZSBNSVAvUE1JUCB0dW5u ZWwgYXBwZWFycyBpbiBteSBtaW5kLCBhbmQgDQp5ZXMsIGlmIE1OcyBkbyBub3QgcmVxdWlyZSBJ UCBtb2JpbGl5IHN1cHBvcnQsIHRoZSAgTUlQL1BNSVAgdHVubmVsIHdpbGwgDQp3YXN0ZSBuZXR3 b3JrIHJlc291cmNlcy4gDQoNCkNoZWVycy4gDQoNCg0KDQpoIGNoYW4gPGguYW50aG9ueS5jaGFu QGh1YXdlaS5jb20+IA0Kt6K8/sjLOiAgZG1tLWJvdW5jZXNAaWV0Zi5vcmcgDQoyMDEyLzA1LzA4 IDAxOjU4IA0KDQoNCsrVvP7Iyw0KImRtbUBpZXRmLm9yZyIgPGRtbUBpZXRmLm9yZz4gDQqzrcvN DQoNCtb3zOINCltETU1dIGRyYWZ0IHJlcXVpcmVtZW50IFJFUS0yOiBUcmFuc3BhcmVuY3kgdG8g VXBwZXIgTGF5ZXJzDQoNCg0KDQoNCg0KDQoNCg0KUkVRLTI6IFRyYW5zcGFyZW5jeSB0byBVcHBl ciBMYXllcnMgDQpUaGUgRE1NIHNvbHV0aW9ucyBTSEFMTCBlbmFibGUgdHJhbnNwYXJlbmN5IGFi b3ZlIHRoZSBJUCBsYXllci4gU3VjaCANCnRyYW5zcGFyZW5jeSBpcyBuZWVkZWQgZm9yIHRoZSBh cHBsaWNhdGlvbiBmbG93cyB0aGF0IGNhbm5vdCBjb3BlIHdpdGggYSANCmNoYW5nZSBvZiBJUCBh ZGRyZXNzIGFuZCB3aGVuIG1vYmlsZSBob3N0cyBvciBlbnRpcmUgbW9iaWxlIG5ldHdvcmtzIA0K Y2hhbmdlIHRoZWlyIHBvaW50IG9mIGF0dGFjaG1lbnQgdG8gdGhlIEludGVybmV0LCBidXQgU0hP VUxEIE5PVCBiZSB0YWtlbiANCmFzIHRoZSBkZWZhdWx0IGJlaGF2aW9yLiANCj4+Pj4+PiBDb21t ZW50cw0KKDEpIFdoYXQgc2NlbmFyaW8gaXMgdGhhdCAiZW50aXJlIG1vYmlsZSBuZXR3b3JrcyBj aGFuZ2UgdGhlaXIgcG9pbnQgb2YgDQphdHRhY2htZW50IHRvIHRoZSBpbnRlcm5ldCI/DQogIA0K UkVRLTJNIChNb3RpdmF0aW9uIGZvciBSRVEtMikgDQpUaGUgZ29hbCBvZiB0aGlzIHJlcXVpcmVt ZW50IGlzIHRvIA0KZW5hYmxlIG1vcmUgZWZmaWNpZW50IHVzZSBvZiBuZXR3b3JrIHJlc291cmNl cyBhbmQgbW9yZSBlZmZpY2llbnQgcm91dGluZyANCmJ5IG5vdCBpbnZva2luZyBtb2JpbGl0eSBz dXBwb3J0IHdoZW4gdGhlcmUgaXMgbm8gc3VjaCBuZWVkLiANCiAgDQpSRUxFVkFOVCBwcm9ibGVt OiANClBTNTogV2FzdGluZyByZXNvdXJjZXMgdG8gc3VwcG9ydCBtb2JpbGUgbm9kZXMgbm90IG5l ZWRpbmcgbW9iaWxpdHkgDQpzdXBwb3J0IA0KSVAgbW9iaWxpdHkgc3VwcG9ydCBpcyBub3QgYWx3 YXlzIHJlcXVpcmVkLiBGb3IgZXhhbXBsZSwgc29tZSBhcHBsaWNhdGlvbnMgDQpkbyBub3QgbmVl ZCBhIHN0YWJsZSBJUCBhZGRyZXNzIGR1cmluZyBoYW5kb3ZlciwgaS5lLiBJUCBzZXNzaW9uIA0K Y29udGludWl0eS4gU29tZXRpbWVzLCB0aGUgZW50aXJlIGFwcGxpY2F0aW9uIHNlc3Npb24gcnVu cyB3aGlsZSB0aGUgDQp0ZXJtaW5hbCBkb2VzIG5vdCBjaGFuZ2UgdGhlIHBvaW50IG9mIGF0dGFj aG1lbnQuIEluIHRoZXNlIHNpdHVhdGlvbnMgdGhhdCANCmRvIG5vdCByZXF1aXJlIElQIG1vYmls aXR5IHN1cHBvcnQsIG5ldHdvcmsgcmVzb3VyY2VzIGFyZSB3YXN0ZWQgd2hlbiANCm1vYmlsaXR5 IGNvbnRleHQgaXMgc2V0IHVwLiBOZXR3b3JrIHJlc291cmNlcyBhcmUgYWxzbyB3YXN0ZWQgd2hl biB0aGUgdmlhIA0Kcm91dGVzIGFyZSBzZXQgdXAgZm9yIG1hbnkgTU5zIHRoYXQgZG8gbm90IHJl cXVpcmUgSVAgbW9iaWxpdHkgc3VwcG9ydC4gDQo+Pj4+Pj4gQ29tbWVudHMNCigxKSBJIGhhdmUg dGhlIHNhbWUgY29uY2VybiBhcyBMdW9XZW4gZG9lcy4gIFdlIHNob3VsZCBiZSBtb3JlIGNsZWFy IHdoYXQgDQphcmUgd2UgcmVmZXJyaW5nIHRvIGZvciB0aGUgdGVybSAibW9iaWxpdHkgY29udGV4 dCIgaGVyZT8gIEl0IGlzIGJlY2F1c2UsIA0KdGhlcmUgd291bGQgYWx3YXlzIGJlIGNvbnRleHQg c2V0IHVwIGZvciB0aGUgbW9iaWxlIG5vZGUgYXR0YWNoaW5nIHRvIHRoZSANCm5ldHdvcmsgcmVn YXJkbGVzcyBpZiB0aGUgSVAgbW9iaWxpdHkgaXMgcmVxdWlyZWQgb3Igbm90LCBzdWNoIGFzIHBl ci1NTiANCmxvY2FsaXphdGlvbiBpbmZvcm1hdGlvbiBhbmQgc2VjdXJpdHkgY29udGV4dC4gIEkg YmVsaWV2ZSB0aGF0IHRoZSANCiJzcGVjaWZpYyIgbW9iaWxpdHkgY29udGV4dCB0aGF0IHlvdSdy ZSByZWZlcnJpbmcgaGVyZSBpcyB0aGUgY29udGV4dCBpbmZvIA0KdGhhdCBzdXBwb3J0cyB0aGUg TU4gZm9yIGNoYW5naW5nIHRoZWlyIHBvaW50IG9mIGF0dGFjaG1lbnQgdG8gdGhlIG5ldHdvcmsg DQpzdWNoIGFzIHRoZSBtb2JpbGl0eSB0dW5uZWxpbmcgaW5mby4gDQo+Pj4+PiBQcm9wb3NlZCBu ZXcgdGV4dCANClBTNTogV2FzdGluZyByZXNvdXJjZXMgdG8gc3VwcG9ydCBtb2JpbGUgbm9kZXMg bm90IG5lZWRpbmcgbW9iaWxpdHkgDQpzdXBwb3J0IA0KSVAgbW9iaWxpdHkgc3VwcG9ydCBpcyBu b3QgYWx3YXlzIHJlcXVpcmVkLiBGb3IgZXhhbXBsZSwgc29tZSBhcHBsaWNhdGlvbnMgDQpkbyBu b3QgbmVlZCBhIHN0YWJsZSBJUCBhZGRyZXNzIGR1cmluZyBoYW5kb3ZlciwgaS5lLiBJUCBzZXNz aW9uIA0KY29udGludWl0eS4gU29tZXRpbWVzLCB0aGUgZW50aXJlIGFwcGxpY2F0aW9uIHNlc3Np b24gcnVucyB3aGlsZSB0aGUgDQp0ZXJtaW5hbCBkb2VzIG5vdCBjaGFuZ2UgdGhlIHBvaW50IG9m IGF0dGFjaG1lbnQuIEluIHRoZXNlIHNpdHVhdGlvbnMgdGhhdCANCmRvIG5vdCByZXF1aXJlIElQ IG1vYmlsaXR5IHN1cHBvcnQsIG5ldHdvcmsgcmVzb3VyY2VzIGFyZSB3YXN0ZWQgd2hlbiANCmlu Y2x1ZGluZyBhZGRpdGlvbmFsIGluZm8gdG8gdGhlIG1vYmlsaXR5IGNvbnRleHQgdG8gc3VwcG9y dCB0aGUgY2hhbmdpbmcgDQp0aGUgcG9pbnQgb2YgYXR0YWNobWVudC4gTmV0d29yayByZXNvdXJj ZXMgYXJlIGFsc28gd2FzdGVkIHdoZW4gdGhlIHZpYSANCnJvdXRlcyBhcmUgc2V0IHVwIGZvciBt YW55IE1OcyB0aGF0IGRvIG5vdCByZXF1aXJlIElQIG1vYmlsaXR5IHN1cHBvcnQuIA0KDQogIA0K T1RIRVIgcmVsYXRlZCBwcm9ibGVtIA0KTy1QUzE6IE1vYmlsaXR5IHNpZ25hbGluZyBvdmVyaGVh ZCB3aXRoIHBlZXItdG8tcGVlciBjb21tdW5pY2F0aW9uIA0KV2hpbGUgbW9iaWxpdHkgbWFuYWdl bWVudCBlbmFibGVzIGEgbW9iaWxlIGhvc3QgdG8gYmUgcmVhY2hhYmxlLCB0aGUgaG9zdHMgDQpt YXkgdGhlbiBjb21tdW5pY2F0ZSBkaXJlY3RseSBzbyB0aGF0IHRoZSBtb2JpbGl0eSBzdXBwb3J0 IGlzIG5vIGxvbmdlciANCm5lZWRlZC4gVGFraW5nIHRoZSBuZWVkIG9mIG1vYmlsaXR5IHN1cHBv cnQgYXMgdGhlIGRlZmF1bHQgYmVoYXZpb3Igd2lsbCANCndhc3RlIG5ldHdvcmsgcmVzb3VyY2Vz LiANCk8tUFMyOiBMYWNrIG9mIHVzZXItY2VudHJpY2l0eSANCkNlbnRyYWxpemVkIGRlcGxveW1l bnQgY29tcGFyZWQgd2l0aCBkaXN0cmlidXRlZCBtb2JpbGl0eSBtYW5hZ2VtZW50IG1heSANCmJl IGxlc3MgY2FwYWJsZSB0byBzdXBwb3J0IHVzZXItY2VudHJpY2l0eS4gRXhhbXBsZSBpbiB0aGUg bGFjayBvZiANCnVzZXItY2VudHJpY2l0eSBpcyB0byBwcm92aWRlIG1vYmlsaXR5IHN1cHBvcnQg dG8gYWxsIG1vYmlsZSBub2RlcyBieSANCmRlZmF1bHQgcmVnYXJkbGVzcyBvZiB3aGV0aGVyIHRo ZSB1c2VyIG5lZWRzIGl0IG9yIG5vdC4gDQogIA0KKFRoZSBhYm92ZSBoYXMgYmVlbiBkcmFmdGVk IHdpdGggY29udHJpYnV0aW9ucywgaW5wdXRzIGFuZCBkaXNjdXNzaW9ucyANCmZyb20gdmFyaW91 cyBwZW9wbGUuIEFkZGl0aW9uYWwgY29udHJpYnV0aW9ucyBhbmQgY29tbWVudHMgYXJlIG1vc3Qg DQp3ZWxjb21lLikgDQogIA0KSCBBbnRob255IENoYW4NCg0KIF9fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fDQpkbW0gbWFpbGluZyBsaXN0DQpkbW1AaWV0Zi5v cmcNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vZG1tDQpfX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KZG1tIG1haWxpbmcgbGlzdA0K ZG1tQGlldGYub3JnDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2RtbQ0K DQoNCg0KDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLQ0KWlRFIEluZm9ybWF0aW9uIFNlY3VyaXR5IE5vdGljZTogVGhlIGluZm9ybWF0aW9u IGNvbnRhaW5lZCBpbiB0aGlzIG1haWwgaXMgc29sZWx5IHByb3BlcnR5IG9mIHRoZSBzZW5kZXIn cyBvcmdhbml6YXRpb24uIFRoaXMgbWFpbCBjb21tdW5pY2F0aW9uIGlzIGNvbmZpZGVudGlhbC4g UmVjaXBpZW50cyBuYW1lZCBhYm92ZSBhcmUgb2JsaWdhdGVkIHRvIG1haW50YWluIHNlY3JlY3kg YW5kIGFyZSBub3QgcGVybWl0dGVkIHRvIGRpc2Nsb3NlIHRoZSBjb250ZW50cyBvZiB0aGlzIGNv bW11bmljYXRpb24gdG8gb3RoZXJzLg0KVGhpcyBlbWFpbCBhbmQgYW55IGZpbGVzIHRyYW5zbWl0 dGVkIHdpdGggaXQgYXJlIGNvbmZpZGVudGlhbCBhbmQgaW50ZW5kZWQgc29sZWx5IGZvciB0aGUg dXNlIG9mIHRoZSBpbmRpdmlkdWFsIG9yIGVudGl0eSB0byB3aG9tIHRoZXkgYXJlIGFkZHJlc3Nl ZC4gSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBlbWFpbCBpbiBlcnJvciBwbGVhc2Ugbm90aWZ5 IHRoZSBvcmlnaW5hdG9yIG9mIHRoZSBtZXNzYWdlLiBBbnkgdmlld3MgZXhwcmVzc2VkIGluIHRo aXMgbWVzc2FnZSBhcmUgdGhvc2Ugb2YgdGhlIGluZGl2aWR1YWwgc2VuZGVyLg0KVGhpcyBtZXNz YWdlIGhhcyBiZWVuIHNjYW5uZWQgZm9yIHZpcnVzZXMgYW5kIFNwYW0gYnkgWlRFIEFudGktU3Bh bSBzeXN0ZW0uDQo= --=_alternative 007BBE4E882579FE_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 PGZvbnQgc2l6ZT0zIGNvbG9yPWJsdWUgZmFjZT0ic2Fucy1zZXJpZiI+RGVhciBBbnRob255LCA8 L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0zIGNvbG9yPWJsdWUgZmFjZT0ic2Fucy1zZXJp ZiI+SSBzaGFyZSB0aGUgc2FtZSBjb25jZXJuDQphcyBMdW93ZW4gZG9lcyBmb3IgUFM1LCBidXQg YWxzbyBzZXZlcmFsIGluZm8gZm9yIGFzc29jaWF0ZWQgd2l0aCB0aGlzDQpyZXF1aXJlbWVudHMu ICZuYnNwO1BsZWFzZSBteSBjb21tZW50cyBpbmxpbmUgYmVsb3cuICZuYnNwOzwvZm9udD4NCjxi cj4NCjxicj48Zm9udCBzaXplPTMgY29sb3I9Ymx1ZSBmYWNlPSJzYW5zLXNlcmlmIj5UaGFua3Mu ICZuYnNwOyA8L2ZvbnQ+DQo8YnI+DQo8YnI+DQo8YnI+DQo8YnI+DQo8dGFibGUgd2lkdGg9MTAw JT4NCjx0ciB2YWxpZ249dG9wPg0KPHRkIHdpZHRoPTM1JT48Zm9udCBzaXplPTEgZmFjZT0ic2Fu cy1zZXJpZiI+PGI+bHVvLndlbkB6dGUuY29tLmNuPC9iPg0KPC9mb250Pg0KPGJyPjxmb250IHNp emU9MSBmYWNlPSJzYW5zLXNlcmlmIj5TZW50IGJ5OiBkbW0tYm91bmNlc0BpZXRmLm9yZzwvZm9u dD4NCjxwPjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj4wNS8wOC8yMDEyIDA2OjIzIFBN PC9mb250Pg0KPHRkIHdpZHRoPTY0JT4NCjx0YWJsZSB3aWR0aD0xMDAlPg0KPHRyIHZhbGlnbj10 b3A+DQo8dGQ+DQo8ZGl2IGFsaWduPXJpZ2h0Pjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlm Ij5UbzwvZm9udD48L2Rpdj4NCjx0ZD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+aCBj aGFuICZsdDtoLmFudGhvbnkuY2hhbkBodWF3ZWkuY29tJmd0OzwvZm9udD4NCjx0ciB2YWxpZ249 dG9wPg0KPHRkPg0KPGRpdiBhbGlnbj1yaWdodD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJp ZiI+Y2M8L2ZvbnQ+PC9kaXY+DQo8dGQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPmRt bS1ib3VuY2VzQGlldGYub3JnLCAmcXVvdDtkbW1AaWV0Zi5vcmcmcXVvdDsNCiZsdDtkbW1AaWV0 Zi5vcmcmZ3Q7PC9mb250Pg0KPHRyIHZhbGlnbj10b3A+DQo8dGQ+DQo8ZGl2IGFsaWduPXJpZ2h0 Pjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj5TdWJqZWN0PC9mb250PjwvZGl2Pg0KPHRk Pjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj5bRE1NXSC08Li0OiAmbmJzcDtkcmFmdCBy ZXF1aXJlbWVudA0KUkVRLTI6IFRyYW5zcGFyZW5jeSB0byBVcHBlciBMYXllcnM8L2ZvbnQ+PC90 YWJsZT4NCjxicj4NCjx0YWJsZT4NCjx0ciB2YWxpZ249dG9wPg0KPHRkPg0KPHRkPjwvdGFibGU+ DQo8YnI+PC90YWJsZT4NCjxicj4NCjxicj4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1z ZXJpZiI+PGJyPg0KPC9mb250Pjxmb250IHNpemU9MyBmYWNlPSJzYW5zLXNlcmlmIj5IaSBBbnRv bnk6IDxicj4NCjxicj4NClRoZSBsYXN0IHBhcnQgb2YgUFMtNSwgZG9lcyB0aGUgc2VudGVuY2Ug JnF1b3Q7PC9mb250Pjxmb250IHNpemU9MyBmYWNlPSJDYWxpYnJpIj48aT4NCk5ldHdvcmsgcmVz b3VyY2VzIGFyZSBhbHNvIHdhc3RlZCB3aGVuIHRoZSB2aWEgcm91dGVzIGFyZSBzZXQgdXAgZm9y IG1hbnkNCk1OcyB0aGF0IGRvIG5vdCByZXF1aXJlIElQIG1vYmlsaXR5IHN1cHBvcnQuJnF1b3Q7 IDwvaT48L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYiPmltcGxpY2l0bHkNCmlu ZGljYXRlIHRoZSA8L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9IkNhbGlicmkiPnNjZW5hcmlvIHdo aWNoIHNpbWlsYXINCndpdGggTUlQL1BNSVA/IDxicj4NCldoZW4gSSByZWFkIHRoaXMgc2VudGVu Y2UsIHRoZSBNSVAvUE1JUCB0dW5uZWwgYXBwZWFycyBpbiBteSBtaW5kLCBhbmQNCnllcywgaWYg TU5zIGRvIG5vdCByZXF1aXJlIElQIG1vYmlsaXkgc3VwcG9ydCwgdGhlICZuYnNwO01JUC9QTUlQ IHR1bm5lbA0Kd2lsbCB3YXN0ZSBuZXR3b3JrIHJlc291cmNlcy48L2ZvbnQ+PGZvbnQgc2l6ZT0z IGZhY2U9InNhbnMtc2VyaWYiPiA8YnI+DQo8L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9IkNhbGli cmkiPjxicj4NCkNoZWVycy48L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYiPiA8 YnI+DQo8YnI+DQo8YnI+DQo8L2ZvbnQ+DQo8dGFibGUgd2lkdGg9MTAwJT4NCjx0ciB2YWxpZ249 dG9wPg0KPHRkIHdpZHRoPTM3JT48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+PGI+aCBj aGFuICZsdDtoLmFudGhvbnkuY2hhbkBodWF3ZWkuY29tJmd0OzwvYj4NCjxicj4NCreivP7Iyzog Jm5ic3A7ZG1tLWJvdW5jZXNAaWV0Zi5vcmc8L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9InNhbnMt c2VyaWYiPg0KPC9mb250Pg0KPHA+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPjIwMTIv MDUvMDggMDE6NTg8L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYiPg0KPC9mb250 Pg0KPHRkIHdpZHRoPTYyJT4NCjxicj4NCjx0YWJsZSB3aWR0aD0xMDAlPg0KPHRyIHZhbGlnbj10 b3A+DQo8dGQgd2lkdGg9MTIlPg0KPGRpdiBhbGlnbj1yaWdodD48Zm9udCBzaXplPTEgZmFjZT0i c2Fucy1zZXJpZiI+ytW8/sjLPC9mb250PjwvZGl2Pg0KPHRkIHdpZHRoPTg3JT48Zm9udCBzaXpl PTEgZmFjZT0ic2Fucy1zZXJpZiI+JnF1b3Q7ZG1tQGlldGYub3JnJnF1b3Q7ICZsdDtkbW1AaWV0 Zi5vcmcmZ3Q7PC9mb250Pjxmb250IHNpemU9MyBmYWNlPSJzYW5zLXNlcmlmIj4NCjwvZm9udD4N Cjx0ciB2YWxpZ249dG9wPg0KPHRkPg0KPGRpdiBhbGlnbj1yaWdodD48Zm9udCBzaXplPTEgZmFj ZT0ic2Fucy1zZXJpZiI+s63LzTwvZm9udD48L2Rpdj4NCjx0ZD4NCjx0ciB2YWxpZ249dG9wPg0K PHRkPg0KPGRpdiBhbGlnbj1yaWdodD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+1vfM 4jwvZm9udD48L2Rpdj4NCjx0ZD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+W0RNTV0g ZHJhZnQgcmVxdWlyZW1lbnQgUkVRLTI6IFRyYW5zcGFyZW5jeQ0KdG8gVXBwZXIgTGF5ZXJzPC9m b250PjwvdGFibGU+DQo8YnI+DQo8YnI+DQo8dGFibGU+DQo8dHIgdmFsaWduPXRvcD4NCjx0ZD4N Cjx0ZD48L3RhYmxlPg0KPGJyPjwvdGFibGU+DQo8YnI+PGZvbnQgc2l6ZT0zIGZhY2U9InNhbnMt c2VyaWYiPjxicj4NCjxicj4NCjwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0iQ2FsaWJyaSI+PGJy Pg0KUkVRLTI6IFRyYW5zcGFyZW5jeSB0byBVcHBlciBMYXllcnM8L2ZvbnQ+PGZvbnQgc2l6ZT0z IGZhY2U9InNhbnMtc2VyaWYiPg0KPC9mb250Pjxmb250IHNpemU9MyBmYWNlPSJDYWxpYnJpIj48 YnI+DQpUaGUgRE1NIHNvbHV0aW9ucyBTSEFMTCBlbmFibGUgdHJhbnNwYXJlbmN5IGFib3ZlIHRo ZSBJUCBsYXllci4gU3VjaCB0cmFuc3BhcmVuY3kNCmlzIG5lZWRlZCBmb3IgdGhlIGFwcGxpY2F0 aW9uIGZsb3dzIHRoYXQgY2Fubm90IGNvcGUgd2l0aCBhIGNoYW5nZSBvZiBJUA0KYWRkcmVzcyBh bmQgd2hlbiBtb2JpbGUgaG9zdHMgb3IgZW50aXJlIG1vYmlsZSBuZXR3b3JrcyBjaGFuZ2UgdGhl aXIgcG9pbnQNCm9mIGF0dGFjaG1lbnQgdG8gdGhlIEludGVybmV0LCBidXQgU0hPVUxEIE5PVCBi ZSB0YWtlbiBhcyB0aGUgZGVmYXVsdCBiZWhhdmlvci48L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9 InNhbnMtc2VyaWYiPg0KPC9mb250Pg0KPGJyPjxmb250IHNpemU9MyBjb2xvcj1ibHVlIGZhY2U9 Ik1WIEJvbGkiPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBDb21tZW50czwvZm9udD4NCjxicj48 Zm9udCBzaXplPTMgY29sb3I9Ymx1ZSBmYWNlPSJNViBCb2xpIj4oMSkgV2hhdCBzY2VuYXJpbyBp cyB0aGF0ICZxdW90O2VudGlyZQ0KbW9iaWxlIG5ldHdvcmtzIGNoYW5nZSB0aGVpciBwb2ludCBv ZiBhdHRhY2htZW50IHRvIHRoZSBpbnRlcm5ldCZxdW90Oz88YnI+DQogJm5ic3A7PC9mb250Pjxm b250IHNpemU9MyBmYWNlPSJDYWxpYnJpIj48YnI+DQpSRVEtMk0gKE1vdGl2YXRpb24gZm9yIFJF US0yKTwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0ic2Fucy1zZXJpZiI+IDwvZm9udD48Zm9udCBz aXplPTMgZmFjZT0iQ2FsaWJyaSI+PGJyPg0KVGhlIGdvYWwgb2YgdGhpcyByZXF1aXJlbWVudCBp cyB0byA8YnI+DQplbmFibGUgbW9yZSBlZmZpY2llbnQgdXNlIG9mIG5ldHdvcmsgcmVzb3VyY2Vz IGFuZCBtb3JlIGVmZmljaWVudCByb3V0aW5nDQpieSBub3QgaW52b2tpbmcgbW9iaWxpdHkgc3Vw cG9ydCB3aGVuIHRoZXJlIGlzIG5vIHN1Y2ggbmVlZC48L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9 InNhbnMtc2VyaWYiPg0KPC9mb250Pjxmb250IHNpemU9MyBmYWNlPSJDYWxpYnJpIj48YnI+DQog PC9mb250Pjxmb250IHNpemU9MyBmYWNlPSJzYW5zLXNlcmlmIj4mbmJzcDs8L2ZvbnQ+PGZvbnQg c2l6ZT0zIGZhY2U9IkNhbGlicmkiPjxicj4NClJFTEVWQU5UIHByb2JsZW06PC9mb250Pjxmb250 IHNpemU9MyBmYWNlPSJzYW5zLXNlcmlmIj4gPC9mb250Pjxmb250IHNpemU9MyBmYWNlPSJDYWxp YnJpIj48YnI+DQpQUzU6IFdhc3RpbmcgcmVzb3VyY2VzIHRvIHN1cHBvcnQgbW9iaWxlIG5vZGVz IG5vdCBuZWVkaW5nIG1vYmlsaXR5IHN1cHBvcnQ8L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9InNh bnMtc2VyaWYiPg0KPC9mb250Pjxmb250IHNpemU9MyBmYWNlPSJDYWxpYnJpIj48YnI+DQpJUCBt b2JpbGl0eSBzdXBwb3J0IGlzIG5vdCBhbHdheXMgcmVxdWlyZWQuIEZvciBleGFtcGxlLCBzb21l IGFwcGxpY2F0aW9ucw0KZG8gbm90IG5lZWQgYSBzdGFibGUgSVAgYWRkcmVzcyBkdXJpbmcgaGFu ZG92ZXIsIGkuZS4gSVAgc2Vzc2lvbiBjb250aW51aXR5Lg0KU29tZXRpbWVzLCB0aGUgZW50aXJl IGFwcGxpY2F0aW9uIHNlc3Npb24gcnVucyB3aGlsZSB0aGUgdGVybWluYWwgZG9lcw0Kbm90IGNo YW5nZSB0aGUgcG9pbnQgb2YgYXR0YWNobWVudC4gSW4gdGhlc2Ugc2l0dWF0aW9ucyB0aGF0IGRv IG5vdCByZXF1aXJlDQpJUCBtb2JpbGl0eSBzdXBwb3J0LCBuZXR3b3JrIHJlc291cmNlcyBhcmUg d2FzdGVkIHdoZW4gbW9iaWxpdHkgY29udGV4dA0KaXMgc2V0IHVwLiBOZXR3b3JrIHJlc291cmNl cyBhcmUgYWxzbyB3YXN0ZWQgd2hlbiB0aGUgdmlhIHJvdXRlcyBhcmUgc2V0DQp1cCBmb3IgbWFu eSBNTnMgdGhhdCBkbyBub3QgcmVxdWlyZSBJUCBtb2JpbGl0eSBzdXBwb3J0LjwvZm9udD48Zm9u dCBzaXplPTMgZmFjZT0ic2Fucy1zZXJpZiI+DQo8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0zIGNv bG9yPWJsdWUgZmFjZT0iTVYgQm9saSI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IENvbW1lbnRz PC9mb250Pg0KPGJyPjxmb250IHNpemU9MyBjb2xvcj1ibHVlIGZhY2U9Ik1WIEJvbGkiPigxKSBJ IGhhdmUgdGhlIHNhbWUgY29uY2Vybg0KYXMgTHVvV2VuIGRvZXMuICZuYnNwO1dlIHNob3VsZCBi ZSBtb3JlIGNsZWFyIHdoYXQgYXJlIHdlIHJlZmVycmluZyB0bw0KZm9yIHRoZSB0ZXJtICZxdW90 O21vYmlsaXR5IGNvbnRleHQmcXVvdDsgaGVyZT8gJm5ic3A7SXQgaXMgYmVjYXVzZSwgdGhlcmUN CndvdWxkIGFsd2F5cyBiZSBjb250ZXh0IHNldCB1cCBmb3IgdGhlIG1vYmlsZSBub2RlIGF0dGFj aGluZyB0byB0aGUgbmV0d29yaw0KcmVnYXJkbGVzcyBpZiB0aGUgSVAgbW9iaWxpdHkgaXMgcmVx dWlyZWQgb3Igbm90LCBzdWNoIGFzIHBlci1NTiBsb2NhbGl6YXRpb24NCmluZm9ybWF0aW9uIGFu ZCBzZWN1cml0eSBjb250ZXh0LiAmbmJzcDtJIGJlbGlldmUgdGhhdCB0aGUgJnF1b3Q7c3BlY2lm aWMmcXVvdDsNCm1vYmlsaXR5IGNvbnRleHQgdGhhdCB5b3UncmUgcmVmZXJyaW5nIGhlcmUgaXMg dGhlIGNvbnRleHQgaW5mbyB0aGF0IHN1cHBvcnRzDQp0aGUgTU4gZm9yIGNoYW5naW5nIHRoZWly IHBvaW50IG9mIGF0dGFjaG1lbnQgdG8gdGhlIG5ldHdvcmsgc3VjaCBhcyB0aGUNCm1vYmlsaXR5 IHR1bm5lbGluZyBpbmZvLiA8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0zIGNvbG9yPWJsdWUgZmFj ZT0iTVYgQm9saSI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgUHJvcG9zZWQNCm5ldyB0ZXh0IDwvZm9u dD4NCjxicj48Zm9udCBzaXplPTMgY29sb3I9Ymx1ZSBmYWNlPSJDYWxpYnJpIj5QUzU6IFdhc3Rp bmcgcmVzb3VyY2VzIHRvIHN1cHBvcnQNCm1vYmlsZSBub2RlcyBub3QgbmVlZGluZyBtb2JpbGl0 eSBzdXBwb3J0PC9mb250Pjxmb250IHNpemU9MyBjb2xvcj1ibHVlIGZhY2U9InNhbnMtc2VyaWYi Pg0KPC9mb250Pjxmb250IHNpemU9MyBjb2xvcj1ibHVlIGZhY2U9IkNhbGlicmkiPjxicj4NCklQ IG1vYmlsaXR5IHN1cHBvcnQgaXMgbm90IGFsd2F5cyByZXF1aXJlZC4gRm9yIGV4YW1wbGUsIHNv bWUgYXBwbGljYXRpb25zDQpkbyBub3QgbmVlZCBhIHN0YWJsZSBJUCBhZGRyZXNzIGR1cmluZyBo YW5kb3ZlciwgaS5lLiBJUCBzZXNzaW9uIGNvbnRpbnVpdHkuDQpTb21ldGltZXMsIHRoZSBlbnRp cmUgYXBwbGljYXRpb24gc2Vzc2lvbiBydW5zIHdoaWxlIHRoZSB0ZXJtaW5hbCBkb2VzDQpub3Qg Y2hhbmdlIHRoZSBwb2ludCBvZiBhdHRhY2htZW50LiBJbiB0aGVzZSBzaXR1YXRpb25zIHRoYXQg ZG8gbm90IHJlcXVpcmUNCklQIG1vYmlsaXR5IHN1cHBvcnQsIG5ldHdvcmsgcmVzb3VyY2VzIGFy ZSB3YXN0ZWQgd2hlbiBpbmNsdWRpbmcgYWRkaXRpb25hbA0KaW5mbyB0byB0aGUgbW9iaWxpdHkg Y29udGV4dCB0byBzdXBwb3J0IHRoZSBjaGFuZ2luZyB0aGUgcG9pbnQgb2YgYXR0YWNobWVudC4N Ck5ldHdvcmsgcmVzb3VyY2VzIGFyZSBhbHNvIHdhc3RlZCB3aGVuIHRoZSB2aWEgcm91dGVzIGFy ZSBzZXQgdXAgZm9yIG1hbnkNCk1OcyB0aGF0IGRvIG5vdCByZXF1aXJlIElQIG1vYmlsaXR5IHN1 cHBvcnQuPC9mb250Pjxmb250IHNpemU9MyBjb2xvcj1ibHVlIGZhY2U9InNhbnMtc2VyaWYiPg0K PC9mb250Pg0KPGJyPjxmb250IHNpemU9MyBmYWNlPSJDYWxpYnJpIj48YnI+DQogPC9mb250Pjxm b250IHNpemU9MyBmYWNlPSJzYW5zLXNlcmlmIj4mbmJzcDs8L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZh Y2U9IkNhbGlicmkiPjxicj4NCk9USEVSIHJlbGF0ZWQgcHJvYmxlbTwvZm9udD48Zm9udCBzaXpl PTMgZmFjZT0ic2Fucy1zZXJpZiI+IDwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0iQ2FsaWJyaSI+ PGJyPg0KTy1QUzE6IE1vYmlsaXR5IHNpZ25hbGluZyBvdmVyaGVhZCB3aXRoIHBlZXItdG8tcGVl ciBjb21tdW5pY2F0aW9uPC9mb250Pjxmb250IHNpemU9MyBmYWNlPSJzYW5zLXNlcmlmIj4NCjwv Zm9udD48Zm9udCBzaXplPTMgZmFjZT0iQ2FsaWJyaSI+PGJyPg0KV2hpbGUgbW9iaWxpdHkgbWFu YWdlbWVudCBlbmFibGVzIGEgbW9iaWxlIGhvc3QgdG8gYmUgcmVhY2hhYmxlLCB0aGUgaG9zdHMN Cm1heSB0aGVuIGNvbW11bmljYXRlIGRpcmVjdGx5IHNvIHRoYXQgdGhlIG1vYmlsaXR5IHN1cHBv cnQgaXMgbm8gbG9uZ2VyDQpuZWVkZWQuIFRha2luZyB0aGUgbmVlZCBvZiBtb2JpbGl0eSBzdXBw b3J0IGFzIHRoZSBkZWZhdWx0IGJlaGF2aW9yIHdpbGwNCndhc3RlIG5ldHdvcmsgcmVzb3VyY2Vz LiA8YnI+DQpPLVBTMjogTGFjayBvZiB1c2VyLWNlbnRyaWNpdHk8L2ZvbnQ+PGZvbnQgc2l6ZT0z IGZhY2U9InNhbnMtc2VyaWYiPiA8L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9IkNhbGlicmkiPjxi cj4NCkNlbnRyYWxpemVkIGRlcGxveW1lbnQgY29tcGFyZWQgd2l0aCBkaXN0cmlidXRlZCBtb2Jp bGl0eSBtYW5hZ2VtZW50IG1heQ0KYmUgbGVzcyBjYXBhYmxlIHRvIHN1cHBvcnQgdXNlci1jZW50 cmljaXR5LiBFeGFtcGxlIGluIHRoZSBsYWNrIG9mIHVzZXItY2VudHJpY2l0eQ0KaXMgdG8gcHJv dmlkZSBtb2JpbGl0eSBzdXBwb3J0IHRvIGFsbCBtb2JpbGUgbm9kZXMgYnkgZGVmYXVsdCByZWdh cmRsZXNzDQpvZiB3aGV0aGVyIHRoZSB1c2VyIG5lZWRzIGl0IG9yIG5vdC48L2ZvbnQ+PGZvbnQg c2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYiPg0KPC9mb250Pjxmb250IHNpemU9MyBmYWNlPSJDYWxp YnJpIj48YnI+DQogPC9mb250Pjxmb250IHNpemU9MyBmYWNlPSJzYW5zLXNlcmlmIj4mbmJzcDs8 L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9IkNhbGlicmkiPjxicj4NCihUaGUgYWJvdmUgaGFzIGJl ZW4gZHJhZnRlZCB3aXRoIGNvbnRyaWJ1dGlvbnMsIGlucHV0cyBhbmQgZGlzY3Vzc2lvbnMNCmZy b20gdmFyaW91cyBwZW9wbGUuIEFkZGl0aW9uYWwgY29udHJpYnV0aW9ucyBhbmQgY29tbWVudHMg YXJlIG1vc3Qgd2VsY29tZS4pPC9mb250Pjxmb250IHNpemU9MyBmYWNlPSJzYW5zLXNlcmlmIj4N CjwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0iQ2FsaWJyaSI+PGJyPg0KIDwvZm9udD48Zm9udCBz aXplPTMgZmFjZT0ic2Fucy1zZXJpZiI+Jm5ic3A7PC9mb250Pjxmb250IHNpemU9MyBmYWNlPSJD YWxpYnJpIj48YnI+DQpIIEFudGhvbnkgQ2hhbjwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0ic2Fu cy1zZXJpZiI+PGJyPg0KPC9mb250Pjxmb250IHNpemU9MiBmYWNlPSJDYWxpYnJpIj48YnI+DQog PC9mb250Pjx0dD48Zm9udCBzaXplPTI+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX188YnI+DQpkbW0gbWFpbGluZyBsaXN0PGJyPg0KZG1tQGlldGYub3JnPGJy Pg0KPC9mb250PjwvdHQ+PGEgaHJlZj1odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp bmZvL2RtbT48dHQ+PGZvbnQgc2l6ZT0yPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz dGluZm8vZG1tPC9mb250PjwvdHQ+PC9hPjxmb250IHNpemU9MyBmYWNlPSJzYW5zLXNlcmlmIj48 YnI+DQo8L2ZvbnQ+PHR0Pjxmb250IHNpemU9Mj5fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXzxicj4NCmRtbSBtYWlsaW5nIGxpc3Q8YnI+DQpkbW1AaWV0Zi5v cmc8YnI+DQo8L2ZvbnQ+PC90dD48YSBocmVmPWh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v bGlzdGluZm8vZG1tPjx0dD48Zm9udCBzaXplPTI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h bi9saXN0aW5mby9kbW08L2ZvbnQ+PC90dD48L2E+PHR0Pjxmb250IHNpemU9Mj48YnI+DQo8L2Zv bnQ+PC90dD4NCjxicj4NCjxicj48cHJlPg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NClpURSZuYnNwO0luZm9ybWF0aW9uJm5ic3A7U2Vj dXJpdHkmbmJzcDtOb3RpY2U6Jm5ic3A7VGhlJm5ic3A7aW5mb3JtYXRpb24mbmJzcDtjb250YWlu ZWQmbmJzcDtpbiZuYnNwO3RoaXMmbmJzcDttYWlsJm5ic3A7aXMmbmJzcDtzb2xlbHkmbmJzcDtw cm9wZXJ0eSZuYnNwO29mJm5ic3A7dGhlJm5ic3A7c2VuZGVyJ3MmbmJzcDtvcmdhbml6YXRpb24u Jm5ic3A7VGhpcyZuYnNwO21haWwmbmJzcDtjb21tdW5pY2F0aW9uJm5ic3A7aXMmbmJzcDtjb25m aWRlbnRpYWwuJm5ic3A7UmVjaXBpZW50cyZuYnNwO25hbWVkJm5ic3A7YWJvdmUmbmJzcDthcmUm bmJzcDtvYmxpZ2F0ZWQmbmJzcDt0byZuYnNwO21haW50YWluJm5ic3A7c2VjcmVjeSZuYnNwO2Fu ZCZuYnNwO2FyZSZuYnNwO25vdCZuYnNwO3Blcm1pdHRlZCZuYnNwO3RvJm5ic3A7ZGlzY2xvc2Um bmJzcDt0aGUmbmJzcDtjb250ZW50cyZuYnNwO29mJm5ic3A7dGhpcyZuYnNwO2NvbW11bmljYXRp b24mbmJzcDt0byZuYnNwO290aGVycy4NClRoaXMmbmJzcDtlbWFpbCZuYnNwO2FuZCZuYnNwO2Fu eSZuYnNwO2ZpbGVzJm5ic3A7dHJhbnNtaXR0ZWQmbmJzcDt3aXRoJm5ic3A7aXQmbmJzcDthcmUm bmJzcDtjb25maWRlbnRpYWwmbmJzcDthbmQmbmJzcDtpbnRlbmRlZCZuYnNwO3NvbGVseSZuYnNw O2ZvciZuYnNwO3RoZSZuYnNwO3VzZSZuYnNwO29mJm5ic3A7dGhlJm5ic3A7aW5kaXZpZHVhbCZu YnNwO29yJm5ic3A7ZW50aXR5Jm5ic3A7dG8mbmJzcDt3aG9tJm5ic3A7dGhleSZuYnNwO2FyZSZu YnNwO2FkZHJlc3NlZC4mbmJzcDtJZiZuYnNwO3lvdSZuYnNwO2hhdmUmbmJzcDtyZWNlaXZlZCZu YnNwO3RoaXMmbmJzcDtlbWFpbCZuYnNwO2luJm5ic3A7ZXJyb3ImbmJzcDtwbGVhc2UmbmJzcDtu b3RpZnkmbmJzcDt0aGUmbmJzcDtvcmlnaW5hdG9yJm5ic3A7b2YmbmJzcDt0aGUmbmJzcDttZXNz YWdlLiZuYnNwO0FueSZuYnNwO3ZpZXdzJm5ic3A7ZXhwcmVzc2VkJm5ic3A7aW4mbmJzcDt0aGlz Jm5ic3A7bWVzc2FnZSZuYnNwO2FyZSZuYnNwO3Rob3NlJm5ic3A7b2YmbmJzcDt0aGUmbmJzcDtp bmRpdmlkdWFsJm5ic3A7c2VuZGVyLg0KVGhpcyZuYnNwO21lc3NhZ2UmbmJzcDtoYXMmbmJzcDti ZWVuJm5ic3A7c2Nhbm5lZCZuYnNwO2ZvciZuYnNwO3ZpcnVzZXMmbmJzcDthbmQmbmJzcDtTcGFt Jm5ic3A7YnkmbmJzcDtaVEUmbmJzcDtBbnRpLVNwYW0mbmJzcDtzeXN0ZW0uDQo8L3ByZT4= --=_alternative 007BBE4E882579FE_=-- From jouni.nospam@gmail.com Thu May 17 16:46:01 2012 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8673E21F8757 for ; Thu, 17 May 2012 16:46:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.576 X-Spam-Level: X-Spam-Status: No, score=-3.576 tagged_above=-999 required=5 tests=[AWL=0.023, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 AkcsyaN4rn59 for ; Thu, 17 May 2012 16:46:00 -0700 (PDT) Received: from mail-wi0-f172.google.com (mail-wi0-f172.google.com [209.85.212.172]) by ietfa.amsl.com (Postfix) with ESMTP id 918D021F8742 for ; Thu, 17 May 2012 16:46:00 -0700 (PDT) Received: by wibhj8 with SMTP id hj8so4711080wib.13 for ; Thu, 17 May 2012 16:45:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=ay9Cv7QiUVHdi/OerFiBTg5oOPJqTSEhhZ+dO3CFrL4=; b=Z82isv30fFONY7R6/GO1DJtuOMEglUnaXhEiji5x4lWNUTIfSxTZlXc1rGN+jbqyir wiRlzSmkJNWmAMnIWoJA/B4qlzrzclHDkQF9vgg8XOZMQd67VgskWNTuTAjX7Y5olIxL SiMkl2EBZytSkozn3AUfiY9s0xYECmUFYqQ5azjQoAUGW8nDPgCAMaYPBgT2McCrJt/g iuBTrP1nIU7kWaNhqCWQ65CRPglDRkreAwzzQh5666t7Vmd9zW0bM3cBcTwewzetVPVi VP9oD8nXGL7oKtX0/j0Q3vOqwTZ65ZvS14wk8JRoVGn/PWPrDA0s/Dypij4UTrxzHpZH DJew== Received: by 10.180.24.39 with SMTP id r7mr55301633wif.9.1337298359693; Thu, 17 May 2012 16:45:59 -0700 (PDT) Received: from [188.117.15.106] ([188.117.15.106]) by mx.google.com with ESMTPS id m1sm29383839wic.6.2012.05.17.16.45.54 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 17 May 2012 16:45:57 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: jouni korhonen In-Reply-To: <6E31144C030982429702B11D6746B98C1DDFB507@SZXEML505-MBS.china.huawei.com> Date: Fri, 18 May 2012 02:45:53 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <9170BC9C-68E5-48F4-947F-9126FA8B8CFD@gmail.com> References: <6E31144C030982429702B11D6746B98C1DDFB507@SZXEML505-MBS.china.huawei.com> To: h chan X-Mailer: Apple Mail (2.1084) Cc: "dmm@ietf.org" Subject: Re: [DMM] draft requirement REQ-1: Distributed deployment X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 May 2012 23:46:01 -0000 Breaking the silence.. On May 7, 2012, at 8:55 PM, h chan wrote: > REQ-1: Distributed deployment > IP mobility, network access and routing solutions provided by DMM = SHALL enable the functions of mobility management of IP sessions to be = distributed so that the traffic is routed in an optimal manner without = relying on centrally deployed anchors. Few comments/questions.. o "SHALL enable the functions of mobility management" does that imply = the DMM "solution" must always involve or extend a mobility protocol? IMHO that should not be a SHALL requirement. o "centrally deployed anchors" what if the access network routing is = laid out in a way that even pure IP routing would lead packets to go = through a=20 central site/edge router? Doesn't that lead to similar deficiencies = than with mobility anchors? > =20 > REQ-1M (Motivation for REQ-1) > The goals of this requirement are to > match mobility deployment with current trend in network evolution: = more cost and resource effective to cache and distribute contents when = combining distributed anchors with caching systems (e.g., CDN); improve = scalability; reduce signaling overhead; avoid single point of failure; = mitigate threats being focused on a centrally deployed anchor, e.g., = home agent and local mobility anchor. Reduce signaling overhead.. is a very good goal. However, if any DMM solution builds on top of an existing mobility protocol that hardly reduces anything. Also if setting up optimal routes require establishing new tunnels, signaling is bound to increase. I would say here "does not increase the amount of present signaling" and the aim for solutions that would reduce it somehow. > =20 > RELEVANT problems: > PS1: Non-optimal routes > Routing via a centralized anchor often results in a longer route, and = the problem is especially manifested when accessing a local or cache = server of a Content Delivery Network (CDN). > PS2: Non-optimality in Evolved Network Architecture > The centralized mobility management can become non-optimal as Network = architecture evolves and become more flattened. More flat is kind of superfluous.. take e.g. EPS example. You have, in = an optimal case, an eNodeB connected directly to a combined SGW/PGW from the user = plane point of view. And the SGW/PGW you can allocate close to you eNodeB based on = its topological location. How you can make that more flat? SGW relocation changes the = situation a bit but still.. > PS3: Low scalability of centralized route and mobility context = maintenance > Setting up such special routes and maintaining the mobility context = for each MN is more difficult to scale in a centralized design with a = large number of MNs. Can I assume the mobility context involves a possible per MN tunnel = state? > Distributing the route maintenance function and the mobility context = maintenance function among different networks can be more scalable. > PS4: Single point of failure and attack > Centralized anchoring may be more vulnerable to single point of = failure and attack than a distributed system. > =20 > (The above is drafted with contributions, inputs and discussions from = various people. Additional contributions and comments are most welcome.) > =20 - Jouni > H Anthony Chan >=20 > =20 > _______________________________________________ > dmm mailing list > dmm@ietf.org > https://www.ietf.org/mailman/listinfo/dmm From jouni.nospam@gmail.com Thu May 17 16:57:11 2012 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 92C7121F87D1 for ; Thu, 17 May 2012 16:57:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.578 X-Spam-Level: X-Spam-Status: No, score=-3.578 tagged_above=-999 required=5 tests=[AWL=0.021, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 TBsUXcSPrFKd for ; Thu, 17 May 2012 16:57:11 -0700 (PDT) Received: from mail-wi0-f178.google.com (mail-wi0-f178.google.com [209.85.212.178]) by ietfa.amsl.com (Postfix) with ESMTP id A689F21F87CF for ; Thu, 17 May 2012 16:57:10 -0700 (PDT) Received: by wibhn6 with SMTP id hn6so1976407wib.13 for ; Thu, 17 May 2012 16:57:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=9XXXBzFfptldNl7MwCoZhylA2V7Z+GsyIrXGUmSoCoY=; b=oYetw9rXlJ4hgud6yW5K+fldvGVJBGQnmxKtso61T5iQzyGlg+2mt9KSlO4d6/dDxB XiGEI8+VN3sTtnfrezSzV+HxaoeGg5A/w7kHWemgUGXiBaF70+HEorVJ1enbBxa4+OnD vdd9/tNQTwNK/XW+xSprn7zS+YmVpY7TzUW+qxe2ClRnkkcOVMQu6TfDF5Lg9OzeKykE inG60YFaZJ6VDBA53GNrkxbaZH1pf0P5ztOXbSbw6emMFgRilUFjbtBYzYTXuOGHdvkS bR9mpvYSC3d/xMRHaMjeR9LaYeJV66ljbh9r4S9ISQ4/MjiTs1PtnfFfaTjzEQUlKVQq 0Rog== Received: by 10.180.99.195 with SMTP id es3mr22921546wib.12.1337299029847; Thu, 17 May 2012 16:57:09 -0700 (PDT) Received: from [188.117.15.106] ([188.117.15.106]) by mx.google.com with ESMTPS id z3sm3454079wix.0.2012.05.17.16.57.05 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 17 May 2012 16:57:09 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: jouni korhonen In-Reply-To: <6E31144C030982429702B11D6746B98C1DDFB50C@SZXEML505-MBS.china.huawei.com> Date: Fri, 18 May 2012 02:56:55 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <2630A3D8-5718-4302-AD79-A6680C8CDFB4@gmail.com> References: <6E31144C030982429702B11D6746B98C1DDFB50C@SZXEML505-MBS.china.huawei.com> To: h chan X-Mailer: Apple Mail (2.1084) Cc: "dmm@ietf.org" Subject: Re: [DMM] draft requirement REQ-2: Transparency to Upper Layers X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 May 2012 23:57:11 -0000 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? >=20 > 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? > =20 > 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. > =20 > 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? - Jouni > =20 > (The above has been drafted with contributions, inputs and discussions = from various people. Additional contributions and comments are most = welcome.) > =20 > H Anthony Chan >=20 > =20 > _______________________________________________ > dmm mailing list > dmm@ietf.org > https://www.ietf.org/mailman/listinfo/dmm From jouni.nospam@gmail.com Thu May 17 17:01:13 2012 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B41E21F87FE for ; Thu, 17 May 2012 17:01:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.579 X-Spam-Level: X-Spam-Status: No, score=-3.579 tagged_above=-999 required=5 tests=[AWL=0.020, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 f+YJsrVIPnrf for ; Thu, 17 May 2012 17:01:12 -0700 (PDT) Received: from mail-wg0-f44.google.com (mail-wg0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id 6BCE621F87FD for ; Thu, 17 May 2012 17:01:12 -0700 (PDT) Received: by wgbdr13 with SMTP id dr13so1584105wgb.13 for ; Thu, 17 May 2012 17:01:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=0j97R0eGJj+oKppwi8BXBIIi7H1/HfEfCmogSr6m/KY=; b=B2jq3wZOYbIJ9IC0d3DXggIRCsdK1AguL5I02PO2IqP7cOYiakR6wARzYrHl3nj2ZH IIRuG8tGWmBjI7Mr7bKuwqBGzYgEZOh9csQTQL3DE2G0R8uASsZnAnfvMJqMqaFn2Jj2 gDRyL5WP3U6kcWdFykR02/0YogLbBdBJUZsmg5IBAHMQCT93EIxxTKEE2etKtpj2mKQa X06zYYB9VEeXGg8D7MPDopb9YpJqgH8jiz2657ffOnUByHb6IVGT5igv5S9j/iV/UAxW 8WZypBa7czbRcH12EGCi7iALINiv0qaPHP5Txmkkffcz2yQd6WJmc5FYNofRO73OUl65 Gq5g== Received: by 10.180.98.201 with SMTP id ek9mr21102371wib.7.1337299271472; Thu, 17 May 2012 17:01:11 -0700 (PDT) Received: from [188.117.15.106] ([188.117.15.106]) by mx.google.com with ESMTPS id g10sm51762667wiw.0.2012.05.17.17.01.08 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 17 May 2012 17:01:10 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: jouni korhonen In-Reply-To: <6E31144C030982429702B11D6746B98C1DDFB532@SZXEML505-MBS.china.huawei.com> Date: Fri, 18 May 2012 03:00:23 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <570967EC-D26C-4605-833F-267AD2C5AFD0@gmail.com> References: <6E31144C030982429702B11D6746B98C1DDFB532@SZXEML505-MBS.china.huawei.com> To: h chan X-Mailer: Apple Mail (2.1084) Cc: "dmm@ietf.org" Subject: Re: [DMM] draft requirement REQ-4: compatibility X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 May 2012 00:01:13 -0000 On May 7, 2012, at 9:04 PM, h chan wrote: > REQ-4: compatibility > The DMM solutions SHALL support existing network deployment with IPv6 = (e.g. existing IPv6 address assignment), be compatible with other = mobility protocols, and be interoperable with the network or the mobile = hosts/routers that do not support the DMM enabling protocol so that the = existing network deployments are unaffected. > =20 > REQ-4M (Motivation for REQ-4) > Motivation: The motivation of this requirement is to be able to work = with network architectures of both hierarchical networks and flattened = networks, so that the mobility management protocol possesses enough = flexibility to support different networks, and so that the existing = networks and hosts are not affected and do not break. Isn't the motivation just "SHALL not break existing network deployments = and end hosts" ? Either the network or the host may not have any idea of the solutions = developed in DMM. - JOuni > =20 > OTHER related problem > O-PS3: Complicated deployment with too many variants and extensions of = MIP > Deployment is complicated with many variants and extensions of MIP. = When introducing new functions which may add to the complicity, existing = solutions are more vulnerable to break. > =20 > (The above has been drafted with contributions, inputs and discussions = from various people. Additional contributions and comments are most = welcome.) > =20 > H Anthony Chan >=20 > =20 > _______________________________________________ > dmm mailing list > dmm@ietf.org > https://www.ietf.org/mailman/listinfo/dmm From jouni.nospam@gmail.com Thu May 17 17:03:06 2012 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A24A11E8083 for ; Thu, 17 May 2012 17:03:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.58 X-Spam-Level: X-Spam-Status: No, score=-3.58 tagged_above=-999 required=5 tests=[AWL=0.019, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 MvUTN6GRH862 for ; Thu, 17 May 2012 17:03:05 -0700 (PDT) Received: from mail-wi0-f172.google.com (mail-wi0-f172.google.com [209.85.212.172]) by ietfa.amsl.com (Postfix) with ESMTP id 91C0311E8080 for ; Thu, 17 May 2012 17:03:05 -0700 (PDT) Received: by wibhj8 with SMTP id hj8so4717339wib.13 for ; Thu, 17 May 2012 17:03:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=8OHAdBmjHpVwszG0gTa88AxiWFwdcDTSh7ALGgRz4IM=; b=vAPX8Bs0Ip+KNEgiCbX+aVLhCUvXRBUiBZH18Vnsm/LI69i7uUI8jj0SnfePtlTycK 29GRdM/QmcxDQqOwM3peqmsWTwCsBEU0tvB9zUIfnHJJid2Gpxku0yQQJRnHPo35zIq7 lW4XE4xDOu/Z0ySDJqDuBBciJvIZvNP9DeAuBTfJE0UBG6jPaAITKLCLSlmrR2+Mx3Mp 93bYxJUOkuz+0eu3yVCoqKOVfKVtMV3XZL0YUV1+4C9LYcqvS37iJurVbmwHbEOGk3hy hzi13aAZYuIuFjn0KO4xFLgtsUpnUQ4HjRPZznuV4bLi52V3rSM79bN7FGin77lTe+us Yspg== Received: by 10.180.80.35 with SMTP id o3mr23015364wix.7.1337299384815; Thu, 17 May 2012 17:03:04 -0700 (PDT) Received: from [188.117.15.106] ([188.117.15.106]) by mx.google.com with ESMTPS id gb9sm7813183wib.8.2012.05.17.17.02.49 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 17 May 2012 17:03:02 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: jouni korhonen In-Reply-To: <6E31144C030982429702B11D6746B98C1DDFB537@SZXEML505-MBS.china.huawei.com> Date: Fri, 18 May 2012 03:02:45 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <3436461C-2DF8-4E14-8889-323AEF4AA079@gmail.com> References: <6E31144C030982429702B11D6746B98C1DDFB537@SZXEML505-MBS.china.huawei.com> To: h chan X-Mailer: Apple Mail (2.1084) Cc: "dmm@ietf.org" Subject: Re: [DMM] draft requirement REQ-5: Mobile IP based X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 May 2012 00:03:06 -0000 On May 7, 2012, at 9:11 PM, h chan wrote: > REQ-5: Mobile IP based > The DMM solutions based on existing host- or network-based mobility = protocols, such as Mobile IPv6 [RFC6275, 5555], Proxy Mobile IPv6 = [RFC5213, 5844] and NEMO [RFC3963], SHOULD be preferred, unless they = fail to meet any of the other requirements. What about something on the lines with: "A DMM solution that relies on a mobility protocol should be based on existing mobility protocol, such as .." - Jouni > REQ-5M (Motivation for REQ-5) > The motivation is to reuse the existing protocol first before = considering new protocols. > =20 > (The above has been drafted with contributions, inputs and discussions = from various people. Additional contributions and comments are most = welcome.) > =20 > H Anthony Chan >=20 > =20 > _______________________________________________ > dmm mailing list > dmm@ietf.org > https://www.ietf.org/mailman/listinfo/dmm From jouni.nospam@gmail.com Thu May 17 17:07:52 2012 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC58E21F86A4 for ; Thu, 17 May 2012 17:07:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.581 X-Spam-Level: X-Spam-Status: No, score=-3.581 tagged_above=-999 required=5 tests=[AWL=0.018, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 DveZb8uw8bbV for ; Thu, 17 May 2012 17:07:52 -0700 (PDT) Received: from mail-wi0-f178.google.com (mail-wi0-f178.google.com [209.85.212.178]) by ietfa.amsl.com (Postfix) with ESMTP id 19CA521F869F for ; Thu, 17 May 2012 17:07:51 -0700 (PDT) Received: by wibhn6 with SMTP id hn6so1980423wib.13 for ; Thu, 17 May 2012 17:07:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=XDBSVvrGepkaklJ2lYhVB0GAqKo0MWBKxFUoA/V0yG4=; b=h4SqfG9bMCPIZrLOY42qP3qVzFC87cskiDxB4IgciCif11mSEP/jOSTmaOlKXKBvdZ kbw744/g853xyMKjqQLBP3s3zD4OuGIUPRN0QzQYWJkCsaGL7WYa0KJhKbOHOpJc+LZF ohWHoaq2t9ir6vvv2qVCp/+QxMHUOTEH+y+QYGSzo/rJOlU/M6gno70CxeQConakgF0Q xG+rortFR1UTQqxoHT5ZfZEkWSMYocUq2fCL54ZXI+JMdSsPuHYbiCQm9ekBxqMaTzk9 6xOeMXi9kDFuszP9lVa2/pn4T9ThH9/JX/rIKcRCYvSobE/NJDNVM0vA5KAiBBKVoEyT YYcw== Received: by 10.216.141.223 with SMTP id g73mr5509878wej.64.1337299671249; Thu, 17 May 2012 17:07:51 -0700 (PDT) Received: from [188.117.15.106] ([188.117.15.106]) by mx.google.com with ESMTPS id bn9sm60527717wib.5.2012.05.17.17.07.42 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 17 May 2012 17:07:45 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: jouni korhonen In-Reply-To: <6E31144C030982429702B11D6746B98C1DDFB53C@SZXEML505-MBS.china.huawei.com> Date: Fri, 18 May 2012 03:07:40 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <122078D1-58A4-4B35-AAEF-65AE250F8479@gmail.com> References: <6E31144C030982429702B11D6746B98C1DDFB53C@SZXEML505-MBS.china.huawei.com> To: h chan X-Mailer: Apple Mail (2.1084) Cc: "dmm@ietf.org" Subject: Re: [DMM] draft requirement REQ-6: authentication and authorization X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 May 2012 00:07:52 -0000 On May 7, 2012, at 9:14 PM, h chan wrote: > REQ-6: Mutual authentication and authorization to access to the DMM = service. > The protocol solutions for DMM SHALL rely on mutual authentication and = authorization mechanisms that allow a legitimate mobile host/router to = access to the DMM service. Would this requirement rule out e.g. use of IPv6 NDP for DMM purposes unless SeND is also deployed? - Jouni > =20 > REQ-6M (Motivation and problem statement) > Mutual authentication and authorization between a mobile host/router = and an access router providing the DMM service to the mobile host/router = are required to prevent potential attacks in the access network of the = DMM service. Otherwise, various attacks such as impersonation, denial of = service, man-in-the-middle attacks, etc are present to obtain = illegitimate access or to collapse the DMM service. > =20 > (The above has been drafted with contributions, inputs and discussions = from various people. Additional contributions and comments are most = welcome.) > =20 > H Anthony Chan >=20 > =20 > _______________________________________________ > dmm mailing list > dmm@ietf.org > https://www.ietf.org/mailman/listinfo/dmm From jouni.nospam@gmail.com Thu May 17 17:13:47 2012 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A89E21F86EB for ; Thu, 17 May 2012 17:13:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.582 X-Spam-Level: X-Spam-Status: No, score=-3.582 tagged_above=-999 required=5 tests=[AWL=0.017, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 tmfGYu7Meo6O for ; Thu, 17 May 2012 17:13:36 -0700 (PDT) Received: from mail-we0-f172.google.com (mail-we0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id D0D5021F86C1 for ; Thu, 17 May 2012 17:13:35 -0700 (PDT) Received: by werb13 with SMTP id b13so163769wer.31 for ; Thu, 17 May 2012 17:13:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=RDyxtS2WujLsDr+3OQa83300ncLHw8H9sMk/kGglWaY=; b=Dw0lIk/pDCANW9HlOsrgrJQSMT1j8btUvWzWejj2FcsXZ9HNIeg7X+oDJOl3oBlrEa udwuDidlDN+d0/kT4U4TzAlBFucetYkPhqhg75UaaYqNOmBMpUTM4Y1Jgvly0hkSBEVq 8v+HwKwS4ghylLEZ4XFe00Zi41CbxJmVMIdaGdCeUkVHcuNMrcGV9orue64QEJ+jFp4o 2JQK8Ljllg/e4VtrRBuHnd9F1E5f7xK9C5IBYPu1SB+WW1zKgT+LCL0id1oV/ecNsHQ9 Fobo800cGbQOyrtNB3niOh1I0e6j1PGMCmTHbjooMCKa+w5ewG7gmNRFYmlTK3benZ+R eZfQ== Received: by 10.180.78.105 with SMTP id a9mr54624416wix.20.1337300014838; Thu, 17 May 2012 17:13:34 -0700 (PDT) Received: from [188.117.15.106] ([188.117.15.106]) by mx.google.com with ESMTPS id k6sm60571147wiy.7.2012.05.17.17.13.22 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 17 May 2012 17:13:34 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: jouni korhonen In-Reply-To: <6E31144C030982429702B11D6746B98C1DDFB541@SZXEML505-MBS.china.huawei.com> Date: Fri, 18 May 2012 03:13:20 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <0DB45913-24E5-44E2-AE6A-269DE8DC8949@gmail.com> References: <6E31144C030982429702B11D6746B98C1DDFB541@SZXEML505-MBS.china.huawei.com> To: h chan X-Mailer: Apple Mail (2.1084) Cc: "dmm@ietf.org" Subject: Re: [DMM] draft requirement REQ-7: Signaling message protection X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 May 2012 00:13:47 -0000 I would consider grouping REQ-6 and REQ-7 as a minimum security = requirements for a DMM solution.. - Jouni On May 7, 2012, at 9:15 PM, h chan wrote: > REQ-7: Signaling message protection > Signaling messages of the protocol solutions for DMM SHALL be = protected in terms of authentication, data integrity, and data = confidentiality. Data confidentiality to signaling messages SHALL be = opt-in or opt-out depending on network environments or user = requirements. > =20 > REQ-7M (Motivation and problem statement) > Signaling messages are subject to various attacks since those messages = carry context of a mobile host/router. For instance, a malicious node = can forge and send a number of signaling messages to redirect traffic to = a specific node. The result of such an attack is both the specific node = becomes under a denial of service attack and other nodes do not receive = their traffic. As signaling messages travel over the Internet, the = end-to-end security is required. > =20 > =20 > (The above has been drafted with contributions, inputs and discussions = from various people. Additional contributions and comments are most = welcome.) > =20 > H Anthony Chan >=20 > =20 > _______________________________________________ > dmm mailing list > dmm@ietf.org > https://www.ietf.org/mailman/listinfo/dmm From rkoodli@cisco.com Thu May 17 17:07:45 2012 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 65B8321F85B5 for ; Thu, 17 May 2012 17:07:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.483 X-Spam-Level: X-Spam-Status: No, score=-110.483 tagged_above=-999 required=5 tests=[AWL=0.116, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] 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 8yM22vH2AS3e for ; Thu, 17 May 2012 17:07:44 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id 97B6A21F85A5 for ; Thu, 17 May 2012 17:07:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=rkoodli@cisco.com; l=3517; q=dns/txt; s=iport; t=1337299664; x=1338509264; h=date:subject:from:to:cc:message-id:in-reply-to: mime-version:content-transfer-encoding; bh=SAPwan1PSIpHgh5Gi+FhpZcPSpxyIWonaI2TE7QG+dk=; b=jjmoNdZFE3xaDJtYJHLg2gVtEwlDkSVqEqXElm3LsZiy0q5u8oM5tNC7 9jirZQW5g43Gobf+bg+GyGbw79GqEUEobowpsOb6n2C+9rVMtHcWCSOuc bOy+mzJcAgCvilWiTXhunfAWvIlSH2pcpQj2/Ae9cvJ2wT1iWIHbrRvPz s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAF6RtU+tJXHB/2dsb2JhbABFs1GBB4IVAQEBAwEBAQEPAScCATELEgEIGE8GMAEBBAENBRsHh14DBgULnCGWGw2JTwSKFm6FSwOIW4x/ix6DGIFkgwk X-IronPort-AV: E=Sophos;i="4.75,613,1330905600"; d="scan'208";a="84276153" Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by rcdn-iport-2.cisco.com with ESMTP; 18 May 2012 00:07:44 +0000 Received: from xbh-rcd-101.cisco.com (xbh-rcd-101.cisco.com [72.163.62.138]) by rcdn-core2-6.cisco.com (8.14.3/8.14.3) with ESMTP id q4I07ifd023860; Fri, 18 May 2012 00:07:44 GMT Received: from xmb-rcd-214.cisco.com ([72.163.62.221]) by xbh-rcd-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 17 May 2012 19:07:44 -0500 Received: from 10.21.94.233 ([10.21.94.233]) by XMB-RCD-214.cisco.com ([72.163.62.221]) with Microsoft Exchange Server HTTP-DAV ; Fri, 18 May 2012 00:07:43 +0000 User-Agent: Microsoft-Entourage/12.24.0.100205 Date: Thu, 17 May 2012 17:14:15 -0700 From: Rajeev Koodli To: jouni korhonen , h chan Message-ID: Thread-Topic: [DMM] draft requirement REQ-2: Transparency to Upper Layers Thread-Index: Ac00iyibcM4m2A3Z9k6Dz8Pn1dwaWQ== In-Reply-To: <2630A3D8-5718-4302-AD79-A6680C8CDFB4@gmail.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 18 May 2012 00:07:44.0042 (UTC) FILETIME=[3F9430A0:01CD348A] X-Mailman-Approved-At: Thu, 17 May 2012 21:31:23 -0700 Cc: "dmm@ietf.org" Subject: Re: [DMM] draft requirement REQ-2: Transparency to Upper Layers X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 May 2012 00:07:45 -0000 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" 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? > >> >> 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? > >> >> 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? > > - 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 >> dmm@ietf.org >> https://www.ietf.org/mailman/listinfo/dmm > > _______________________________________________ > dmm mailing list > dmm@ietf.org > https://www.ietf.org/mailman/listinfo/dmm From jonghyouk@gmail.com Fri May 18 05:09:20 2012 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E5E7C21F866E for ; Fri, 18 May 2012 05:09:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.448 X-Spam-Level: X-Spam-Status: No, score=-3.448 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] 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 P9YZ3fYQKhF5 for ; Fri, 18 May 2012 05:09:20 -0700 (PDT) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id 27C2021F85F7 for ; Fri, 18 May 2012 05:09:20 -0700 (PDT) Received: by yhq56 with SMTP id 56so3293769yhq.31 for ; Fri, 18 May 2012 05:09:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=SrhXhwxHT3f8RKTALKqNbcIznQQXh6BTbhNiYWF6GwA=; b=A5L+KlA8yzN9dYKb+iHOs1dSYpIbQfy3PSZEPFjRppVqrsdb+7LFRUF98ufbMLYTuU olrGLOyrJY9hmCHufdeGyzjf0IYx1RUsgjcPbeiOEmyR3FGQF/yet+qXchP3g33Yt1iA sB5/y80+S+TuJWf1UpMx418PLx96eBN1wgR3taEiUN4Gr8nydSLXXnKf/K6JYZKRM80f BYQjGkAbhAsm2vGMkrP7yDftfeFuxTxr2u05Zkb7BUEGRY1K41bGSaAWVWdvlLndOj4n KZnTL/pm0/vlmOBUmIqI4Nh+QMpY3dqJBCQgLy9LR3bemPbADMyxnjZ5CgIAwl7YnYiX btxQ== MIME-Version: 1.0 Received: by 10.50.104.166 with SMTP id gf6mr266644igb.35.1337342959255; Fri, 18 May 2012 05:09:19 -0700 (PDT) Received: by 10.64.127.98 with HTTP; Fri, 18 May 2012 05:09:19 -0700 (PDT) In-Reply-To: <122078D1-58A4-4B35-AAEF-65AE250F8479@gmail.com> References: <6E31144C030982429702B11D6746B98C1DDFB53C@SZXEML505-MBS.china.huawei.com> <122078D1-58A4-4B35-AAEF-65AE250F8479@gmail.com> Date: Fri, 18 May 2012 14:09:19 +0200 Message-ID: From: Jong-Hyouk Lee To: jouni korhonen Content-Type: multipart/alternative; boundary=e89a8f234341077faf04c04e6c24 Cc: "dmm@ietf.org" Subject: Re: [DMM] draft requirement REQ-6: authentication and authorization X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 May 2012 12:09:21 -0000 --e89a8f234341077faf04c04e6c24 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Jouni, This requirement is for access network security between a mobile node and an access router. The actual link is required to be protected with L2 (link-layer) or L3 (IP layer) security protection. Then, it is expected to be protected with mostly L2 security protection; in this case, the use of SeND is not required. If L2 security protection is not provided for access network security, L3 security protection, e.g., SeND, is required. When we developed this requirement, we didn=E2=80=99t consider to rule out = the use of NDP in any case. Cheers. On Fri, May 18, 2012 at 2:07 AM, jouni korhonen wro= te: > > On May 7, 2012, at 9:14 PM, h chan wrote: > > > REQ-6: Mutual authentication and authorization to access to the DMM > service. > > The protocol solutions for DMM SHALL rely on mutual authentication and > authorization mechanisms that allow a legitimate mobile host/router to > access to the DMM service. > > Would this requirement rule out e.g. use of IPv6 NDP for DMM > purposes unless SeND is also deployed? > > > - Jouni > > > > > REQ-6M (Motivation and problem statement) > > Mutual authentication and authorization between a mobile host/router an= d > an access router providing the DMM service to the mobile host/router are > required to prevent potential attacks in the access network of the DMM > service. Otherwise, various attacks such as impersonation, denial of > service, man-in-the-middle attacks, etc are present to obtain illegitimat= e > access or to collapse the DMM service. > > > > (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 > > dmm@ietf.org > > https://www.ietf.org/mailman/listinfo/dmm > > _______________________________________________ > dmm mailing list > dmm@ietf.org > https://www.ietf.org/mailman/listinfo/dmm > --=20 RSM Department, TELECOM Bretagne, France Jong-Hyouk Lee, living somewhere between /dev/null and /dev/random #email: jonghyouk (at) gmail (dot) com #webpage: http://sites.google.com/site/hurryon/ --e89a8f234341077faf04c04e6c24 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Jouni,

This requirement is for access network secur= ity between a mobile node and an access router. The actual link is required= to be protected with L2 (link-layer) or L3 (IP layer) security protection.= Then, it is expected to be protected with mostly L2 security protection; i= n this case, the use of SeND is not required. If L2 security protection is = not provided for access network security, L3 security protection, e.g., SeN= D, is required.

When we developed this requirement, we didn=E2=80=99t c= onsider to rule out the use of NDP in any case.

Ch= eers.

On Fri, May 18, 2012 at 2:07 AM, = jouni korhonen <jouni.nospam@gmail.com> wrote:

On May 7, 2012, at 9:14 PM, h chan wrote:

> REQ-6: Mutual authentication and authorization to access to the DMM se= rvice.
> The protocol solutions for DMM SHALL rely on mutual authentication and= authorization mechanisms that allow a legitimate mobile host/router to acc= ess to the DMM service.

Would this requirement rule out e.g. use of IPv6 NDP for DMM
purposes unless SeND is also deployed?


- Jouni

>
> REQ-6M (Motivation and problem statement)
> Mutual authentication and authorization between a mobile host/router a= nd an access router providing the DMM service to the mobile host/router are= required to prevent potential attacks in the access network of the DMM ser= vice. Otherwise, various attacks such as impersonation, denial of service, = man-in-the-middle attacks, etc are present to obtain illegitimate access or= to collapse the DMM service.
>
> (The above has been drafted with contributions, inputs and discussions= from various people. Additional contributions and comments are most welcom= e.)
>
> H Anthony Chan
>
>
> _______________________________________________
> dmm mailing list
> dmm@ietf.org
> https://www.ietf.org/mailman/listinfo/dmm

_______________________________________________
dmm mailing list
dmm@ietf.org
htt= ps://www.ietf.org/mailman/listinfo/dmm



--
RSM Dep= artment, TELECOM Bretagne, France
Jong-Hyouk Lee, living somewher= e between /dev/null and /dev/random

#email:=C2=A0j= onghyouk (at) gmail (dot) com

--e89a8f234341077faf04c04e6c24-- From jonghyouk@gmail.com Fri May 18 05:12:38 2012 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5ACC921F8582 for ; Fri, 18 May 2012 05:12:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.498 X-Spam-Level: X-Spam-Status: No, score=-3.498 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] 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 94fiup6RkxNf for ; Fri, 18 May 2012 05:12:37 -0700 (PDT) Received: from mail-gg0-f172.google.com (mail-gg0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id 943F521F857F for ; Fri, 18 May 2012 05:12:37 -0700 (PDT) Received: by ggnc4 with SMTP id c4so3237093ggn.31 for ; Fri, 18 May 2012 05:12:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=favILH/SSzKrCd5dQKKvBMHDjKgPwtznk8SeA1AaFb8=; b=mtZkmD0uiz7b5AS8qS7cNnfU8RVECpQdjCZo+dD8oOASgeD05T4sVeqb5raZ577emU s4SEliEvh3oeGVupLGOOcRG2qfBLcNv4336VfeNf1DzRwQfXsY4tStCauL0FyEU8boeQ cl4SBcIzGGGU3uDXaaWNSJ0/igAiqW0IByRTf4hfP0tBUI5T1I0f5nbFg0u6jbloJeGM jAuw8YJ7/2alDSI9dMLTGKcNOTByAfVi9kO2eemI1m1n94J4/dB/Jq/LnleLOWud7ow4 rjrKC1dE+pAVhhzw92Ctwl8WWrfzjy0gD4MJ3JGTfcF6pj1tEKQ2oTyVEdAUuh9LSP8R r3nQ== MIME-Version: 1.0 Received: by 10.50.159.134 with SMTP id xc6mr273746igb.41.1337343157024; Fri, 18 May 2012 05:12:37 -0700 (PDT) Received: by 10.64.127.98 with HTTP; Fri, 18 May 2012 05:12:36 -0700 (PDT) In-Reply-To: <0DB45913-24E5-44E2-AE6A-269DE8DC8949@gmail.com> References: <6E31144C030982429702B11D6746B98C1DDFB541@SZXEML505-MBS.china.huawei.com> <0DB45913-24E5-44E2-AE6A-269DE8DC8949@gmail.com> Date: Fri, 18 May 2012 14:12:36 +0200 Message-ID: From: Jong-Hyouk Lee To: jouni korhonen Content-Type: multipart/alternative; boundary=14dae9340e33d1376104c04e77f0 Cc: "dmm@ietf.org" Subject: Re: [DMM] draft requirement REQ-7: Signaling message protection X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 May 2012 12:12:38 -0000 --14dae9340e33d1376104c04e77f0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Jouni, The requirement 6 is for access network security, whereas the requirement 7 is for end-to-end security. Agree; those are the minimum security requirements. But, I=E2=80=99m not su= re if it would be better to merge them into one. We cannot stress enough how important these are. ;) Cheers. On Fri, May 18, 2012 at 2:13 AM, jouni korhonen wro= te: > > I would consider grouping REQ-6 and REQ-7 as a minimum security > requirements > for a DMM solution.. > > - Jouni > > On May 7, 2012, at 9:15 PM, h chan wrote: > > > REQ-7: Signaling message protection > > Signaling messages of the protocol solutions for DMM SHALL be protected > in terms of authentication, data integrity, and data confidentiality. Dat= a > confidentiality to signaling messages SHALL be opt-in or opt-out dependin= g > on network environments or user requirements. > > > > REQ-7M (Motivation and problem statement) > > Signaling messages are subject to various attacks since those messages > carry context of a mobile host/router. For instance, a malicious node can > forge and send a number of signaling messages to redirect traffic to a > specific node. The result of such an attack is both the specific node > becomes under a denial of service attack and other nodes do not receive > their traffic. As signaling messages travel over the Internet, the > end-to-end security is required. > > > > > > (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 > > dmm@ietf.org > > https://www.ietf.org/mailman/listinfo/dmm > > _______________________________________________ > dmm mailing list > dmm@ietf.org > https://www.ietf.org/mailman/listinfo/dmm > --=20 RSM Department, TELECOM Bretagne, France Jong-Hyouk Lee, living somewhere between /dev/null and /dev/random #email: jonghyouk (at) gmail (dot) com #webpage: http://sites.google.com/site/hurryon/ --14dae9340e33d1376104c04e77f0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Jouni,

The requirement 6 is for access network security,= whereas the=C2=A0requirement=C2=A07 is for end-to-end security.=C2=A0

Agree; those are the minimum security requirements. Bu= t, I=E2=80=99m not sure if it would be better to merge them into one.=C2=A0= We cannot stress enough how important these are. ;)

Cheers.

On Fri, May 1= 8, 2012 at 2:13 AM, jouni korhonen <jouni.nospam@gmail.com> wrote:

I would consider grouping REQ-6 and REQ-7 as a minimum security requirement= s
for a DMM solution..

- Jouni

On May 7, 2012, at 9:15 PM, h chan wrote:

> REQ-7: Signaling message protection
> Signaling messages of the protocol solutions for DMM SHALL be protecte= d in terms of authentication, data integrity, and data confidentiality. Dat= a confidentiality to signaling messages SHALL be opt-in or opt-out dependin= g on network environments or user requirements.
>
> REQ-7M (Motivation and problem statement)
> Signaling messages are subject to various attacks since those messages= carry context of a mobile host/router. For instance, a malicious node can = forge and send a number of signaling messages to redirect traffic to a spec= ific node. The result of such an attack is both the specific node becomes u= nder a denial of service attack and other nodes do not receive their traffi= c. As signaling messages travel over the Internet, the end-to-end security = is required.
>
>
> (The above has been drafted with contributions, inputs and discussions= from various people. Additional contributions and comments are most welcom= e.)
>
> H Anthony Chan
>
>
> _______________________________________________
> dmm mailing list
> dmm@ietf.org
> https://www.ietf.org/mailman/listinfo/dmm

_______________________________________________
dmm mailing list
dmm@ietf.org
htt= ps://www.ietf.org/mailman/listinfo/dmm



--
RSM Dep= artment, TELECOM Bretagne, France
Jong-Hyouk Lee, living somewher= e between /dev/null and /dev/random

#email:=C2=A0j= onghyouk (at) gmail (dot) com

--14dae9340e33d1376104c04e77f0-- From Peter.McCann@huawei.com Fri May 18 07:39:12 2012 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA64221F8650 for ; Fri, 18 May 2012 07:39:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.599 X-Spam-Level: X-Spam-Status: No, score=-4.599 tagged_above=-999 required=5 tests=[AWL=2.000, 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 SXzqePNhUcJv for ; Fri, 18 May 2012 07:39:11 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id 1B3C121F864D for ; Fri, 18 May 2012 07:39:11 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml202-edg.china.huawei.com) ([172.18.9.243]) by dfwrg01-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AGH74862; Fri, 18 May 2012 10:39:10 -0400 (EDT) Received: from DFWEML407-HUB.china.huawei.com (10.193.5.132) by dfweml202-edg.china.huawei.com (172.18.9.108) with Microsoft SMTP Server (TLS) id 14.1.323.3; Fri, 18 May 2012 07:34:54 -0700 Received: from dfweml512-mbx.china.huawei.com ([169.254.1.156]) by dfweml407-hub.china.huawei.com ([10.193.5.132]) with mapi id 14.01.0323.003; Fri, 18 May 2012 07:34:44 -0700 From: Peter McCann To: jouni korhonen , h chan Thread-Topic: [DMM] draft requirement REQ-2: Transparency to Upper Layers Thread-Index: AQHNNIjOdy4Iz0JRzEuH1W1r3jhvK5bPnGNw Date: Fri, 18 May 2012 14:34:43 +0000 Message-ID: <5963DDF1F751474D8DEEFDCDBEE43AE716E04224@dfweml512-mbx.china.huawei.com> References: <6E31144C030982429702B11D6746B98C1DDFB50C@SZXEML505-MBS.china.huawei.com> <2630A3D8-5718-4302-AD79-A6680C8CDFB4@gmail.com> In-Reply-To: <2630A3D8-5718-4302-AD79-A6680C8CDFB4@gmail.com> Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.193.125.205] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "dmm@ietf.org" Subject: Re: [DMM] draft requirement REQ-2: Transparency to Upper Layers X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 May 2012 14:39:12 -0000 Hi, Jouni, jouni korhonen wrote: >=20 > Few comments/questions here: >=20 > On May 7, 2012, at 8:58 PM, h chan wrote: >=20 >> 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. >=20 > "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. =20 >> 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. >=20 > 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. >>=20 >> 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. >=20 > 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 >=20 > - Jouni >=20 >=20 >>=20 >> (The above has been drafted with contributions, inputs and discussions >> from various people. Additional contributions and comments are most >> welcome.) >>=20 >> H Anthony Chan >>=20 >>=20 >> _______________________________________________ >> dmm mailing list >> dmm@ietf.org >> https://www.ietf.org/mailman/listinfo/dmm >=20 > _______________________________________________ > dmm mailing list > dmm@ietf.org > https://www.ietf.org/mailman/listinfo/dmm From Peter.McCann@huawei.com Fri May 18 07:40:37 2012 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 91F3A21F86B7 for ; Fri, 18 May 2012 07:40:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.781 X-Spam-Level: X-Spam-Status: No, score=-4.781 tagged_above=-999 required=5 tests=[AWL=1.818, 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 08eJoCpuAXL4 for ; Fri, 18 May 2012 07:40:36 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id 731FE21F869E for ; Fri, 18 May 2012 07:40:36 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml202-edg.china.huawei.com) ([172.18.9.243]) by dfwrg02-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AGA78182; Fri, 18 May 2012 10:40:36 -0400 (EDT) Received: from DFWEML403-HUB.china.huawei.com (10.193.5.151) by dfweml202-edg.china.huawei.com (172.18.9.108) with Microsoft SMTP Server (TLS) id 14.1.323.3; Fri, 18 May 2012 07:36:53 -0700 Received: from dfweml512-mbx.china.huawei.com ([169.254.1.156]) by dfweml403-hub.china.huawei.com ([10.193.5.151]) with mapi id 14.01.0323.003; Fri, 18 May 2012 07:36:42 -0700 From: Peter McCann To: Rajeev Koodli , jouni korhonen , h chan Thread-Topic: [DMM] draft requirement REQ-2: Transparency to Upper Layers Thread-Index: AQHNNIjOdy4Iz0JRzEuH1W1r3jhvK5bPIpiAgAB5o6A= Date: Fri, 18 May 2012 14:36:42 +0000 Message-ID: <5963DDF1F751474D8DEEFDCDBEE43AE716E04231@dfweml512-mbx.china.huawei.com> References: <2630A3D8-5718-4302-AD79-A6680C8CDFB4@gmail.com> In-Reply-To: Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.193.125.205] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "dmm@ietf.org" Subject: Re: [DMM] draft requirement REQ-2: Transparency to Upper Layers X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 May 2012 14:40:37 -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: >=20 > Hi Jouni, All, >=20 > Sorry if this has been captured before.. >=20 > 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. >=20 > Thanks. >=20 > -Rajeev >=20 >=20 >=20 > On 5/17/12 4:56 PM, "jouni korhonen" wrote: >=20 >>=20 >> Few comments/questions here: >>=20 >> On May 7, 2012, at 8:58 PM, h chan wrote: >>=20 >>> 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. >>=20 >> "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? >>=20 >>>=20 >>> 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. >>=20 >> Does this still mean the mobility support must be implement even if it >> is not used? >>=20 >>>=20 >>> 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. >>>=20 >>> 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. >>=20 >> 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? >>=20 >> - Jouni >>=20 >>=20 >>>=20 >>> (The above has been drafted with contributions, inputs and >>> discussions from various people. Additional contributions and >>> comments are most welcome.) >>>=20 >>> H Anthony Chan >>>=20 >>>=20 >>> _______________________________________________ >>> dmm mailing list >>> dmm@ietf.org >>> https://www.ietf.org/mailman/listinfo/dmm >>=20 >> _______________________________________________ >> dmm mailing list >> dmm@ietf.org >> https://www.ietf.org/mailman/listinfo/dmm >=20 > _______________________________________________ > dmm mailing list > dmm@ietf.org > https://www.ietf.org/mailman/listinfo/dmm From Peter.McCann@huawei.com Fri May 18 07:57:54 2012 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4278221F8610 for ; Fri, 18 May 2012 07:57:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.932 X-Spam-Level: X-Spam-Status: No, score=-4.932 tagged_above=-999 required=5 tests=[AWL=1.667, 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 93D60Jt7JAD0 for ; Fri, 18 May 2012 07:57:53 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id 7757A21F85FB for ; Fri, 18 May 2012 07:57:53 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml201-edg.china.huawei.com) ([172.18.9.243]) by dfwrg02-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AGA79480; Fri, 18 May 2012 10:57:53 -0400 (EDT) Received: from DFWEML405-HUB.china.huawei.com (10.193.5.102) by dfweml201-edg.china.huawei.com (172.18.9.107) with Microsoft SMTP Server (TLS) id 14.1.323.3; Fri, 18 May 2012 07:55:22 -0700 Received: from dfweml512-mbx.china.huawei.com ([169.254.1.156]) by dfweml405-hub.china.huawei.com ([10.193.5.102]) with mapi id 14.01.0323.003; Fri, 18 May 2012 07:55:11 -0700 From: Peter McCann To: jouni korhonen , h chan Thread-Topic: [DMM] draft requirement REQ-1: Distributed deployment Thread-Index: AQHNNIdKPT2eKHwtYEyhuKcyknrUyZbPnxvA Date: Fri, 18 May 2012 14:55:09 +0000 Message-ID: <5963DDF1F751474D8DEEFDCDBEE43AE716E04252@dfweml512-mbx.china.huawei.com> References: <6E31144C030982429702B11D6746B98C1DDFB507@SZXEML505-MBS.china.huawei.com> <9170BC9C-68E5-48F4-947F-9126FA8B8CFD@gmail.com> In-Reply-To: <9170BC9C-68E5-48F4-947F-9126FA8B8CFD@gmail.com> Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.193.125.205] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "dmm@ietf.org" Subject: Re: [DMM] draft requirement REQ-1: Distributed deployment X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 May 2012 14:57:54 -0000 Hi, Jouni, jouni korhonen wrote: > Breaking the silence.. >=20 > On May 7, 2012, at 8:55 PM, h chan wrote: >=20 >> REQ-1: Distributed deployment >> IP mobility, network access and routing solutions provided by DMM >> SHALL enable the functions of mobility management of IP sessions to be >> distributed so that the traffic is routed in an optimal manner without >> relying on centrally deployed anchors. >=20 > Few comments/questions.. > o "SHALL enable the functions of mobility management" does that imply > the > DMM "solution" must always involve or extend a mobility protocol? IMHO > that should not be a SHALL requirement. To the extent that DMM provides an "IP mobility...solution" I think it does involve or extend a mobility protocol. However, I don't think the requirem= ent implies that we will necessarily extend an existing mobility protocol. > o "centrally deployed anchors" what if the access network routing is > laid > out in a way that even pure IP routing would lead packets to go > through a central site/edge router? Doesn't that lead to similar > deficiencies than with mobility anchors? It does indeed, which is why a good network deployment will have redundant back-up paths throughout the network. Unfortunately, it is difficult to provide redundancy when the path involves tunnel state at an anchor point. =20 >> REQ-1M (Motivation for REQ-1) >> The goals of this requirement are to match mobility deployment with >> current trend in network evolution: >> more cost and resource effective to cache and distribute contents when >> combining distributed anchors with caching systems (e.g., CDN); >> improve scalability; reduce signaling overhead; avoid single point of >> failure; mitigate threats being focused on a centrally deployed >> anchor, e.g., home agent and local mobility anchor. >=20 > Reduce signaling overhead.. is a very good goal. However, if any DMM > solution builds on top of an existing mobility protocol that hardly > reduces anything. Also if setting up optimal routes require > establishing new tunnels, signaling is bound to increase. I would say > here "does not increase the amount of present signaling" and the aim > for solutions that would reduce it somehow. It should be possible to completely avoid mobility management signaling when the MN is stationary or doesn't need a fixed address. I would say that reduces signaling. >> RELEVANT problems: >> PS1: Non-optimal routes >> Routing via a centralized anchor often results in a longer route, >> and >> the problem is especially manifested when accessing a local or cache >> server of a Content Delivery Network (CDN). >> PS2: Non-optimality in Evolved Network Architecture The centralized >> mobility management can become non-optimal as Network architecture >> evolves and become more flattened. >=20 > More flat is kind of superfluous.. take e.g. EPS example. You have, in > an optimal case, an eNodeB connected directly to a combined SGW/PGW > from the user plane point of view. And the SGW/PGW you can allocate > close to you eNodeB based on its topological location. How you can > make that more flat? SGW relocation changes the situation a bit but still= .. Putting an SGW/PGW (or an LGW) inside in eNB would indeed be a maximally flat architecture. However, we would then need to deal with a change of anchor point during the life of a session, which is something that wasn't contemplated by 3GPP. That is exactly the area that DMM should focus on, IMHO. >> PS3: Low scalability of centralized route and mobility context >> maintenance Setting up such special routes and maintaining the >> mobility context for each MN is more difficult to scale in a >> centralized design with a large number of MNs. >=20 > Can I assume the mobility context involves a possible per MN tunnel > state? Yes, I think the per-MN tunnel state is part of the mobility context being talked about here. -Pete >> Distributing the route maintenance function and the mobility context >> maintenance function among different networks can be more scalable. >> PS4: Single point of failure and attack Centralized anchoring may be >> more vulnerable to single point of failure and attack than a >> distributed system. >>=20 >> (The above is drafted with contributions, inputs and discussions >> from various people. Additional contributions and comments are most >> welcome.) >>=20 >=20 > - Jouni >=20 >=20 >=20 >> H Anthony Chan >>=20 >>=20 >> _______________________________________________ >> dmm mailing list >> dmm@ietf.org >> https://www.ietf.org/mailman/listinfo/dmm >=20 > _______________________________________________ > dmm mailing list > dmm@ietf.org > https://www.ietf.org/mailman/listinfo/dmm From Peter.McCann@huawei.com Fri May 18 08:01:53 2012 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4AEA221F8713 for ; Fri, 18 May 2012 08:01:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.061 X-Spam-Level: X-Spam-Status: No, score=-5.061 tagged_above=-999 required=5 tests=[AWL=1.538, 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 NpcD10l1flZJ for ; Fri, 18 May 2012 08:01:52 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id 9C89121F8711 for ; Fri, 18 May 2012 08:01:52 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml201-edg.china.huawei.com) ([172.18.9.243]) by dfwrg02-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AGA79780; Fri, 18 May 2012 11:01:52 -0400 (EDT) Received: from DFWEML404-HUB.china.huawei.com (10.193.5.203) by dfweml201-edg.china.huawei.com (172.18.9.107) with Microsoft SMTP Server (TLS) id 14.1.323.3; Fri, 18 May 2012 08:00:04 -0700 Received: from dfweml512-mbx.china.huawei.com ([169.254.1.156]) by dfweml404-hub.china.huawei.com ([10.193.5.203]) with mapi id 14.01.0323.003; Fri, 18 May 2012 08:00:05 -0700 From: Peter McCann To: jouni korhonen , h chan Thread-Topic: [DMM] draft requirement REQ-4: compatibility Thread-Index: AQHNNIlbtoqbJ5yETkOkjeylInPSyJbPpE0Q Date: Fri, 18 May 2012 15:00:03 +0000 Message-ID: <5963DDF1F751474D8DEEFDCDBEE43AE716E0426B@dfweml512-mbx.china.huawei.com> References: <6E31144C030982429702B11D6746B98C1DDFB532@SZXEML505-MBS.china.huawei.com> <570967EC-D26C-4605-833F-267AD2C5AFD0@gmail.com> In-Reply-To: <570967EC-D26C-4605-833F-267AD2C5AFD0@gmail.com> Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.193.125.205] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "dmm@ietf.org" Subject: Re: [DMM] draft requirement REQ-4: compatibility X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 May 2012 15:01:53 -0000 Hi, Jouni, jouni korhonen wrote: >=20 > On May 7, 2012, at 9:04 PM, h chan wrote: >=20 >> REQ-4: compatibility >> The DMM solutions SHALL support existing network deployment with >> IPv6 >> (e.g. existing IPv6 address assignment), be compatible with other >> mobility protocols, and be interoperable with the network or the >> mobile hosts/routers that do not support the DMM enabling protocol so >> that the existing network deployments are unaffected. >>=20 >> REQ-4M (Motivation for REQ-4) >> Motivation: The motivation of this requirement is to be able to work >> with network architectures of both hierarchical networks and flattened >> networks, so that the mobility management protocol possesses enough >> flexibility to support different networks, and so that the existing >> networks and hosts are not affected and do not break. >=20 > Isn't the motivation just "SHALL not break existing network > deployments and end hosts" ? > Either the network or the host may not have any idea of the solutions > developed in DMM. I think that's a reasonable simplification. We need a strategy for backwards compatibility. -Pete > - JOuni >=20 >>=20 >> OTHER related problem O-PS3: Complicated deployment with too many >> variants and extensions of MIP Deployment is complicated with many >> variants and extensions of > MIP. When introducing new functions which may add to the complicity, > existing solutions are more vulnerable to break. >>=20 >> (The above has been drafted with contributions, inputs and discussions >> from various people. Additional contributions and comments are most >> welcome.) >>=20 >> H Anthony Chan >>=20 >>=20 >> _______________________________________________ >> dmm mailing list >> dmm@ietf.org >> https://www.ietf.org/mailman/listinfo/dmm >=20 > _______________________________________________ > dmm mailing list > dmm@ietf.org > https://www.ietf.org/mailman/listinfo/dmm From Peter.McCann@huawei.com Fri May 18 08:02:46 2012 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 64A7D21F856D for ; Fri, 18 May 2012 08:02:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.17 X-Spam-Level: X-Spam-Status: No, score=-5.17 tagged_above=-999 required=5 tests=[AWL=1.429, 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 lTynXqThs8TV for ; Fri, 18 May 2012 08:02:45 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id 88B0421F8570 for ; Fri, 18 May 2012 08:02:41 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml201-edg.china.huawei.com) ([172.18.9.243]) by dfwrg01-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AGH76553; Fri, 18 May 2012 11:02:41 -0400 (EDT) Received: from DFWEML407-HUB.china.huawei.com (10.193.5.132) by dfweml201-edg.china.huawei.com (172.18.9.107) with Microsoft SMTP Server (TLS) id 14.1.323.3; Fri, 18 May 2012 08:00:47 -0700 Received: from dfweml512-mbx.china.huawei.com ([169.254.1.156]) by dfweml407-hub.china.huawei.com ([10.193.5.132]) with mapi id 14.01.0323.003; Fri, 18 May 2012 08:00:46 -0700 From: Peter McCann To: jouni korhonen , h chan Thread-Topic: [DMM] draft requirement REQ-5: Mobile IP based Thread-Index: AQHNNImgQn2qlSOe806lg5Ox2L3oZ5bPpNcw Date: Fri, 18 May 2012 15:00:45 +0000 Message-ID: <5963DDF1F751474D8DEEFDCDBEE43AE716E0427A@dfweml512-mbx.china.huawei.com> References: <6E31144C030982429702B11D6746B98C1DDFB537@SZXEML505-MBS.china.huawei.com> <3436461C-2DF8-4E14-8889-323AEF4AA079@gmail.com> In-Reply-To: <3436461C-2DF8-4E14-8889-323AEF4AA079@gmail.com> Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.193.125.205] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "dmm@ietf.org" Subject: Re: [DMM] draft requirement REQ-5: Mobile IP based X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 May 2012 15:02:46 -0000 Hi, Jouni, jouni korhonen wrote: >=20 > On May 7, 2012, at 9:11 PM, h chan wrote: >=20 >> REQ-5: Mobile IP based >> The DMM solutions based on existing host- or network-based mobility > protocols, such as Mobile IPv6 [RFC6275, 5555], Proxy Mobile IPv6 > [RFC5213, 5844] and NEMO [RFC3963], SHOULD be preferred, unless they > fail to meet any of the other requirements. >=20 > What about something on the lines with: >=20 > "A DMM solution that relies on a mobility protocol should be based on > existing mobility protocol, such as .." Sounds good to me. -Pete > - Jouni >=20 >> REQ-5M (Motivation for REQ-5) The motivation is to reuse the existing >> protocol first before considering new protocols. >>=20 >> (The above has been drafted with contributions, inputs and discussions >> from various people. Additional contributions and comments are most >> welcome.) >>=20 >> H Anthony Chan >>=20 >>=20 >> _______________________________________________ >> dmm mailing list >> dmm@ietf.org >> https://www.ietf.org/mailman/listinfo/dmm >=20 > _______________________________________________ > dmm mailing list > dmm@ietf.org > https://www.ietf.org/mailman/listinfo/dmm From jouni.nospam@gmail.com Sat May 19 02:09:12 2012 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C52721F8698 for ; Sat, 19 May 2012 02:09:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.299 X-Spam-Level: X-Spam-Status: No, score=-3.299 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 ttzRvaasAF8C for ; Sat, 19 May 2012 02:09:11 -0700 (PDT) Received: from mail-wg0-f42.google.com (mail-wg0-f42.google.com [74.125.82.42]) by ietfa.amsl.com (Postfix) with ESMTP id 3F8F921F8673 for ; Sat, 19 May 2012 02:09:08 -0700 (PDT) Received: by wgbds11 with SMTP id ds11so1450590wgb.1 for ; Sat, 19 May 2012 02:09:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=Dd8o0CafE4dQcgyAT7sq0tgZZwe7xv2qTwgy3cxwOvI=; b=AQ27CkrlHnC2Ocncn9vgT4VzrDgPqTUDWBdoOzk5/HBTBPXsFnRlvS7U3HAoaCmZek N7esFOvrbQYnEI1bnwVVi1/F398VHMftlYlkaNKX/CG5SUvhi4oez4bTNWAyP+NIZE2G 0OKI9WqTk3KdT695mA/pv7t0Ae4tqGo4y6auOQf1LrYoguskiCqYvg9b90mJ14CcX8bM Knl7dLs802ChjH2P1u7pz/mIXztKaYnCtZmv8EKaomYlgMdhASmV/msMMQJRFoNlRrL1 ETzzQo6Ba6E7cby4bKlRAHFW3zWbUch86ZMNHsa1MANaPbBAjEpjwdoAwnkCvubCYpX1 xwTA== Received: by 10.180.82.5 with SMTP id e5mr8941066wiy.0.1337418547284; Sat, 19 May 2012 02:09:07 -0700 (PDT) Received: from [188.117.15.110] ([188.117.15.110]) by mx.google.com with ESMTPS id k8sm12064600wia.6.2012.05.19.02.09.05 (version=TLSv1/SSLv3 cipher=OTHER); Sat, 19 May 2012 02:09:06 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=us-ascii From: Jouni In-Reply-To: <5963DDF1F751474D8DEEFDCDBEE43AE716E04231@dfweml512-mbx.china.huawei.com> Date: Sat, 19 May 2012 12:09:03 +0300 Content-Transfer-Encoding: 7bit Message-Id: <8E2216F5-4CE5-41B8-9501-C7EA17481F12@gmail.com> References: <2630A3D8-5718-4302-AD79-A6680C8CDFB4@gmail.com> <5963DDF1F751474D8DEEFDCDBEE43AE716E04231@dfweml512-mbx.china.huawei.com> To: Peter McCann X-Mailer: Apple Mail (2.1257) Cc: Rajeev Koodli , "dmm@ietf.org" Subject: Re: [DMM] draft requirement REQ-2: Transparency to Upper Layers X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 May 2012 09:09:12 -0000 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 On May 18, 2012, at 5:36 PM, Peter McCann wrote: > 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: >> >> 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" 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? >>> >>>> >>>> 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? >>> >>>> >>>> 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? >>> >>> - 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 >>>> dmm@ietf.org >>>> https://www.ietf.org/mailman/listinfo/dmm >>> >>> _______________________________________________ >>> dmm mailing list >>> dmm@ietf.org >>> https://www.ietf.org/mailman/listinfo/dmm >> >> _______________________________________________ >> dmm mailing list >> dmm@ietf.org >> https://www.ietf.org/mailman/listinfo/dmm > > > From jouni.nospam@gmail.com Sat May 19 02:23:04 2012 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6706121F86B1 for ; Sat, 19 May 2012 02:23:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.449 X-Spam-Level: X-Spam-Status: No, score=-3.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 VKX5WZvDhADQ for ; Sat, 19 May 2012 02:23:03 -0700 (PDT) Received: from mail-wg0-f44.google.com (mail-wg0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id 3DCC921F86B0 for ; Sat, 19 May 2012 02:23:03 -0700 (PDT) Received: by wgbdr13 with SMTP id dr13so2421997wgb.13 for ; Sat, 19 May 2012 02:23:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=vtUNvCNmcw3+Yh17iDeMrCHPKhs3UIGzYkzlIAnqyAo=; b=WFlar+NUsuITklh6imvGd2NYeMZcnvc6pqk2u/TguP5jMMneCNKjg4fmnVHOW27J/p ePMYf05pAUQDJHcfA2RwW/0ipQJmyB4CY9VEBMiYAg/7tps1dEQlHpMIzhw9rH3k6QD/ YtQLy9BHbD+/bi3bkKqXSF8FmpZ1EHDD11h63eHoUsmB668EJ3LHC6d2qpD1lr3G75gX vs0TOcmXGZuaI8gqwsLWFdGqN375WdDXfJ4maNd+bIJvl4qX3B+J77BWdjvSeEYTZlC5 QuZ86O8vIaBolFZZswOlX1hbmPpfRg3tYkE+pkEwTMUTYaTm0spbvBB/3mw96ySoh9Wd zWDA== Received: by 10.180.92.130 with SMTP id cm2mr9047543wib.4.1337419382319; Sat, 19 May 2012 02:23:02 -0700 (PDT) Received: from [188.117.15.110] ([188.117.15.110]) by mx.google.com with ESMTPS id fm1sm7758299wib.10.2012.05.19.02.23.00 (version=TLSv1/SSLv3 cipher=OTHER); Sat, 19 May 2012 02:23:01 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=us-ascii From: Jouni In-Reply-To: <5963DDF1F751474D8DEEFDCDBEE43AE716E04252@dfweml512-mbx.china.huawei.com> Date: Sat, 19 May 2012 12:22:59 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <6964EF2A-397A-4B2B-BD24-B6C85A21482F@gmail.com> References: <6E31144C030982429702B11D6746B98C1DDFB507@SZXEML505-MBS.china.huawei.com> <9170BC9C-68E5-48F4-947F-9126FA8B8CFD@gmail.com> <5963DDF1F751474D8DEEFDCDBEE43AE716E04252@dfweml512-mbx.china.huawei.com> To: Peter McCann X-Mailer: Apple Mail (2.1257) Cc: "dmm@ietf.org" Subject: Re: [DMM] draft requirement REQ-1: Distributed deployment X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 May 2012 09:23:04 -0000 Hi On May 18, 2012, at 5:55 PM, Peter McCann wrote: > Hi, Jouni, >=20 > jouni korhonen wrote: >> Breaking the silence.. >>=20 >> On May 7, 2012, at 8:55 PM, h chan wrote: >>=20 >>> REQ-1: Distributed deployment >>> IP mobility, network access and routing solutions provided by DMM >>> SHALL enable the functions of mobility management of IP sessions to = be >>> distributed so that the traffic is routed in an optimal manner = without >>> relying on centrally deployed anchors. >>=20 >> Few comments/questions.. >> o "SHALL enable the functions of mobility management" does that imply >> the >> DMM "solution" must always involve or extend a mobility protocol? = IMHO >> that should not be a SHALL requirement. >=20 > To the extent that DMM provides an "IP mobility...solution" I think it = does > involve or extend a mobility protocol. However, I don't think the = requirement > implies that we will necessarily extend an existing mobility protocol. Excerpt from the charter: on managing the use of care-of versus home addresses in an efficient manner for different types of communications. Just making sure the right flavor or address is used does not = necessarily extend or require any mobility protocol support. >> o "centrally deployed anchors" what if the access network routing is >> laid >> out in a way that even pure IP routing would lead packets to go >> through a central site/edge router? Doesn't that lead to similar >> deficiencies than with mobility anchors? >=20 > It does indeed, which is why a good network deployment will have = redundant > back-up paths throughout the network. Unfortunately, it is difficult = to > provide redundancy when the path involves tunnel state at an anchor = point. >=20 >>> REQ-1M (Motivation for REQ-1) >>> The goals of this requirement are to match mobility deployment with >>> current trend in network evolution: >>> more cost and resource effective to cache and distribute contents = when >>> combining distributed anchors with caching systems (e.g., CDN); >>> improve scalability; reduce signaling overhead; avoid single point = of >>> failure; mitigate threats being focused on a centrally deployed >>> anchor, e.g., home agent and local mobility anchor. >>=20 >> Reduce signaling overhead.. is a very good goal. However, if any DMM >> solution builds on top of an existing mobility protocol that hardly >> reduces anything. Also if setting up optimal routes require >> establishing new tunnels, signaling is bound to increase. I would say >> here "does not increase the amount of present signaling" and the aim >> for solutions that would reduce it somehow. >=20 > It should be possible to completely avoid mobility management = signaling > when the MN is stationary or doesn't need a fixed address. I would = say > that reduces signaling. =46rom that point view ok. Extra care is then needed that one does not move the signaling to another layer.. take DSMIP6 (S2c) as an example, which avoids BU/BA exchange but then expanded the IKE signaling :) >>> RELEVANT problems: >>> PS1: Non-optimal routes >>> Routing via a centralized anchor often results in a longer route, >>> and >>> the problem is especially manifested when accessing a local or cache >>> server of a Content Delivery Network (CDN). >>> PS2: Non-optimality in Evolved Network Architecture The centralized >>> mobility management can become non-optimal as Network architecture >>> evolves and become more flattened. >>=20 >> More flat is kind of superfluous.. take e.g. EPS example. You have, = in >> an optimal case, an eNodeB connected directly to a combined SGW/PGW >> from the user plane point of view. And the SGW/PGW you can allocate >> close to you eNodeB based on its topological location. How you can >> make that more flat? SGW relocation changes the situation a bit but = still.. >=20 > Putting an SGW/PGW (or an LGW) inside in eNB would indeed be a = maximally Putting SGW/PGW into eNodeB is not too realistic for a wider are deployment. LGWs we already got out there but the mobility in that case ain't too great as far as I remember. > flat architecture. However, we would then need to deal with a change = of > anchor point during the life of a session, which is something that = wasn't > contemplated by 3GPP. That is exactly the area that DMM should focus = on, > IMHO. With a cost of additional signaling and new tunnel state? >>> PS3: Low scalability of centralized route and mobility context >>> maintenance Setting up such special routes and maintaining the >>> mobility context for each MN is more difficult to scale in a >>> centralized design with a large number of MNs. >>=20 >> Can I assume the mobility context involves a possible per MN tunnel >> state? >=20 > Yes, I think the per-MN tunnel state is part of the mobility context > being talked about here. - Jouni >=20 > -Pete >=20 >>> Distributing the route maintenance function and the mobility context >>> maintenance function among different networks can be more scalable. >>> PS4: Single point of failure and attack Centralized anchoring may be >>> more vulnerable to single point of failure and attack than a >>> distributed system. >>>=20 >>> (The above is drafted with contributions, inputs and discussions >>> from various people. Additional contributions and comments are most >>> welcome.) >>>=20 >>=20 >> - Jouni >>=20 >>=20 >>=20 >>> H Anthony Chan >>>=20 >>>=20 >>> _______________________________________________ >>> dmm mailing list >>> dmm@ietf.org >>> https://www.ietf.org/mailman/listinfo/dmm >>=20 >> _______________________________________________ >> dmm mailing list >> dmm@ietf.org >> https://www.ietf.org/mailman/listinfo/dmm >=20 >=20 >=20 From sgundave@cisco.com Mon May 21 19:13:41 2012 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2962821F8596 for ; Mon, 21 May 2012 19:13:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.298 X-Spam-Level: X-Spam-Status: No, score=-10.298 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] 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 dVroF0QIvq51 for ; Mon, 21 May 2012 19:13:40 -0700 (PDT) Received: from mtv-iport-1.cisco.com (mtv-iport-1.cisco.com [173.36.130.12]) by ietfa.amsl.com (Postfix) with ESMTP id AC3A121F8575 for ; Mon, 21 May 2012 19:13:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=sgundave@cisco.com; l=2808; q=dns/txt; s=iport; t=1337652820; x=1338862420; h=subject:mime-version:from:in-reply-to:date:cc:message-id: references:to; bh=1cjSw1EXHajEL3PBHLgBXQzKNTe/QhLyQqkLCKmb2kA=; b=RWU05uwHfhQ0o50RveRKPlzgixc6yPLSi+fKlx9V2MoQl5ZuzCAu93lL eN3HVTiH7zfHMbM1YUw67vD5AfJa12YUAxHytitvQ9gYPVRiGU9iHW4m4 il99Zc8p0cvfFMrduByYedzsfDw2dZZ8M1X4u9y4ewCXUh4ha2lJV/d4+ I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EAKv1uk+rRDoJ/2dsb2JhbABEgkWxVoEHghUBAQEDARIBZgULCwRCVwYuB4dnBJ5moBOLBYRaYgOIQoxZjgyBZIMJ X-IronPort-AV: E=Sophos;i="4.75,635,1330905600"; d="scan'208,217";a="42693516" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-1.cisco.com with ESMTP; 22 May 2012 02:13:40 +0000 Received: from sjc-vpn7-811.cisco.com (sjc-vpn7-811.cisco.com [10.21.147.43]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id q4M2DdoR023865; Tue, 22 May 2012 02:13:40 GMT Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: multipart/alternative; boundary="Apple-Mail=_C7207570-809C-48BA-811F-397F974618B0" From: Sri Gundavelli In-Reply-To: <6E31144C030982429702B11D6746B98C1DDFB537@SZXEML505-MBS.china.huawei.com> Date: Mon, 21 May 2012 19:13:39 -0700 Message-Id: <4A1C1A18-5F9A-4864-BC2F-09CEB9DB358B@cisco.com> References: <6E31144C030982429702B11D6746B98C1DDFB537@SZXEML505-MBS.china.huawei.com> To: h chan X-Mailer: Apple Mail (2.1278) Cc: "dmm@ietf.org" Subject: Re: [DMM] draft requirement REQ-5: Mobile IP based X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 May 2012 02:13:41 -0000 --Apple-Mail=_C7207570-809C-48BA-811F-397F974618B0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On May 7, 2012, at 11:11 AM, h chan wrote: > REQ-5: Mobile IP based > The DMM solutions based on existing host- or network-based mobility = protocols, such as Mobile IPv6 [RFC6275, 5555], Proxy Mobile IPv6 = [RFC5213, 5844] and NEMO [RFC3963], SHOULD be preferred, unless they = fail to meet any of the other requirements. Anthony: Ack. Since, you have added 3963 reference, you may want to add a = reference to the PMIPv6 PD draft. Regards Sri --Apple-Mail=_C7207570-809C-48BA-811F-397F974618B0 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
On May 7, 2012, at 11:11 AM, h chan = wrote:

REQ-5: Mobile IP based
The DMM = solutions based on existing host- or network-based mobility protocols, = such as Mobile IPv6 [RFC6275, 5555], Proxy Mobile IPv6 [RFC5213, 5844] = and NEMO [RFC3963], SHOULD be preferred, unless they fail to meet any of = the other = requirements.

<= div>
Anthony:

Ack. Since, you = have added 3963 reference, you may want to add a reference to the PMIPv6 = PD = draft.

Regards
Sri

=

= --Apple-Mail=_C7207570-809C-48BA-811F-397F974618B0-- From h.anthony.chan@huawei.com Tue May 22 15:27:12 2012 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3813E21F86C6 for ; Tue, 22 May 2012 15:27:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.395 X-Spam-Level: X-Spam-Status: No, score=-2.395 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, 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 lCxqfnV9hKPW for ; Tue, 22 May 2012 15:27:11 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id B0BDF21F86BB for ; Tue, 22 May 2012 15:27:10 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml202-edg.china.huawei.com) ([172.18.9.243]) by dfwrg01-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AGL00652; Tue, 22 May 2012 18:27:10 -0400 (EDT) Received: from DFWEML408-HUB.china.huawei.com (10.193.5.134) by dfweml202-edg.china.huawei.com (172.18.9.108) with Microsoft SMTP Server (TLS) id 14.1.323.3; Tue, 22 May 2012 15:25:36 -0700 Received: from SZXEML414-HUB.china.huawei.com (10.82.67.153) by dfweml408-hub.china.huawei.com (10.193.5.134) with Microsoft SMTP Server (TLS) id 14.1.323.3; Tue, 22 May 2012 15:25:34 -0700 Received: from SZXEML505-MBS.china.huawei.com ([169.254.2.245]) by SZXEML414-HUB.china.huawei.com ([10.82.67.153]) with mapi id 14.01.0323.003; Wed, 23 May 2012 06:25:30 +0800 From: h chan To: "tso@zteusa.com" , "luo.wen@zte.com.cn" Thread-Topic: [DMM]: draft requirement REQ-2: Transparency to Upper Layers Thread-Index: AQHNMiFcYaJK4TU3aUSMjJNJ9Rstu5bWWhLw Date: Tue, 22 May 2012 22:25:29 +0000 Message-ID: <6E31144C030982429702B11D6746B98C1DE04C58@SZXEML505-MBS.china.huawei.com> References: <6E31144C030982429702B11D6746B98C1DDFB50C@SZXEML505-MBS.china.huawei.com> In-Reply-To: Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.154.87] Content-Type: multipart/alternative; boundary="_000_6E31144C030982429702B11D6746B98C1DE04C58SZXEML505MBSchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "dmm@ietf.org" Subject: Re: [DMM] : draft requirement REQ-2: Transparency to Upper Layers X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 May 2012 22:27:12 -0000 --_000_6E31144C030982429702B11D6746B98C1DE04C58SZXEML505MBSchi_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 VHJpY2NpIGFuZCBMdW8sDQoNClRoZSBzY2VuYXJpbyBvZiBlbnRpcmUgbmV0d29ya3MgY2hhbmdp bmcgdGhlaXIgUE9BIGlzIG5lbW8uDQoNClBTNSBpcyBhIHByb2JsZW0gc3RhdGVtZW50IG9uIGV4 aXN0aW5nIGRlcGxveW1lbnQgKE1JUC9QTUlQKS4gU28gSSB0aGluayBtb2JpbGl0eSBjb250ZXh0 IGhlcmUgaXMgcmVmZXJyaW5nIHRvIHRoZSBhZGRpdGlvbmFsIGluZm9ybWF0aW9uIHdoZW4gYSBt b2JpbGUgbm9kZSBhdHRhY2hlcyB0byB0aGUgbmV0d29yayBpbiBhbnRpY2lwYXRpb24gb2YgcG9z c2libGUgY2hhbmdlIG9mIFBPQSBjb21wYXJlZCB3aXRoIHdoYXQgYXJlIG5lZWRlZCB3aGVuIGEg Zml4ZWQgbm9kZSBhdHRhY2hlcyB0byB0aGUgbmV0d29yay4gTm93YWRheXMsIG1hbnkgcGVvcGxl IGFyZSB1c2luZyB0aGUgd2lyZWxlc3MgY29ubmVjdGlvbiB3aXRoIGxhcHRvcCBhbmQgbW9iaWxl IHBob25lcyBhdCBmaXhlZCBsb2NhdGlvbnMgKGhvbWUgb3Igb2ZmaWNlKSBub3QgYmVjYXVzZSB0 aGV5IGFudGljaXBhdGUgY2hhbmdlIG9mIFBPQSBidXQgcmF0aGVyIGZvciB0aGUgY29udmVuaWVu Y2Ugb2YgYmVpbmcgY29yZGxlc3MuIFdoZW4gc28gbWFueSBNTiBhcmUgbm90IGNoYW5naW5nIFBP QSwgd2hhdGV2ZXIgdGhhdCB3YXMgc2V0IHVwIHRvIHByZXBhcmUgZm9yIHBvc3NpYmxlIGNoYW5n ZSBvZiBQT0EgaXMgYmVjb21pbmcgYSB3YXN0ZS4NCllldCB3aGF0IGluZm9ybWF0aW9uIGlzIGVz c2VudGlhbCBhbmQgd2hhdCBpcyB3YXN0ZWQgY291bGQgbWVhbiBkaWZmZXJlbnQgdGhpbmdzIHRv IGRpZmZlcmVudCBwZW9wbGUuIFlvdXIgc3VnZ2VzdGVkIHRleHQgdG8gY2xhcmlmeSBQUzUgbG9v a3MgZ29vZCB0byBtZS4NCg0KSCBBbnRob255IENoYW4NCg0KDQpGcm9tOiB0c29AenRldXNhLmNv bSBbbWFpbHRvOnRzb0B6dGV1c2EuY29tXQ0KU2VudDogTW9uZGF5LCBNYXkgMTQsIDIwMTIgNToz MiBQTQ0KVG86IGx1by53ZW5AenRlLmNvbS5jbg0KQ2M6IGRtbUBpZXRmLm9yZzsgaCBjaGFuDQpT dWJqZWN0OiBSZTogW0RNTV0gtPC4tDogZHJhZnQgcmVxdWlyZW1lbnQgUkVRLTI6IFRyYW5zcGFy ZW5jeSB0byBVcHBlciBMYXllcnMNCg0KRGVhciBBbnRob255LA0KDQpJIHNoYXJlIHRoZSBzYW1l IGNvbmNlcm4gYXMgTHVvd2VuIGRvZXMgZm9yIFBTNSwgYnV0IGFsc28gc2V2ZXJhbCBpbmZvIGZv ciBhc3NvY2lhdGVkIHdpdGggdGhpcyByZXF1aXJlbWVudHMuICBQbGVhc2UgbXkgY29tbWVudHMg aW5saW5lIGJlbG93Lg0KDQpUaGFua3MuDQoNCg0KbHVvLndlbkB6dGUuY29tLmNuDQpTZW50IGJ5 OiBkbW0tYm91bmNlc0BpZXRmLm9yZw0KDQowNS8wOC8yMDEyIDA2OjIzIFBNDQoNClRvDQoNCmgg Y2hhbiA8aC5hbnRob255LmNoYW5AaHVhd2VpLmNvbT4NCg0KY2MNCg0KZG1tLWJvdW5jZXNAaWV0 Zi5vcmcsICJkbW1AaWV0Zi5vcmciIDxkbW1AaWV0Zi5vcmc+DQoNClN1YmplY3QNCg0KW0RNTV0g tPC4tDogIGRyYWZ0IHJlcXVpcmVtZW50IFJFUS0yOiBUcmFuc3BhcmVuY3kgdG8gVXBwZXIgTGF5 ZXJzDQoNCg0KDQoNCg0KDQoNCg0KSGkgQW50b255Og0KDQpUaGUgbGFzdCBwYXJ0IG9mIFBTLTUs IGRvZXMgdGhlIHNlbnRlbmNlICIgTmV0d29yayByZXNvdXJjZXMgYXJlIGFsc28gd2FzdGVkIHdo ZW4gdGhlIHZpYSByb3V0ZXMgYXJlIHNldCB1cCBmb3IgbWFueSBNTnMgdGhhdCBkbyBub3QgcmVx dWlyZSBJUCBtb2JpbGl0eSBzdXBwb3J0LiIgaW1wbGljaXRseSBpbmRpY2F0ZSB0aGUgc2NlbmFy aW8gd2hpY2ggc2ltaWxhciB3aXRoIE1JUC9QTUlQPw0KV2hlbiBJIHJlYWQgdGhpcyBzZW50ZW5j ZSwgdGhlIE1JUC9QTUlQIHR1bm5lbCBhcHBlYXJzIGluIG15IG1pbmQsIGFuZCB5ZXMsIGlmIE1O cyBkbyBub3QgcmVxdWlyZSBJUCBtb2JpbGl5IHN1cHBvcnQsIHRoZSAgTUlQL1BNSVAgdHVubmVs IHdpbGwgd2FzdGUgbmV0d29yayByZXNvdXJjZXMuDQoNCkNoZWVycy4NCg0KaCBjaGFuIDxoLmFu dGhvbnkuY2hhbkBodWF3ZWkuY29tPg0Kt6K8/sjLOiAgZG1tLWJvdW5jZXNAaWV0Zi5vcmcNCg0K MjAxMi8wNS8wOCAwMTo1OA0KDQoNCsrVvP7Iyw0KDQoiZG1tQGlldGYub3JnIiA8ZG1tQGlldGYu b3JnPg0KDQqzrcvNDQoNCtb3zOINCg0KW0RNTV0gZHJhZnQgcmVxdWlyZW1lbnQgUkVRLTI6IFRy YW5zcGFyZW5jeSB0byBVcHBlciBMYXllcnMNCg0KDQoNCg0KDQoNCg0KDQpSRVEtMjogVHJhbnNw YXJlbmN5IHRvIFVwcGVyIExheWVycw0KVGhlIERNTSBzb2x1dGlvbnMgU0hBTEwgZW5hYmxlIHRy YW5zcGFyZW5jeSBhYm92ZSB0aGUgSVAgbGF5ZXIuIFN1Y2ggdHJhbnNwYXJlbmN5IGlzIG5lZWRl ZCBmb3IgdGhlIGFwcGxpY2F0aW9uIGZsb3dzIHRoYXQgY2Fubm90IGNvcGUgd2l0aCBhIGNoYW5n ZSBvZiBJUCBhZGRyZXNzIGFuZCB3aGVuIG1vYmlsZSBob3N0cyBvciBlbnRpcmUgbW9iaWxlIG5l dHdvcmtzIGNoYW5nZSB0aGVpciBwb2ludCBvZiBhdHRhY2htZW50IHRvIHRoZSBJbnRlcm5ldCwg YnV0IFNIT1VMRCBOT1QgYmUgdGFrZW4gYXMgdGhlIGRlZmF1bHQgYmVoYXZpb3IuDQo+Pj4+Pj4g Q29tbWVudHMNCigxKSBXaGF0IHNjZW5hcmlvIGlzIHRoYXQgImVudGlyZSBtb2JpbGUgbmV0d29y a3MgY2hhbmdlIHRoZWlyIHBvaW50IG9mIGF0dGFjaG1lbnQgdG8gdGhlIGludGVybmV0Ij8NCg0K UkVRLTJNIChNb3RpdmF0aW9uIGZvciBSRVEtMikNClRoZSBnb2FsIG9mIHRoaXMgcmVxdWlyZW1l bnQgaXMgdG8NCmVuYWJsZSBtb3JlIGVmZmljaWVudCB1c2Ugb2YgbmV0d29yayByZXNvdXJjZXMg YW5kIG1vcmUgZWZmaWNpZW50IHJvdXRpbmcgYnkgbm90IGludm9raW5nIG1vYmlsaXR5IHN1cHBv cnQgd2hlbiB0aGVyZSBpcyBubyBzdWNoIG5lZWQuDQoNClJFTEVWQU5UIHByb2JsZW06DQpQUzU6 IFdhc3RpbmcgcmVzb3VyY2VzIHRvIHN1cHBvcnQgbW9iaWxlIG5vZGVzIG5vdCBuZWVkaW5nIG1v YmlsaXR5IHN1cHBvcnQNCklQIG1vYmlsaXR5IHN1cHBvcnQgaXMgbm90IGFsd2F5cyByZXF1aXJl ZC4gRm9yIGV4YW1wbGUsIHNvbWUgYXBwbGljYXRpb25zIGRvIG5vdCBuZWVkIGEgc3RhYmxlIElQ IGFkZHJlc3MgZHVyaW5nIGhhbmRvdmVyLCBpLmUuIElQIHNlc3Npb24gY29udGludWl0eS4gU29t ZXRpbWVzLCB0aGUgZW50aXJlIGFwcGxpY2F0aW9uIHNlc3Npb24gcnVucyB3aGlsZSB0aGUgdGVy bWluYWwgZG9lcyBub3QgY2hhbmdlIHRoZSBwb2ludCBvZiBhdHRhY2htZW50LiBJbiB0aGVzZSBz aXR1YXRpb25zIHRoYXQgZG8gbm90IHJlcXVpcmUgSVAgbW9iaWxpdHkgc3VwcG9ydCwgbmV0d29y ayByZXNvdXJjZXMgYXJlIHdhc3RlZCB3aGVuIG1vYmlsaXR5IGNvbnRleHQgaXMgc2V0IHVwLiBO ZXR3b3JrIHJlc291cmNlcyBhcmUgYWxzbyB3YXN0ZWQgd2hlbiB0aGUgdmlhIHJvdXRlcyBhcmUg c2V0IHVwIGZvciBtYW55IE1OcyB0aGF0IGRvIG5vdCByZXF1aXJlIElQIG1vYmlsaXR5IHN1cHBv cnQuDQo+Pj4+Pj4gQ29tbWVudHMNCigxKSBJIGhhdmUgdGhlIHNhbWUgY29uY2VybiBhcyBMdW9X ZW4gZG9lcy4gIFdlIHNob3VsZCBiZSBtb3JlIGNsZWFyIHdoYXQgYXJlIHdlIHJlZmVycmluZyB0 byBmb3IgdGhlIHRlcm0gIm1vYmlsaXR5IGNvbnRleHQiIGhlcmU/ICBJdCBpcyBiZWNhdXNlLCB0 aGVyZSB3b3VsZCBhbHdheXMgYmUgY29udGV4dCBzZXQgdXAgZm9yIHRoZSBtb2JpbGUgbm9kZSBh dHRhY2hpbmcgdG8gdGhlIG5ldHdvcmsgcmVnYXJkbGVzcyBpZiB0aGUgSVAgbW9iaWxpdHkgaXMg cmVxdWlyZWQgb3Igbm90LCBzdWNoIGFzIHBlci1NTiBsb2NhbGl6YXRpb24gaW5mb3JtYXRpb24g YW5kIHNlY3VyaXR5IGNvbnRleHQuICBJIGJlbGlldmUgdGhhdCB0aGUgInNwZWNpZmljIiBtb2Jp bGl0eSBjb250ZXh0IHRoYXQgeW91J3JlIHJlZmVycmluZyBoZXJlIGlzIHRoZSBjb250ZXh0IGlu Zm8gdGhhdCBzdXBwb3J0cyB0aGUgTU4gZm9yIGNoYW5naW5nIHRoZWlyIHBvaW50IG9mIGF0dGFj aG1lbnQgdG8gdGhlIG5ldHdvcmsgc3VjaCBhcyB0aGUgbW9iaWxpdHkgdHVubmVsaW5nIGluZm8u DQo+Pj4+PiBQcm9wb3NlZCBuZXcgdGV4dA0KUFM1OiBXYXN0aW5nIHJlc291cmNlcyB0byBzdXBw b3J0IG1vYmlsZSBub2RlcyBub3QgbmVlZGluZyBtb2JpbGl0eSBzdXBwb3J0DQpJUCBtb2JpbGl0 eSBzdXBwb3J0IGlzIG5vdCBhbHdheXMgcmVxdWlyZWQuIEZvciBleGFtcGxlLCBzb21lIGFwcGxp Y2F0aW9ucyBkbyBub3QgbmVlZCBhIHN0YWJsZSBJUCBhZGRyZXNzIGR1cmluZyBoYW5kb3Zlciwg aS5lLiBJUCBzZXNzaW9uIGNvbnRpbnVpdHkuIFNvbWV0aW1lcywgdGhlIGVudGlyZSBhcHBsaWNh dGlvbiBzZXNzaW9uIHJ1bnMgd2hpbGUgdGhlIHRlcm1pbmFsIGRvZXMgbm90IGNoYW5nZSB0aGUg cG9pbnQgb2YgYXR0YWNobWVudC4gSW4gdGhlc2Ugc2l0dWF0aW9ucyB0aGF0IGRvIG5vdCByZXF1 aXJlIElQIG1vYmlsaXR5IHN1cHBvcnQsIG5ldHdvcmsgcmVzb3VyY2VzIGFyZSB3YXN0ZWQgd2hl biBpbmNsdWRpbmcgYWRkaXRpb25hbCBpbmZvIHRvIHRoZSBtb2JpbGl0eSBjb250ZXh0IHRvIHN1 cHBvcnQgdGhlIGNoYW5naW5nIHRoZSBwb2ludCBvZiBhdHRhY2htZW50LiBOZXR3b3JrIHJlc291 cmNlcyBhcmUgYWxzbyB3YXN0ZWQgd2hlbiB0aGUgdmlhIHJvdXRlcyBhcmUgc2V0IHVwIGZvciBt YW55IE1OcyB0aGF0IGRvIG5vdCByZXF1aXJlIElQIG1vYmlsaXR5IHN1cHBvcnQuDQoNCg0KT1RI RVIgcmVsYXRlZCBwcm9ibGVtDQpPLVBTMTogTW9iaWxpdHkgc2lnbmFsaW5nIG92ZXJoZWFkIHdp dGggcGVlci10by1wZWVyIGNvbW11bmljYXRpb24NCldoaWxlIG1vYmlsaXR5IG1hbmFnZW1lbnQg ZW5hYmxlcyBhIG1vYmlsZSBob3N0IHRvIGJlIHJlYWNoYWJsZSwgdGhlIGhvc3RzIG1heSB0aGVu IGNvbW11bmljYXRlIGRpcmVjdGx5IHNvIHRoYXQgdGhlIG1vYmlsaXR5IHN1cHBvcnQgaXMgbm8g bG9uZ2VyIG5lZWRlZC4gVGFraW5nIHRoZSBuZWVkIG9mIG1vYmlsaXR5IHN1cHBvcnQgYXMgdGhl IGRlZmF1bHQgYmVoYXZpb3Igd2lsbCB3YXN0ZSBuZXR3b3JrIHJlc291cmNlcy4NCk8tUFMyOiBM YWNrIG9mIHVzZXItY2VudHJpY2l0eQ0KQ2VudHJhbGl6ZWQgZGVwbG95bWVudCBjb21wYXJlZCB3 aXRoIGRpc3RyaWJ1dGVkIG1vYmlsaXR5IG1hbmFnZW1lbnQgbWF5IGJlIGxlc3MgY2FwYWJsZSB0 byBzdXBwb3J0IHVzZXItY2VudHJpY2l0eS4gRXhhbXBsZSBpbiB0aGUgbGFjayBvZiB1c2VyLWNl bnRyaWNpdHkgaXMgdG8gcHJvdmlkZSBtb2JpbGl0eSBzdXBwb3J0IHRvIGFsbCBtb2JpbGUgbm9k ZXMgYnkgZGVmYXVsdCByZWdhcmRsZXNzIG9mIHdoZXRoZXIgdGhlIHVzZXIgbmVlZHMgaXQgb3Ig bm90Lg0KDQooVGhlIGFib3ZlIGhhcyBiZWVuIGRyYWZ0ZWQgd2l0aCBjb250cmlidXRpb25zLCBp bnB1dHMgYW5kIGRpc2N1c3Npb25zIGZyb20gdmFyaW91cyBwZW9wbGUuIEFkZGl0aW9uYWwgY29u dHJpYnV0aW9ucyBhbmQgY29tbWVudHMgYXJlIG1vc3Qgd2VsY29tZS4pDQoNCkggQW50aG9ueSBD aGFuDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpk bW0gbWFpbGluZyBsaXN0DQpkbW1AaWV0Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt YW4vbGlzdGluZm8vZG1tDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXw0KZG1tIG1haWxpbmcgbGlzdA0KZG1tQGlldGYub3JnDQpodHRwczovL3d3dy5pZXRm Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL2RtbQ0KDQoNCg0KDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KDQpaVEUgSW5mb3JtYXRpb24gU2Vj dXJpdHkgTm90aWNlOiBUaGUgaW5mb3JtYXRpb24gY29udGFpbmVkIGluIHRoaXMgbWFpbCBpcyBz b2xlbHkgcHJvcGVydHkgb2YgdGhlIHNlbmRlcidzIG9yZ2FuaXphdGlvbi4gVGhpcyBtYWlsIGNv bW11bmljYXRpb24gaXMgY29uZmlkZW50aWFsLiBSZWNpcGllbnRzIG5hbWVkIGFib3ZlIGFyZSBv YmxpZ2F0ZWQgdG8gbWFpbnRhaW4gc2VjcmVjeSBhbmQgYXJlIG5vdCBwZXJtaXR0ZWQgdG8gZGlz Y2xvc2UgdGhlIGNvbnRlbnRzIG9mIHRoaXMgY29tbXVuaWNhdGlvbiB0byBvdGhlcnMuDQoNClRo aXMgZW1haWwgYW5kIGFueSBmaWxlcyB0cmFuc21pdHRlZCB3aXRoIGl0IGFyZSBjb25maWRlbnRp YWwgYW5kIGludGVuZGVkIHNvbGVseSBmb3IgdGhlIHVzZSBvZiB0aGUgaW5kaXZpZHVhbCBvciBl bnRpdHkgdG8gd2hvbSB0aGV5IGFyZSBhZGRyZXNzZWQuIElmIHlvdSBoYXZlIHJlY2VpdmVkIHRo aXMgZW1haWwgaW4gZXJyb3IgcGxlYXNlIG5vdGlmeSB0aGUgb3JpZ2luYXRvciBvZiB0aGUgbWVz c2FnZS4gQW55IHZpZXdzIGV4cHJlc3NlZCBpbiB0aGlzIG1lc3NhZ2UgYXJlIHRob3NlIG9mIHRo ZSBpbmRpdmlkdWFsIHNlbmRlci4NCg0KVGhpcyBtZXNzYWdlIGhhcyBiZWVuIHNjYW5uZWQgZm9y IHZpcnVzZXMgYW5kIFNwYW0gYnkgWlRFIEFudGktU3BhbSBzeXN0ZW0uDQo= --_000_6E31144C030982429702B11D6746B98C1DE04C58SZXEML505MBSchi_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable

Tricci and Luo,

 <= /p>

The scenario of entire ne= tworks changing their POA is nemo.

 <= /p>

PS5 is a problem statemen= t on existing deployment (MIP/PMIP). So I think mobility context here is re= ferring 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 o= f being cordless. When so many MN are not changing POA, whatever that was s= et up to prepare for possible change of POA is becoming a waste.

Yet what information is e= ssential and what is wasted could mean different things to different people= . Your suggested text to clarify PS5 looks good to me.

 <= /p>

H Anthony Chan

 <= /p>

From: tso@zteu= sa.com [mailto:tso@zteusa.com]
Sent: Monday, May 14, 2012 5:32 PM
To: luo.wen@zte.com.cn
Cc: dmm@ietf.org; h chan
Subject: Re: [DMM] =B4=F0=B8=B4: draft requirement REQ-2: Transparenc= y 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 bel= ow.  

Thanks.  


luo.wen@zte.com.cn
Sent by: dmm-bounces@ietf.org

05/08/2012 06:23 PM

To

h chan <h.anthony.chan@huawei.com>

cc

dmm-bounces@ietf.org, "dmm@ietf.org&q= uot; <dmm@ietf.org>

Subject

[DMM] =B4=F0=B8=B4:  draft requirement REQ-2: Transparency to Upper Layers

 





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 requir= e 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 w= aste network resources.

Cheers.

h chan <h.anthony.chan@huawei.com>= ;
=B7=A2=BC=FE=C8=CB:  dmm-bounces@ietf.org

2012/05/08 01:58

 

=CA=D5=BC=FE=C8=CB<= /p>

"dmm@ietf.org" <dmm@ietf.org&= gt;

=B3=AD=CB=CD

=D6=F7=CC=E2

[DMM] draft requirement REQ-2: Transparenc= y to Upper Layers

 





REQ-2: Transparency to Upper Layers
The DMM solutions SHALL enable transparency above the IP layer. Such transp= arency is needed for the application flows that cannot cope with a change o= f IP address and when mobile hosts or entire mobile networks change their p= oint of attachment to the Internet, but SHOULD NOT be taken as the default behavior.
>>>>= >> Comments
(1) What scenari= o is that "entire mobile networks change their point of attachment to = the internet"?
 
REQ-2M (Motivation for REQ-2)
The goal of this requirement is to
enable more efficient use of network resources and more efficient routing b= y 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 no= t change the point of attachment. In these situations that do not require IP mobility support, network resou= rces 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.
>>>>= >> Comments
(1) I have the s= ame concern as LuoWen does.  We should be more clear what are we refer= ring 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 p= er-MN localization information and security context.  I believe that t= he "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 in= fo.
>>>>= > 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 no= t change the point of attachment. In these situations that do not require IP mobility support, network resou= rces are wasted when including additional info to the mobility context to s= upport the changing the point of attachment. Network resources are also was= ted 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 nee= ded. 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-centr= icity is to provide mobility support to all mobile nodes by default regardl= ess 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
dmm@ietf.org
https://www.ietf.org/mailman/listinfo/dmm<= br> _______________________________= ________________
dmm mailing list
dmm@ietf.org
https://www.ietf.org/mailman/listinfo/dmm

 
--------------------------------------------------------

ZTE Information Security Notice: The informat=
ion contained in this mail is solely pro=
perty of the sender's organization. This mail=
 communication is confidential. Recipients named&n=
bsp;above are obligated to maintain secrecy a=
nd are not permitted to disclose the con=
tents of this communication to others.<=
/pre>

This email and any files transmitted wit=
h it are confidential and intended solely&nbs=
p;for the use of the individual or entit=
y to whom they are addressed. If you&nbs=
p;have received this email in error please&nb=
sp;notify the originator of the message. Any&=
nbsp;views expressed in this message are thos=
e of the individual sender.


This message has been scanned for viruse=
s and Spam by ZTE Anti-Spam system.
--_000_6E31144C030982429702B11D6746B98C1DE04C58SZXEML505MBSchi_-- From h.anthony.chan@huawei.com Wed May 23 14:26:27 2012 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E6F511E8099 for ; Wed, 23 May 2012 14:26:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.497 X-Spam-Level: X-Spam-Status: No, score=-4.497 tagged_above=-999 required=5 tests=[AWL=2.102, 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 2+WQmhn2N13J for ; Wed, 23 May 2012 14:26:26 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id C212511E8080 for ; Wed, 23 May 2012 14:26:26 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml202-edg.china.huawei.com) ([172.18.9.243]) by dfwrg02-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AGE89628; Wed, 23 May 2012 17:26:26 -0400 (EDT) Received: from DFWEML403-HUB.china.huawei.com (10.193.5.151) by dfweml202-edg.china.huawei.com (172.18.9.108) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 23 May 2012 14:25:07 -0700 Received: from SZXEML413-HUB.china.huawei.com (10.82.67.152) by dfweml403-hub.china.huawei.com (10.193.5.151) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 23 May 2012 14:25:05 -0700 Received: from SZXEML505-MBS.china.huawei.com ([169.254.2.245]) by szxeml413-hub.china.huawei.com ([10.82.67.152]) with mapi id 14.01.0323.003; Thu, 24 May 2012 05:24:52 +0800 From: h chan To: Peter McCann , jouni korhonen Thread-Topic: [DMM] draft requirement REQ-5: Mobile IP based Thread-Index: AQHNNImgQn2qlSOe806lg5Ox2L3oZ5bPpNcwgAhGztA= Date: Wed, 23 May 2012 21:24:52 +0000 Message-ID: <6E31144C030982429702B11D6746B98C1DE04D3F@SZXEML505-MBS.china.huawei.com> References: <6E31144C030982429702B11D6746B98C1DDFB537@SZXEML505-MBS.china.huawei.com> <3436461C-2DF8-4E14-8889-323AEF4AA079@gmail.com> <5963DDF1F751474D8DEEFDCDBEE43AE716E0427A@dfweml512-mbx.china.huawei.com> In-Reply-To: <5963DDF1F751474D8DEEFDCDBEE43AE716E0427A@dfweml512-mbx.china.huawei.com> Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.144.148] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "dmm@ietf.org" Subject: Re: [DMM] draft requirement REQ-5: Mobile IP based X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 May 2012 21:26:27 -0000 Clean up the text below: REQ-5: Mobile IP based A DMM solution that relies on a mobility protocol SHOULD be based on existi= ng mobility protocol, such as Mobile IPv6 [RFC6275, 5555], Proxy Mobile IPv= 6 [RFC5213, 5844], NEMO [RFC3963], and [I-D.ietf-netext-pd-pmip].=20 (assuming the PMIPv6 PD will have an rfc number later to update this requir= ement) REQ-5M (Motivation for REQ-5): The motivation is to reuse the existing protocol first before considering n= ew protocols. H Anthony Chan -----Original Message----- From: Peter McCann=20 Sent: Friday, May 18, 2012 10:01 AM To: jouni korhonen; h chan Cc: dmm@ietf.org Subject: RE: [DMM] draft requirement REQ-5: Mobile IP based Hi, Jouni, jouni korhonen wrote: >=20 > On May 7, 2012, at 9:11 PM, h chan wrote: >=20 >> REQ-5: Mobile IP based >> The DMM solutions based on existing host- or network-based mobility > protocols, such as Mobile IPv6 [RFC6275, 5555], Proxy Mobile IPv6 > [RFC5213, 5844] and NEMO [RFC3963], SHOULD be preferred, unless they > fail to meet any of the other requirements. >=20 > What about something on the lines with: >=20 > "A DMM solution that relies on a mobility protocol should be based on > existing mobility protocol, such as .." Sounds good to me. -Pete > - Jouni >=20 >> REQ-5M (Motivation for REQ-5) The motivation is to reuse the existing >> protocol first before considering new protocols. >>=20 >> (The above has been drafted with contributions, inputs and discussions >> from various people. Additional contributions and comments are most >> welcome.) >>=20 >> H Anthony Chan >>=20 >>=20 >> _______________________________________________ >> dmm mailing list >> dmm@ietf.org >> https://www.ietf.org/mailman/listinfo/dmm >=20 > _______________________________________________ > dmm mailing list > dmm@ietf.org > https://www.ietf.org/mailman/listinfo/dmm From h.anthony.chan@huawei.com Wed May 23 15:19:11 2012 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 26D5311E80B3 for ; Wed, 23 May 2012 15:19:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.548 X-Spam-Level: X-Spam-Status: No, score=-5.548 tagged_above=-999 required=5 tests=[AWL=1.051, 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 QZg-tIFKYdYC for ; Wed, 23 May 2012 15:19:09 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id 8553E11E80B1 for ; Wed, 23 May 2012 15:19:09 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml202-edg.china.huawei.com) ([172.18.9.243]) by dfwrg02-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AGE92469; Wed, 23 May 2012 18:19:09 -0400 (EDT) Received: from DFWEML405-HUB.china.huawei.com (10.193.5.102) by dfweml202-edg.china.huawei.com (172.18.9.108) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 23 May 2012 15:16:27 -0700 Received: from SZXEML415-HUB.china.huawei.com (10.82.67.154) by dfweml405-hub.china.huawei.com (10.193.5.102) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 23 May 2012 15:16:26 -0700 Received: from SZXEML505-MBS.china.huawei.com ([169.254.2.245]) by szxeml415-hub.china.huawei.com ([10.82.67.154]) with mapi id 14.01.0323.003; Thu, 24 May 2012 06:16:13 +0800 From: h chan To: Jouni , Peter McCann Thread-Topic: [DMM] draft requirement REQ-1: Distributed deployment Thread-Index: AQHNNaECgC7rQqJQfUavC0eCI3rcQZbX9pRA Date: Wed, 23 May 2012 22:16:11 +0000 Message-ID: <6E31144C030982429702B11D6746B98C1DE04D56@SZXEML505-MBS.china.huawei.com> References: <6E31144C030982429702B11D6746B98C1DDFB507@SZXEML505-MBS.china.huawei.com> <9170BC9C-68E5-48F4-947F-9126FA8B8CFD@gmail.com> <5963DDF1F751474D8DEEFDCDBEE43AE716E04252@dfweml512-mbx.china.huawei.com> <6964EF2A-397A-4B2B-BD24-B6C85A21482F@gmail.com> In-Reply-To: <6964EF2A-397A-4B2B-BD24-B6C85A21482F@gmail.com> Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.144.148] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "dmm@ietf.org" Subject: Re: [DMM] draft requirement REQ-1: Distributed deployment X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 May 2012 22:19:11 -0000 >> More flat is kind of superfluous.. Let us just say "as network architecture flattens" rather than "become more= flatten" to include the flattening that is already happening.=20 H Anthony Chan -----Original Message----- From: Jouni [mailto:jouni.nospam@gmail.com]=20 Sent: Saturday, May 19, 2012 4:23 AM To: Peter McCann Cc: h chan; dmm@ietf.org Subject: Re: [DMM] draft requirement REQ-1: Distributed deployment Hi On May 18, 2012, at 5:55 PM, Peter McCann wrote: > Hi, Jouni, >=20 > jouni korhonen wrote: >> Breaking the silence.. >>=20 >> On May 7, 2012, at 8:55 PM, h chan wrote: >>=20 >>> REQ-1: Distributed deployment >>> IP mobility, network access and routing solutions provided by DMM >>> SHALL enable the functions of mobility management of IP sessions to be >>> distributed so that the traffic is routed in an optimal manner without >>> relying on centrally deployed anchors. >>=20 >> Few comments/questions.. >> o "SHALL enable the functions of mobility management" does that imply >> the >> DMM "solution" must always involve or extend a mobility protocol? IMHO >> that should not be a SHALL requirement. >=20 > To the extent that DMM provides an "IP mobility...solution" I think it do= es > involve or extend a mobility protocol. However, I don't think the requir= ement > implies that we will necessarily extend an existing mobility protocol. Excerpt from the charter: on managing the use of care-of versus home addresses in an efficient manner for different types of communications. Just making sure the right flavor or address is used does not necessarily extend or require any mobility protocol support. >> o "centrally deployed anchors" what if the access network routing is >> laid >> out in a way that even pure IP routing would lead packets to go >> through a central site/edge router? Doesn't that lead to similar >> deficiencies than with mobility anchors? >=20 > It does indeed, which is why a good network deployment will have redundan= t > back-up paths throughout the network. Unfortunately, it is difficult to > provide redundancy when the path involves tunnel state at an anchor point= . >=20 >>> REQ-1M (Motivation for REQ-1) >>> The goals of this requirement are to match mobility deployment with >>> current trend in network evolution: >>> more cost and resource effective to cache and distribute contents when >>> combining distributed anchors with caching systems (e.g., CDN); >>> improve scalability; reduce signaling overhead; avoid single point of >>> failure; mitigate threats being focused on a centrally deployed >>> anchor, e.g., home agent and local mobility anchor. >>=20 >> Reduce signaling overhead.. is a very good goal. However, if any DMM >> solution builds on top of an existing mobility protocol that hardly >> reduces anything. Also if setting up optimal routes require >> establishing new tunnels, signaling is bound to increase. I would say >> here "does not increase the amount of present signaling" and the aim >> for solutions that would reduce it somehow. >=20 > It should be possible to completely avoid mobility management signaling > when the MN is stationary or doesn't need a fixed address. I would say > that reduces signaling. >From that point view ok. Extra care is then needed that one does not move the signaling to another layer.. take DSMIP6 (S2c) as an example, which avoids BU/BA exchange but then expanded the IKE signaling :) >>> RELEVANT problems: >>> PS1: Non-optimal routes >>> Routing via a centralized anchor often results in a longer route, >>> and >>> the problem is especially manifested when accessing a local or cache >>> server of a Content Delivery Network (CDN). >>> PS2: Non-optimality in Evolved Network Architecture The centralized >>> mobility management can become non-optimal as Network architecture >>> evolves and become more flattened. >>=20 >> More flat is kind of superfluous.. take e.g. EPS example. You have, in >> an optimal case, an eNodeB connected directly to a combined SGW/PGW >> from the user plane point of view. And the SGW/PGW you can allocate >> close to you eNodeB based on its topological location. How you can >> make that more flat? SGW relocation changes the situation a bit but stil= l.. >=20 > Putting an SGW/PGW (or an LGW) inside in eNB would indeed be a maximally Putting SGW/PGW into eNodeB is not too realistic for a wider are deployment. LGWs we already got out there but the mobility in that case ain't too great as far as I remember. > flat architecture. However, we would then need to deal with a change of > anchor point during the life of a session, which is something that wasn't > contemplated by 3GPP. That is exactly the area that DMM should focus on, > IMHO. With a cost of additional signaling and new tunnel state? >>> PS3: Low scalability of centralized route and mobility context >>> maintenance Setting up such special routes and maintaining the >>> mobility context for each MN is more difficult to scale in a >>> centralized design with a large number of MNs. >>=20 >> Can I assume the mobility context involves a possible per MN tunnel >> state? >=20 > Yes, I think the per-MN tunnel state is part of the mobility context > being talked about here. - Jouni >=20 > -Pete >=20 >>> Distributing the route maintenance function and the mobility context >>> maintenance function among different networks can be more scalable. >>> PS4: Single point of failure and attack Centralized anchoring may be >>> more vulnerable to single point of failure and attack than a >>> distributed system. >>>=20 >>> (The above is drafted with contributions, inputs and discussions >>> from various people. Additional contributions and comments are most >>> welcome.) >>>=20 >>=20 >> - Jouni >>=20 >>=20 >>=20 >>> H Anthony Chan >>>=20 >>>=20 >>> _______________________________________________ >>> dmm mailing list >>> dmm@ietf.org >>> https://www.ietf.org/mailman/listinfo/dmm >>=20 >> _______________________________________________ >> dmm mailing list >> dmm@ietf.org >> https://www.ietf.org/mailman/listinfo/dmm >=20 >=20 >=20 From h.anthony.chan@huawei.com Wed May 23 15:32:42 2012 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0FC6621F85D2 for ; Wed, 23 May 2012 15:32:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.898 X-Spam-Level: X-Spam-Status: No, score=-5.898 tagged_above=-999 required=5 tests=[AWL=0.701, 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 vBUCgNurMK5A for ; Wed, 23 May 2012 15:32:41 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id 5026321F85D1 for ; Wed, 23 May 2012 15:32:41 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml201-edg.china.huawei.com) ([172.18.9.243]) by dfwrg01-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AGL95673; Wed, 23 May 2012 18:32:39 -0400 (EDT) Received: from DFWEML405-HUB.china.huawei.com (10.193.5.102) by dfweml201-edg.china.huawei.com (172.18.9.107) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 23 May 2012 15:31:04 -0700 Received: from SZXEML422-HUB.china.huawei.com (10.82.67.161) by dfweml405-hub.china.huawei.com (10.193.5.102) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 23 May 2012 15:31:09 -0700 Received: from SZXEML505-MBS.china.huawei.com ([169.254.2.245]) by szxeml422-hub.china.huawei.com ([10.82.67.161]) with mapi id 14.01.0323.003; Thu, 24 May 2012 06:31:05 +0800 From: h chan To: jouni korhonen Thread-Topic: [DMM] draft requirement REQ-1: Distributed deployment Thread-Index: AQHNNIc7hMOO3p4fOEOHU91k3f92YZbX/V/g Date: Wed, 23 May 2012 22:31:04 +0000 Message-ID: <6E31144C030982429702B11D6746B98C1DE04D5C@SZXEML505-MBS.china.huawei.com> References: <6E31144C030982429702B11D6746B98C1DDFB507@SZXEML505-MBS.china.huawei.com> <9170BC9C-68E5-48F4-947F-9126FA8B8CFD@gmail.com> In-Reply-To: <9170BC9C-68E5-48F4-947F-9126FA8B8CFD@gmail.com> Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.144.148] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "dmm@ietf.org" Subject: Re: [DMM] draft requirement REQ-1: Distributed deployment X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 May 2012 22:32:42 -0000 o "SHALL enable the functions of mobility management" does that imply the DMM "solution" must always involve or extend a mobility protocol? IMHO that should not be a SHALL requirement. We can reword "functions of mobility management" to avoid such implication.= =20 H Anthony Chan -----Original Message----- From: jouni korhonen [mailto:jouni.nospam@gmail.com]=20 Sent: Thursday, May 17, 2012 6:46 PM To: h chan Cc: dmm@ietf.org Subject: Re: [DMM] draft requirement REQ-1: Distributed deployment Breaking the silence.. On May 7, 2012, at 8:55 PM, h chan wrote: > REQ-1: Distributed deployment > IP mobility, network access and routing solutions provided by DMM SHALL e= nable the functions of mobility management of IP sessions to be distributed= so that the traffic is routed in an optimal manner without relying on cent= rally deployed anchors. Few comments/questions.. o "SHALL enable the functions of mobility management" does that imply the DMM "solution" must always involve or extend a mobility protocol? IMHO that should not be a SHALL requirement. o "centrally deployed anchors" what if the access network routing is laid out in a way that even pure IP routing would lead packets to go through a= =20 central site/edge router? Doesn't that lead to similar deficiencies than with mobility anchors? > =20 > REQ-1M (Motivation for REQ-1) > The goals of this requirement are to > match mobility deployment with current trend in network evolution: more c= ost and resource effective to cache and distribute contents when combining = distributed anchors with caching systems (e.g., CDN); improve scalability; = reduce signaling overhead; avoid single point of failure; mitigate threats = being focused on a centrally deployed anchor, e.g., home agent and local mo= bility anchor. Reduce signaling overhead.. is a very good goal. However, if any DMM solution builds on top of an existing mobility protocol that hardly reduces anything. Also if setting up optimal routes require establishing new tunnels, signaling is bound to increase. I would say here "does not increase the amount of present signaling" and the aim for solutions that would reduce it somehow. > =20 > RELEVANT problems: > PS1: Non-optimal routes > Routing via a centralized anchor often results in a longer route, and the= problem is especially manifested when accessing a local or cache server of= a Content Delivery Network (CDN). > PS2: Non-optimality in Evolved Network Architecture > The centralized mobility management can become non-optimal as Network arc= hitecture evolves and become more flattened. More flat is kind of superfluous.. take e.g. EPS example. You have, in an o= ptimal case, an eNodeB connected directly to a combined SGW/PGW from the user plan= e point of view. And the SGW/PGW you can allocate close to you eNodeB based on its = topological location. How you can make that more flat? SGW relocation changes the situa= tion a bit but still.. > PS3: Low scalability of centralized route and mobility context maintenanc= e > Setting up such special routes and maintaining the mobility context for e= ach MN is more difficult to scale in a centralized design with a large numb= er of MNs. Can I assume the mobility context involves a possible per MN tunnel state? > Distributing the route maintenance function and the mobility context main= tenance function among different networks can be more scalable. > PS4: Single point of failure and attack > Centralized anchoring may be more vulnerable to single point of failure a= nd attack than a distributed system. > =20 > (The above is drafted with contributions, inputs and discussions from var= ious people. Additional contributions and comments are most welcome.) > =20 - Jouni > H Anthony Chan >=20 > =20 > _______________________________________________ > dmm mailing list > dmm@ietf.org > https://www.ietf.org/mailman/listinfo/dmm From h.anthony.chan@huawei.com Wed May 23 15:38:01 2012 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 75F1311E80CD for ; Wed, 23 May 2012 15:38:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.074 X-Spam-Level: X-Spam-Status: No, score=-6.074 tagged_above=-999 required=5 tests=[AWL=0.526, 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 o4UShaPWPh9l for ; Wed, 23 May 2012 15:38:00 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id 7533D11E80CF for ; Wed, 23 May 2012 15:38:00 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml202-edg.china.huawei.com) ([172.18.9.243]) by dfwrg02-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AGE93544; Wed, 23 May 2012 18:38:00 -0400 (EDT) Received: from DFWEML404-HUB.china.huawei.com (10.193.5.203) by dfweml202-edg.china.huawei.com (172.18.9.108) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 23 May 2012 15:34:49 -0700 Received: from SZXEML402-HUB.china.huawei.com (10.82.67.32) by dfweml404-hub.china.huawei.com (10.193.5.203) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 23 May 2012 15:34:47 -0700 Received: from SZXEML505-MBS.china.huawei.com ([169.254.2.245]) by szxeml402-hub.china.huawei.com ([::1]) with mapi id 14.01.0323.003; Thu, 24 May 2012 06:34:42 +0800 From: h chan To: jouni korhonen Thread-Topic: [DMM] draft requirement REQ-1: Distributed deployment Thread-Index: AQHNNIc7hMOO3p4fOEOHU91k3f92YZbX/nNg Date: Wed, 23 May 2012 22:34:41 +0000 Message-ID: <6E31144C030982429702B11D6746B98C1DE04D62@SZXEML505-MBS.china.huawei.com> References: <6E31144C030982429702B11D6746B98C1DDFB507@SZXEML505-MBS.china.huawei.com> <9170BC9C-68E5-48F4-947F-9126FA8B8CFD@gmail.com> In-Reply-To: <9170BC9C-68E5-48F4-947F-9126FA8B8CFD@gmail.com> Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.144.148] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "dmm@ietf.org" Subject: Re: [DMM] draft requirement REQ-1: Distributed deployment X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 May 2012 22:38:01 -0000 o "centrally deployed anchors" what if the access network routing is laid out in a way that even pure IP routing would lead packets to go through a= =20 central site/edge router? Doesn't that lead to similar deficiencies than with mobility anchors? Let us call it "centrally deployed mobility anchors" in the requirement.=20 H Anthony Chan -----Original Message----- From: jouni korhonen [mailto:jouni.nospam@gmail.com]=20 Sent: Thursday, May 17, 2012 6:46 PM To: h chan Cc: dmm@ietf.org Subject: Re: [DMM] draft requirement REQ-1: Distributed deployment Breaking the silence.. On May 7, 2012, at 8:55 PM, h chan wrote: > REQ-1: Distributed deployment > IP mobility, network access and routing solutions provided by DMM SHALL e= nable the functions of mobility management of IP sessions to be distributed= so that the traffic is routed in an optimal manner without relying on cent= rally deployed anchors. Few comments/questions.. o "SHALL enable the functions of mobility management" does that imply the DMM "solution" must always involve or extend a mobility protocol? IMHO that should not be a SHALL requirement. o "centrally deployed anchors" what if the access network routing is laid out in a way that even pure IP routing would lead packets to go through a= =20 central site/edge router? Doesn't that lead to similar deficiencies than with mobility anchors? > =20 > REQ-1M (Motivation for REQ-1) > The goals of this requirement are to > match mobility deployment with current trend in network evolution: more c= ost and resource effective to cache and distribute contents when combining = distributed anchors with caching systems (e.g., CDN); improve scalability; = reduce signaling overhead; avoid single point of failure; mitigate threats = being focused on a centrally deployed anchor, e.g., home agent and local mo= bility anchor. Reduce signaling overhead.. is a very good goal. However, if any DMM solution builds on top of an existing mobility protocol that hardly reduces anything. Also if setting up optimal routes require establishing new tunnels, signaling is bound to increase. I would say here "does not increase the amount of present signaling" and the aim for solutions that would reduce it somehow. > =20 > RELEVANT problems: > PS1: Non-optimal routes > Routing via a centralized anchor often results in a longer route, and the= problem is especially manifested when accessing a local or cache server of= a Content Delivery Network (CDN). > PS2: Non-optimality in Evolved Network Architecture > The centralized mobility management can become non-optimal as Network arc= hitecture evolves and become more flattened. More flat is kind of superfluous.. take e.g. EPS example. You have, in an o= ptimal case, an eNodeB connected directly to a combined SGW/PGW from the user plan= e point of view. And the SGW/PGW you can allocate close to you eNodeB based on its = topological location. How you can make that more flat? SGW relocation changes the situa= tion a bit but still.. > PS3: Low scalability of centralized route and mobility context maintenanc= e > Setting up such special routes and maintaining the mobility context for e= ach MN is more difficult to scale in a centralized design with a large numb= er of MNs. Can I assume the mobility context involves a possible per MN tunnel state? > Distributing the route maintenance function and the mobility context main= tenance function among different networks can be more scalable. > PS4: Single point of failure and attack > Centralized anchoring may be more vulnerable to single point of failure a= nd attack than a distributed system. > =20 > (The above is drafted with contributions, inputs and discussions from var= ious people. Additional contributions and comments are most welcome.) > =20 - Jouni > H Anthony Chan >=20 > =20 > _______________________________________________ > dmm mailing list > dmm@ietf.org > https://www.ietf.org/mailman/listinfo/dmm From h.anthony.chan@huawei.com Wed May 23 16:02:43 2012 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D0B0A21F85BD for ; Wed, 23 May 2012 16:02:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.179 X-Spam-Level: X-Spam-Status: No, score=-6.179 tagged_above=-999 required=5 tests=[AWL=0.420, 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 nIo5PgZTpwTw for ; Wed, 23 May 2012 16:02:43 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id D3E4821F85A2 for ; Wed, 23 May 2012 16:02:42 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml202-edg.china.huawei.com) ([172.18.9.243]) by dfwrg02-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AGE94669; Wed, 23 May 2012 19:02:42 -0400 (EDT) Received: from DFWEML403-HUB.china.huawei.com (10.193.5.151) by dfweml202-edg.china.huawei.com (172.18.9.108) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 23 May 2012 16:01:25 -0700 Received: from SZXEML418-HUB.china.huawei.com (10.82.67.157) by dfweml403-hub.china.huawei.com (10.193.5.151) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 23 May 2012 16:01:23 -0700 Received: from SZXEML505-MBS.china.huawei.com ([169.254.2.245]) by szxeml418-hub.china.huawei.com ([10.82.67.157]) with mapi id 14.01.0323.003; Thu, 24 May 2012 07:01:13 +0800 From: h chan To: Jouni , Peter McCann Thread-Topic: [DMM] draft requirement REQ-1: Distributed deployment Thread-Index: AQHNNaECgC7rQqJQfUavC0eCI3rcQZbYAQvA Date: Wed, 23 May 2012 23:01:13 +0000 Message-ID: <6E31144C030982429702B11D6746B98C1DE04D7A@SZXEML505-MBS.china.huawei.com> References: <6E31144C030982429702B11D6746B98C1DDFB507@SZXEML505-MBS.china.huawei.com> <9170BC9C-68E5-48F4-947F-9126FA8B8CFD@gmail.com> <5963DDF1F751474D8DEEFDCDBEE43AE716E04252@dfweml512-mbx.china.huawei.com> <6964EF2A-397A-4B2B-BD24-B6C85A21482F@gmail.com> In-Reply-To: <6964EF2A-397A-4B2B-BD24-B6C85A21482F@gmail.com> Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.144.148] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "dmm@ietf.org" Subject: Re: [DMM] draft requirement REQ-1: Distributed deployment X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 May 2012 23:02:44 -0000 >> Reduce signaling overhead.. is a very good goal. However, if any DMM=20 >> solution builds on top of an existing mobility protocol that hardly=20 >> reduces anything. Also if setting up optimal routes require=20 >> establishing new tunnels, signaling is bound to increase. I would say=20 >> here "does not increase the amount of present signaling" and the aim=20 >> for solutions that would reduce it somehow. >=20 > It should be possible to completely avoid mobility management=20 > signaling when the MN is stationary or doesn't need a fixed address. =20 > I would say that reduces signaling. ---------------------------- Regarding above comment: I think the reduction of mobility signaling here applies more to REQ-2 (e.g= ., not using the HoA from the previous network you don't need to) but not R= EQ-1. In the motivation for this REQ-1, we can delete "reduce signaling ove= rhead" =20 H Anthony Chan -----Original Message----- From: Jouni [mailto:jouni.nospam@gmail.com]=20 Sent: Saturday, May 19, 2012 4:23 AM To: Peter McCann Cc: h chan; dmm@ietf.org Subject: Re: [DMM] draft requirement REQ-1: Distributed deployment Hi On May 18, 2012, at 5:55 PM, Peter McCann wrote: > Hi, Jouni, >=20 > jouni korhonen wrote: >> Breaking the silence.. >>=20 >> On May 7, 2012, at 8:55 PM, h chan wrote: >>=20 >>> REQ-1: Distributed deployment >>> IP mobility, network access and routing solutions provided by DMM >>> SHALL enable the functions of mobility management of IP sessions to be >>> distributed so that the traffic is routed in an optimal manner without >>> relying on centrally deployed anchors. >>=20 >> Few comments/questions.. >> o "SHALL enable the functions of mobility management" does that imply >> the >> DMM "solution" must always involve or extend a mobility protocol? IMHO >> that should not be a SHALL requirement. >=20 > To the extent that DMM provides an "IP mobility...solution" I think it do= es > involve or extend a mobility protocol. However, I don't think the requir= ement > implies that we will necessarily extend an existing mobility protocol. Excerpt from the charter: on managing the use of care-of versus home addresses in an efficient manner for different types of communications. Just making sure the right flavor or address is used does not necessarily extend or require any mobility protocol support. >> o "centrally deployed anchors" what if the access network routing is >> laid >> out in a way that even pure IP routing would lead packets to go >> through a central site/edge router? Doesn't that lead to similar >> deficiencies than with mobility anchors? >=20 > It does indeed, which is why a good network deployment will have redundan= t > back-up paths throughout the network. Unfortunately, it is difficult to > provide redundancy when the path involves tunnel state at an anchor point= . >=20 >>> REQ-1M (Motivation for REQ-1) >>> The goals of this requirement are to match mobility deployment with >>> current trend in network evolution: >>> more cost and resource effective to cache and distribute contents when >>> combining distributed anchors with caching systems (e.g., CDN); >>> improve scalability; reduce signaling overhead; avoid single point of >>> failure; mitigate threats being focused on a centrally deployed >>> anchor, e.g., home agent and local mobility anchor. >>=20 >> Reduce signaling overhead.. is a very good goal. However, if any DMM >> solution builds on top of an existing mobility protocol that hardly >> reduces anything. Also if setting up optimal routes require >> establishing new tunnels, signaling is bound to increase. I would say >> here "does not increase the amount of present signaling" and the aim >> for solutions that would reduce it somehow. >=20 > It should be possible to completely avoid mobility management signaling > when the MN is stationary or doesn't need a fixed address. I would say > that reduces signaling. >From that point view ok. Extra care is then needed that one does not move the signaling to another layer.. take DSMIP6 (S2c) as an example, which avoids BU/BA exchange but then expanded the IKE signaling :) >>> RELEVANT problems: >>> PS1: Non-optimal routes >>> Routing via a centralized anchor often results in a longer route, >>> and >>> the problem is especially manifested when accessing a local or cache >>> server of a Content Delivery Network (CDN). >>> PS2: Non-optimality in Evolved Network Architecture The centralized >>> mobility management can become non-optimal as Network architecture >>> evolves and become more flattened. >>=20 >> More flat is kind of superfluous.. take e.g. EPS example. You have, in >> an optimal case, an eNodeB connected directly to a combined SGW/PGW >> from the user plane point of view. And the SGW/PGW you can allocate >> close to you eNodeB based on its topological location. How you can >> make that more flat? SGW relocation changes the situation a bit but stil= l.. >=20 > Putting an SGW/PGW (or an LGW) inside in eNB would indeed be a maximally Putting SGW/PGW into eNodeB is not too realistic for a wider are deployment. LGWs we already got out there but the mobility in that case ain't too great as far as I remember. > flat architecture. However, we would then need to deal with a change of > anchor point during the life of a session, which is something that wasn't > contemplated by 3GPP. That is exactly the area that DMM should focus on, > IMHO. With a cost of additional signaling and new tunnel state? >>> PS3: Low scalability of centralized route and mobility context >>> maintenance Setting up such special routes and maintaining the >>> mobility context for each MN is more difficult to scale in a >>> centralized design with a large number of MNs. >>=20 >> Can I assume the mobility context involves a possible per MN tunnel >> state? >=20 > Yes, I think the per-MN tunnel state is part of the mobility context > being talked about here. - Jouni >=20 > -Pete >=20 >>> Distributing the route maintenance function and the mobility context >>> maintenance function among different networks can be more scalable. >>> PS4: Single point of failure and attack Centralized anchoring may be >>> more vulnerable to single point of failure and attack than a >>> distributed system. >>>=20 >>> (The above is drafted with contributions, inputs and discussions >>> from various people. Additional contributions and comments are most >>> welcome.) >>>=20 >>=20 >> - Jouni >>=20 >>=20 >>=20 >>> H Anthony Chan >>>=20 >>>=20 >>> _______________________________________________ >>> dmm mailing list >>> dmm@ietf.org >>> https://www.ietf.org/mailman/listinfo/dmm >>=20 >> _______________________________________________ >> dmm mailing list >> dmm@ietf.org >> https://www.ietf.org/mailman/listinfo/dmm >=20 >=20 >=20 From h.anthony.chan@huawei.com Wed May 23 16:10:23 2012 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CFFBF21F85E3 for ; Wed, 23 May 2012 16:10:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[AWL=0.350, 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 QPD7i754Fc03 for ; Wed, 23 May 2012 16:10:22 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id BD7BC21F85D9 for ; Wed, 23 May 2012 16:10:22 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml202-edg.china.huawei.com) ([172.18.9.243]) by dfwrg02-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AGE95104; Wed, 23 May 2012 19:10:22 -0400 (EDT) Received: from DFWEML407-HUB.china.huawei.com (10.193.5.132) by dfweml202-edg.china.huawei.com (172.18.9.108) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 23 May 2012 16:09:15 -0700 Received: from SZXEML411-HUB.china.huawei.com (10.82.67.138) by dfweml407-hub.china.huawei.com (10.193.5.132) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 23 May 2012 16:09:13 -0700 Received: from SZXEML505-MBS.china.huawei.com ([169.254.2.245]) by szxeml411-hub.china.huawei.com ([::1]) with mapi id 14.01.0323.003; Thu, 24 May 2012 07:08:59 +0800 From: h chan To: Jouni , Peter McCann Thread-Topic: [DMM] draft requirement REQ-1: Distributed deployment Thread-Index: AQHNNaECgC7rQqJQfUavC0eCI3rcQZbYBSrw Date: Wed, 23 May 2012 23:08:59 +0000 Message-ID: <6E31144C030982429702B11D6746B98C1DE04D80@SZXEML505-MBS.china.huawei.com> References: <6E31144C030982429702B11D6746B98C1DDFB507@SZXEML505-MBS.china.huawei.com> <9170BC9C-68E5-48F4-947F-9126FA8B8CFD@gmail.com> <5963DDF1F751474D8DEEFDCDBEE43AE716E04252@dfweml512-mbx.china.huawei.com> <6964EF2A-397A-4B2B-BD24-B6C85A21482F@gmail.com> In-Reply-To: <6964EF2A-397A-4B2B-BD24-B6C85A21482F@gmail.com> Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.144.148] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "dmm@ietf.org" Subject: Re: [DMM] draft requirement REQ-1: Distributed deployment X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 May 2012 23:10:23 -0000 >>> PS3: Low scalability of centralized route and mobility context >>> maintenance Setting up such special routes and maintaining the >>> mobility context for each MN is more difficult to scale in a >>> centralized design with a large number of MNs. >>=20 >> Can I assume the mobility context involves a possible per MN tunnel >> state? >=20 > Yes, I think the per-MN tunnel state is part of the mobility context > being talked about here. ------------------- It looks like the meaning of mobility context is broad and can have differe= nt interpretations. We can specifically name the tunnel state here.=20 H Anthony Chan -----Original Message----- From: Jouni [mailto:jouni.nospam@gmail.com]=20 Sent: Saturday, May 19, 2012 4:23 AM To: Peter McCann Cc: h chan; dmm@ietf.org Subject: Re: [DMM] draft requirement REQ-1: Distributed deployment Hi On May 18, 2012, at 5:55 PM, Peter McCann wrote: > Hi, Jouni, >=20 > jouni korhonen wrote: >> Breaking the silence.. >>=20 >> On May 7, 2012, at 8:55 PM, h chan wrote: >>=20 >>> REQ-1: Distributed deployment >>> IP mobility, network access and routing solutions provided by DMM >>> SHALL enable the functions of mobility management of IP sessions to be >>> distributed so that the traffic is routed in an optimal manner without >>> relying on centrally deployed anchors. >>=20 >> Few comments/questions.. >> o "SHALL enable the functions of mobility management" does that imply >> the >> DMM "solution" must always involve or extend a mobility protocol? IMHO >> that should not be a SHALL requirement. >=20 > To the extent that DMM provides an "IP mobility...solution" I think it do= es > involve or extend a mobility protocol. However, I don't think the requir= ement > implies that we will necessarily extend an existing mobility protocol. Excerpt from the charter: on managing the use of care-of versus home addresses in an efficient manner for different types of communications. Just making sure the right flavor or address is used does not necessarily extend or require any mobility protocol support. >> o "centrally deployed anchors" what if the access network routing is >> laid >> out in a way that even pure IP routing would lead packets to go >> through a central site/edge router? Doesn't that lead to similar >> deficiencies than with mobility anchors? >=20 > It does indeed, which is why a good network deployment will have redundan= t > back-up paths throughout the network. Unfortunately, it is difficult to > provide redundancy when the path involves tunnel state at an anchor point= . >=20 >>> REQ-1M (Motivation for REQ-1) >>> The goals of this requirement are to match mobility deployment with >>> current trend in network evolution: >>> more cost and resource effective to cache and distribute contents when >>> combining distributed anchors with caching systems (e.g., CDN); >>> improve scalability; reduce signaling overhead; avoid single point of >>> failure; mitigate threats being focused on a centrally deployed >>> anchor, e.g., home agent and local mobility anchor. >>=20 >> Reduce signaling overhead.. is a very good goal. However, if any DMM >> solution builds on top of an existing mobility protocol that hardly >> reduces anything. Also if setting up optimal routes require >> establishing new tunnels, signaling is bound to increase. I would say >> here "does not increase the amount of present signaling" and the aim >> for solutions that would reduce it somehow. >=20 > It should be possible to completely avoid mobility management signaling > when the MN is stationary or doesn't need a fixed address. I would say > that reduces signaling. >From that point view ok. Extra care is then needed that one does not move the signaling to another layer.. take DSMIP6 (S2c) as an example, which avoids BU/BA exchange but then expanded the IKE signaling :) >>> RELEVANT problems: >>> PS1: Non-optimal routes >>> Routing via a centralized anchor often results in a longer route, >>> and >>> the problem is especially manifested when accessing a local or cache >>> server of a Content Delivery Network (CDN). >>> PS2: Non-optimality in Evolved Network Architecture The centralized >>> mobility management can become non-optimal as Network architecture >>> evolves and become more flattened. >>=20 >> More flat is kind of superfluous.. take e.g. EPS example. You have, in >> an optimal case, an eNodeB connected directly to a combined SGW/PGW >> from the user plane point of view. And the SGW/PGW you can allocate >> close to you eNodeB based on its topological location. How you can >> make that more flat? SGW relocation changes the situation a bit but stil= l.. >=20 > Putting an SGW/PGW (or an LGW) inside in eNB would indeed be a maximally Putting SGW/PGW into eNodeB is not too realistic for a wider are deployment. LGWs we already got out there but the mobility in that case ain't too great as far as I remember. > flat architecture. However, we would then need to deal with a change of > anchor point during the life of a session, which is something that wasn't > contemplated by 3GPP. That is exactly the area that DMM should focus on, > IMHO. With a cost of additional signaling and new tunnel state? >>> PS3: Low scalability of centralized route and mobility context >>> maintenance Setting up such special routes and maintaining the >>> mobility context for each MN is more difficult to scale in a >>> centralized design with a large number of MNs. >>=20 >> Can I assume the mobility context involves a possible per MN tunnel >> state? >=20 > Yes, I think the per-MN tunnel state is part of the mobility context > being talked about here. - Jouni >=20 > -Pete >=20 >>> Distributing the route maintenance function and the mobility context >>> maintenance function among different networks can be more scalable. >>> PS4: Single point of failure and attack Centralized anchoring may be >>> more vulnerable to single point of failure and attack than a >>> distributed system. >>>=20 >>> (The above is drafted with contributions, inputs and discussions >>> from various people. Additional contributions and comments are most >>> welcome.) >>>=20 >>=20 >> - Jouni >>=20 >>=20 >>=20 >>> H Anthony Chan >>>=20 >>>=20 >>> _______________________________________________ >>> dmm mailing list >>> dmm@ietf.org >>> https://www.ietf.org/mailman/listinfo/dmm >>=20 >> _______________________________________________ >> dmm mailing list >> dmm@ietf.org >> https://www.ietf.org/mailman/listinfo/dmm >=20 >=20 >=20 From h.anthony.chan@huawei.com Wed May 23 16:24:00 2012 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC24911E8088 for ; Wed, 23 May 2012 16:24:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.299 X-Spam-Level: X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[AWL=0.300, 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 HWqxHRIpXQvB for ; Wed, 23 May 2012 16:23:59 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id B18F411E8085 for ; Wed, 23 May 2012 16:23:59 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml202-edg.china.huawei.com) ([172.18.9.243]) by dfwrg01-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AGL98155; Wed, 23 May 2012 19:23:59 -0400 (EDT) Received: from DFWEML403-HUB.china.huawei.com (10.193.5.151) by dfweml202-edg.china.huawei.com (172.18.9.108) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 23 May 2012 16:21:06 -0700 Received: from SZXEML415-HUB.china.huawei.com (10.82.67.154) by dfweml403-hub.china.huawei.com (10.193.5.151) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 23 May 2012 16:21:04 -0700 Received: from SZXEML505-MBS.china.huawei.com ([169.254.2.245]) by szxeml415-hub.china.huawei.com ([10.82.67.154]) with mapi id 14.01.0323.003; Thu, 24 May 2012 07:20:47 +0800 From: h chan To: Jouni , Peter McCann Thread-Topic: [DMM] draft requirement REQ-1: Distributed deployment Thread-Index: AQHNNaECgC7rQqJQfUavC0eCI3rcQZbYBwKA Date: Wed, 23 May 2012 23:20:46 +0000 Message-ID: <6E31144C030982429702B11D6746B98C1DE04D8E@SZXEML505-MBS.china.huawei.com> References: <6E31144C030982429702B11D6746B98C1DDFB507@SZXEML505-MBS.china.huawei.com> <9170BC9C-68E5-48F4-947F-9126FA8B8CFD@gmail.com> <5963DDF1F751474D8DEEFDCDBEE43AE716E04252@dfweml512-mbx.china.huawei.com> <6964EF2A-397A-4B2B-BD24-B6C85A21482F@gmail.com> In-Reply-To: <6964EF2A-397A-4B2B-BD24-B6C85A21482F@gmail.com> Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.144.148] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "dmm@ietf.org" Subject: Re: [DMM] draft requirement REQ-1: Distributed deployment X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 May 2012 23:24:01 -0000 An attempt to clean up the text for REQ-1 below:=20 REQ-1: Distributed deployment=20 IP mobility, network access and routing solutions provided by DMM SHALL ena= ble a distributed deployment of mobility management of IP sessions so that = the traffic can be routed in an optimal manner without traversing centrally= deployed mobility anchors. REQ-1M (Motivation for REQ-1) The goals of this requirement are to match mobility deployment with current= trend in network evolution: more cost and resource effective to cache and = distribute contents when combining distributed anchors with caching systems= (e.g., CDN); improve scalability; avoid single point of failure; mitigate = threats being focused on a centrally deployed anchor, e.g., home agent and = local mobility anchor. RELEVANT problems: PS1: Non-optimal routes Routing via a centralized anchor often results in a longer route, and the p= roblem is especially manifested when accessing a local or cache server of a= Content Delivery Network (CDN). PS2: Non-optimality in Evolved Network Architecture The centralized mobility management becomes non-optimal as network architec= ture evolves and flattens. PS3: Low scalability of centralized route and mobility context maintenance= =20 Setting up such special routes and maintaining the mobility context includi= ng the tunnel state for each MN is more difficult to scale in a centralized= design with a large number of MNs. Distributing the route maintenance func= tion and the mobility context maintenance function among different networks= can be more scalable. PS4: Single point of failure and attack=20 Centralized anchoring may be more vulnerable to single point of failure and= attack than a distributed system. H Anthony Chan -----Original Message----- From: Jouni [mailto:jouni.nospam@gmail.com]=20 Sent: Saturday, May 19, 2012 4:23 AM To: Peter McCann Cc: h chan; dmm@ietf.org Subject: Re: [DMM] draft requirement REQ-1: Distributed deployment Hi On May 18, 2012, at 5:55 PM, Peter McCann wrote: > Hi, Jouni, >=20 > jouni korhonen wrote: >> Breaking the silence.. >>=20 >> On May 7, 2012, at 8:55 PM, h chan wrote: >>=20 >>> REQ-1: Distributed deployment >>> IP mobility, network access and routing solutions provided by DMM >>> SHALL enable the functions of mobility management of IP sessions to be >>> distributed so that the traffic is routed in an optimal manner without >>> relying on centrally deployed anchors. >>=20 >> Few comments/questions.. >> o "SHALL enable the functions of mobility management" does that imply >> the >> DMM "solution" must always involve or extend a mobility protocol? IMHO >> that should not be a SHALL requirement. >=20 > To the extent that DMM provides an "IP mobility...solution" I think it do= es > involve or extend a mobility protocol. However, I don't think the requir= ement > implies that we will necessarily extend an existing mobility protocol. Excerpt from the charter: on managing the use of care-of versus home addresses in an efficient manner for different types of communications. Just making sure the right flavor or address is used does not necessarily extend or require any mobility protocol support. >> o "centrally deployed anchors" what if the access network routing is >> laid >> out in a way that even pure IP routing would lead packets to go >> through a central site/edge router? Doesn't that lead to similar >> deficiencies than with mobility anchors? >=20 > It does indeed, which is why a good network deployment will have redundan= t > back-up paths throughout the network. Unfortunately, it is difficult to > provide redundancy when the path involves tunnel state at an anchor point= . >=20 >>> REQ-1M (Motivation for REQ-1) >>> The goals of this requirement are to match mobility deployment with >>> current trend in network evolution: >>> more cost and resource effective to cache and distribute contents when >>> combining distributed anchors with caching systems (e.g., CDN); >>> improve scalability; reduce signaling overhead; avoid single point of >>> failure; mitigate threats being focused on a centrally deployed >>> anchor, e.g., home agent and local mobility anchor. >>=20 >> Reduce signaling overhead.. is a very good goal. However, if any DMM >> solution builds on top of an existing mobility protocol that hardly >> reduces anything. Also if setting up optimal routes require >> establishing new tunnels, signaling is bound to increase. I would say >> here "does not increase the amount of present signaling" and the aim >> for solutions that would reduce it somehow. >=20 > It should be possible to completely avoid mobility management signaling > when the MN is stationary or doesn't need a fixed address. I would say > that reduces signaling. >From that point view ok. Extra care is then needed that one does not move the signaling to another layer.. take DSMIP6 (S2c) as an example, which avoids BU/BA exchange but then expanded the IKE signaling :) >>> RELEVANT problems: >>> PS1: Non-optimal routes >>> Routing via a centralized anchor often results in a longer route, >>> and >>> the problem is especially manifested when accessing a local or cache >>> server of a Content Delivery Network (CDN). >>> PS2: Non-optimality in Evolved Network Architecture The centralized >>> mobility management can become non-optimal as Network architecture >>> evolves and become more flattened. >>=20 >> More flat is kind of superfluous.. take e.g. EPS example. You have, in >> an optimal case, an eNodeB connected directly to a combined SGW/PGW >> from the user plane point of view. And the SGW/PGW you can allocate >> close to you eNodeB based on its topological location. How you can >> make that more flat? SGW relocation changes the situation a bit but stil= l.. >=20 > Putting an SGW/PGW (or an LGW) inside in eNB would indeed be a maximally Putting SGW/PGW into eNodeB is not too realistic for a wider are deployment. LGWs we already got out there but the mobility in that case ain't too great as far as I remember. > flat architecture. However, we would then need to deal with a change of > anchor point during the life of a session, which is something that wasn't > contemplated by 3GPP. That is exactly the area that DMM should focus on, > IMHO. With a cost of additional signaling and new tunnel state? >>> PS3: Low scalability of centralized route and mobility context >>> maintenance Setting up such special routes and maintaining the >>> mobility context for each MN is more difficult to scale in a >>> centralized design with a large number of MNs. >>=20 >> Can I assume the mobility context involves a possible per MN tunnel >> state? >=20 > Yes, I think the per-MN tunnel state is part of the mobility context > being talked about here. - Jouni >=20 > -Pete >=20 >>> Distributing the route maintenance function and the mobility context >>> maintenance function among different networks can be more scalable. >>> PS4: Single point of failure and attack Centralized anchoring may be >>> more vulnerable to single point of failure and attack than a >>> distributed system. >>>=20 >>> (The above is drafted with contributions, inputs and discussions >>> from various people. Additional contributions and comments are most >>> welcome.) >>>=20 >>=20 >> - Jouni >>=20 >>=20 >>=20 >>> H Anthony Chan >>>=20 >>>=20 >>> _______________________________________________ >>> dmm mailing list >>> dmm@ietf.org >>> https://www.ietf.org/mailman/listinfo/dmm >>=20 >> _______________________________________________ >> dmm mailing list >> dmm@ietf.org >> https://www.ietf.org/mailman/listinfo/dmm >=20 >=20 >=20 From h.anthony.chan@huawei.com Wed May 23 17:11:43 2012 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CFBCA21F8736 for ; Wed, 23 May 2012 17:11:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.336 X-Spam-Level: X-Spam-Status: No, score=-6.336 tagged_above=-999 required=5 tests=[AWL=0.263, 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 cJNLB7d7Jes4 for ; Wed, 23 May 2012 17:11:43 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id 02B1D21F8735 for ; Wed, 23 May 2012 17:11:42 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml202-edg.china.huawei.com) ([172.18.9.243]) by dfwrg02-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AGE97999; Wed, 23 May 2012 20:11:42 -0400 (EDT) Received: from DFWEML405-HUB.china.huawei.com (10.193.5.102) by dfweml202-edg.china.huawei.com (172.18.9.108) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 23 May 2012 17:08:49 -0700 Received: from SZXEML408-HUB.china.huawei.com (10.82.67.95) by dfweml405-hub.china.huawei.com (10.193.5.102) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 23 May 2012 17:08:45 -0700 Received: from SZXEML505-MBS.china.huawei.com ([169.254.2.245]) by szxeml408-hub.china.huawei.com ([10.82.67.95]) with mapi id 14.01.0323.003; Thu, 24 May 2012 08:08:32 +0800 From: h chan To: Peter McCann , jouni korhonen Thread-Topic: [DMM] draft requirement REQ-2: Transparency to Upper Layers Thread-Index: AQHNNIjOdy4Iz0JRzEuH1W1r3jhvK5bPnGNwgAhyM3A= Date: Thu, 24 May 2012 00:08:32 +0000 Message-ID: <6E31144C030982429702B11D6746B98C1DE04DA3@SZXEML505-MBS.china.huawei.com> References: <6E31144C030982429702B11D6746B98C1DDFB50C@SZXEML505-MBS.china.huawei.com> <2630A3D8-5718-4302-AD79-A6680C8CDFB4@gmail.com> <5963DDF1F751474D8DEEFDCDBEE43AE716E04224@dfweml512-mbx.china.huawei.com> In-Reply-To: <5963DDF1F751474D8DEEFDCDBEE43AE716E04224@dfweml512-mbx.china.huawei.com> Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.144.148] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "dmm@ietf.org" Subject: Re: [DMM] draft requirement REQ-2: Transparency to Upper Layers X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 May 2012 00:11:43 -0000 > "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. ------------------------------ Regarding the above comment, we probably need to reword this requirement. T= he intention of this requirement may better be explained with an example. T= he assumption is that there is a mix of different applications and nodes. S= ome 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.=20 To the former, a mobility management solution SHALL meet their need. If a s= olution does not meet their need, we probably cannot call it a mobility man= agement solution. Therefore SHALL is used here.=20 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 netwo= rks change their point of attachment to the Internet, for the application f= lows 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=20 Sent: Friday, May 18, 2012 9:35 AM To: jouni korhonen; h chan Cc: dmm@ietf.org Subject: RE: [DMM] draft requirement REQ-2: Transparency to Upper Layers Hi, Jouni, jouni korhonen wrote: >=20 > Few comments/questions here: >=20 > On May 7, 2012, at 8:58 PM, h chan wrote: >=20 >> 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. >=20 > "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. =20 >> 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. >=20 > 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. >>=20 >> 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. >=20 > 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 >=20 > - Jouni >=20 >=20 >>=20 >> (The above has been drafted with contributions, inputs and discussions >> from various people. Additional contributions and comments are most >> welcome.) >>=20 >> H Anthony Chan >>=20 >>=20 >> _______________________________________________ >> dmm mailing list >> dmm@ietf.org >> https://www.ietf.org/mailman/listinfo/dmm >=20 > _______________________________________________ > dmm mailing list > dmm@ietf.org > https://www.ietf.org/mailman/listinfo/dmm From h.anthony.chan@huawei.com Wed May 23 17:38:38 2012 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E38021F8672 for ; Wed, 23 May 2012 17:38:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.365 X-Spam-Level: X-Spam-Status: No, score=-6.365 tagged_above=-999 required=5 tests=[AWL=0.234, 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 5vu9cgak4zBI for ; Wed, 23 May 2012 17:38:37 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id 5DB4A11E8072 for ; Wed, 23 May 2012 17:38:37 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml201-edg.china.huawei.com) ([172.18.9.243]) by dfwrg02-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AGE99227; Wed, 23 May 2012 20:38:37 -0400 (EDT) Received: from DFWEML404-HUB.china.huawei.com (10.193.5.203) by dfweml201-edg.china.huawei.com (172.18.9.107) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 23 May 2012 17:36:37 -0700 Received: from SZXEML436-HUB.china.huawei.com (10.72.61.64) by dfweml404-hub.china.huawei.com (10.193.5.203) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 23 May 2012 17:36:41 -0700 Received: from SZXEML505-MBS.china.huawei.com ([169.254.2.245]) by szxeml436-hub.china.huawei.com ([10.72.61.64]) with mapi id 14.01.0323.003; Thu, 24 May 2012 08:36:35 +0800 From: h chan To: jouni korhonen , "rute.sofia@ulusofona.pt" Thread-Topic: [DMM] draft requirement REQ-2: Transparency to Upper Layers Thread-Index: AQHNNIjJVHsJRjIffUyH6f6D6t8USJbYHclg Date: Thu, 24 May 2012 00:36:35 +0000 Message-ID: <6E31144C030982429702B11D6746B98C1DE04DBD@SZXEML505-MBS.china.huawei.com> References: <6E31144C030982429702B11D6746B98C1DDFB50C@SZXEML505-MBS.china.huawei.com> <2630A3D8-5718-4302-AD79-A6680C8CDFB4@gmail.com> In-Reply-To: <2630A3D8-5718-4302-AD79-A6680C8CDFB4@gmail.com> Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.144.148] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "dmm@ietf.org" Subject: Re: [DMM] draft requirement REQ-2: Transparency to Upper Layers X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 May 2012 00:38:38 -0000 Rute, Can you explain why it is necessary to introduce the term user centricity h= ere?=20 For the following comment, user centricity is a term used by some researche= r in a sense analogous to the terms scalability, backward compatibility, et= c. 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.=20 H Anthony Chan > OTHER related problem > O-PS1: Mobility signaling overhead with peer-to-peer communication > While mobility management enables a mobile host to be reachable, the host= s may then communicate directly so that the mobility support is no longer n= eeded. Taking the need of mobility support as the default behavior will was= te 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-cen= tricity is to provide mobility support to all mobile nodes by default regar= dless of whether the user needs it or not. I have issues to parse O-PS2.. the motivation makes sense though but the ti= tle "lack of user-centricity" is somewhat confusing.. what does forced/alwa= ys-on mobility support has to do with user centricity? -----Original Message----- From: jouni korhonen [mailto:jouni.nospam@gmail.com]=20 Sent: Thursday, May 17, 2012 6:57 PM To: h chan Cc: dmm@ietf.org Subject: Re: [DMM] draft requirement REQ-2: Transparency to Upper Layers 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 tran= sparency 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 defaul= t 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 transparenc= y completely away if the applications/hosts just don't care whether IP change= s or not? >=20 > 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? > =20 > RELEVANT problem: > PS5: Wasting resources to support mobile nodes not needing mobility suppo= rt > IP mobility support is not always required. For example, some application= s do not need a stable IP address during handover, i.e. IP session continui= ty. 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 f= or many MNs that do not require IP mobility support. > =20 > OTHER related problem > O-PS1: Mobility signaling overhead with peer-to-peer communication > While mobility management enables a mobile host to be reachable, the host= s may then communicate directly so that the mobility support is no longer n= eeded. Taking the need of mobility support as the default behavior will was= te 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-cen= tricity is to provide mobility support to all mobile nodes by default regar= dless 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? - Jouni > =20 > (The above has been drafted with contributions, inputs and discussions fr= om various people. Additional contributions and comments are most welcome.) > =20 > H Anthony Chan >=20 > =20 > _______________________________________________ > dmm mailing list > dmm@ietf.org > https://www.ietf.org/mailman/listinfo/dmm From h.anthony.chan@huawei.com Wed May 23 17:48:15 2012 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A67A511E8088 for ; Wed, 23 May 2012 17:48:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.389 X-Spam-Level: X-Spam-Status: No, score=-6.389 tagged_above=-999 required=5 tests=[AWL=0.210, 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 HUNj7GrW6qY0 for ; Wed, 23 May 2012 17:48:15 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id D4DE611E8072 for ; Wed, 23 May 2012 17:48:14 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml201-edg.china.huawei.com) ([172.18.9.243]) by dfwrg01-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AGM02105; Wed, 23 May 2012 20:48:14 -0400 (EDT) Received: from DFWEML407-HUB.china.huawei.com (10.193.5.132) by dfweml201-edg.china.huawei.com (172.18.9.107) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 23 May 2012 17:46:33 -0700 Received: from SZXEML404-HUB.china.huawei.com (10.82.67.59) by dfweml407-hub.china.huawei.com (10.193.5.132) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 23 May 2012 17:46:37 -0700 Received: from SZXEML505-MBS.china.huawei.com ([169.254.2.245]) by szxeml404-hub.china.huawei.com ([::1]) with mapi id 14.01.0323.003; Thu, 24 May 2012 08:46:26 +0800 From: h chan To: Peter McCann , jouni korhonen Thread-Topic: [DMM] draft requirement REQ-2: Transparency to Upper Layers Thread-Index: AQHNNIjOdy4Iz0JRzEuH1W1r3jhvK5bPnGNwgAiF4wA= Date: Thu, 24 May 2012 00:46:25 +0000 Message-ID: <6E31144C030982429702B11D6746B98C1DE04DCC@SZXEML505-MBS.china.huawei.com> References: <6E31144C030982429702B11D6746B98C1DDFB50C@SZXEML505-MBS.china.huawei.com> <2630A3D8-5718-4302-AD79-A6680C8CDFB4@gmail.com> <5963DDF1F751474D8DEEFDCDBEE43AE716E04224@dfweml512-mbx.china.huawei.com> In-Reply-To: <5963DDF1F751474D8DEEFDCDBEE43AE716E04224@dfweml512-mbx.china.huawei.com> Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.144.148] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "dmm@ietf.org" Subject: Re: [DMM] draft requirement REQ-2: Transparency to Upper Layers X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 May 2012 00:48:15 -0000 >> 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. >=20 > 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. --------------- 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 res= ources and more efficient routing when mobility support is implemented by n= ot invoking it for the application flows and nodes that do not need it.=20 H Anthony Chan -----Original Message----- From: Peter McCann=20 Sent: Friday, May 18, 2012 9:35 AM To: jouni korhonen; h chan Cc: dmm@ietf.org Subject: RE: [DMM] draft requirement REQ-2: Transparency to Upper Layers Hi, Jouni, jouni korhonen wrote: >=20 > Few comments/questions here: >=20 > On May 7, 2012, at 8:58 PM, h chan wrote: >=20 >> 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. >=20 > "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. =20 >> 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. >=20 > 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. >>=20 >> 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. >=20 > 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 >=20 > - Jouni >=20 >=20 >>=20 >> (The above has been drafted with contributions, inputs and discussions >> from various people. Additional contributions and comments are most >> welcome.) >>=20 >> H Anthony Chan >>=20 >>=20 >> _______________________________________________ >> dmm mailing list >> dmm@ietf.org >> https://www.ietf.org/mailman/listinfo/dmm >=20 > _______________________________________________ > dmm mailing list > dmm@ietf.org > https://www.ietf.org/mailman/listinfo/dmm From h.anthony.chan@huawei.com Wed May 23 17:54:14 2012 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3DA7B11E8088 for ; Wed, 23 May 2012 17:54:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.408 X-Spam-Level: X-Spam-Status: No, score=-6.408 tagged_above=-999 required=5 tests=[AWL=0.191, 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 qzEP735Gcgp0 for ; Wed, 23 May 2012 17:54:13 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id 63CF911E8072 for ; Wed, 23 May 2012 17:54:13 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml202-edg.china.huawei.com) ([172.18.9.243]) by dfwrg02-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AGF00087; Wed, 23 May 2012 20:54:13 -0400 (EDT) Received: from DFWEML403-HUB.china.huawei.com (10.193.5.151) by dfweml202-edg.china.huawei.com (172.18.9.108) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 23 May 2012 17:51:31 -0700 Received: from SZXEML414-HUB.china.huawei.com (10.82.67.153) by dfweml403-hub.china.huawei.com (10.193.5.151) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 23 May 2012 17:51:30 -0700 Received: from SZXEML505-MBS.china.huawei.com ([169.254.2.245]) by SZXEML414-HUB.china.huawei.com ([10.82.67.153]) with mapi id 14.01.0323.003; Thu, 24 May 2012 08:51:17 +0800 From: h chan To: Peter McCann , jouni korhonen Thread-Topic: [DMM] draft requirement REQ-2: Transparency to Upper Layers Thread-Index: AQHNNIjOdy4Iz0JRzEuH1W1r3jhvK5bPnGNwgAiIGwA= Date: Thu, 24 May 2012 00:51:17 +0000 Message-ID: <6E31144C030982429702B11D6746B98C1DE04DD2@SZXEML505-MBS.china.huawei.com> References: <6E31144C030982429702B11D6746B98C1DDFB50C@SZXEML505-MBS.china.huawei.com> <2630A3D8-5718-4302-AD79-A6680C8CDFB4@gmail.com> <5963DDF1F751474D8DEEFDCDBEE43AE716E04224@dfweml512-mbx.china.huawei.com> In-Reply-To: <5963DDF1F751474D8DEEFDCDBEE43AE716E04224@dfweml512-mbx.china.huawei.com> Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.144.148] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "dmm@ietf.org" Subject: Re: [DMM] draft requirement REQ-2: Transparency to Upper Layers X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 May 2012 00:54:14 -0000 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 netwo= rks change their point of attachment to the Internet, for the application f= lows 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 res= ources and more efficient routing when mobility support is implemented by n= ot invoking it for the application flows and nodes that do not need it.=20 RELEVANT problem: PS5: Wasting resources to support mobile nodes not needing mobility support= =20 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 no= t change the point of attachment. In these situations that do not require I= P 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 nee= ded. Taking the need of mobility support as the default behavior will waste= network resources.=20 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-centr= icity is to provide mobility support to all mobile nodes by default regardl= ess of whether the user needs it or not. H Anthony Chan -----Original Message----- From: Peter McCann=20 Sent: Friday, May 18, 2012 9:35 AM To: jouni korhonen; h chan Cc: dmm@ietf.org Subject: RE: [DMM] draft requirement REQ-2: Transparency to Upper Layers Hi, Jouni, jouni korhonen wrote: >=20 > Few comments/questions here: >=20 > On May 7, 2012, at 8:58 PM, h chan wrote: >=20 >> 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. >=20 > "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. =20 >> 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. >=20 > 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. >>=20 >> 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. >=20 > 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 >=20 > - Jouni >=20 >=20 >>=20 >> (The above has been drafted with contributions, inputs and discussions >> from various people. Additional contributions and comments are most >> welcome.) >>=20 >> H Anthony Chan >>=20 >>=20 >> _______________________________________________ >> dmm mailing list >> dmm@ietf.org >> https://www.ietf.org/mailman/listinfo/dmm >=20 > _______________________________________________ > dmm mailing list > dmm@ietf.org > https://www.ietf.org/mailman/listinfo/dmm From h.anthony.chan@huawei.com Wed May 23 18:03:02 2012 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C2AA911E80A1 for ; Wed, 23 May 2012 18:03:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.424 X-Spam-Level: X-Spam-Status: No, score=-6.424 tagged_above=-999 required=5 tests=[AWL=0.175, 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 QMtvUOIiyFjw for ; Wed, 23 May 2012 18:03:02 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id 1FD1511E8088 for ; Wed, 23 May 2012 18:03:02 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml202-edg.china.huawei.com) ([172.18.9.243]) by dfwrg01-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AGM02788; Wed, 23 May 2012 21:03:01 -0400 (EDT) Received: from DFWEML404-HUB.china.huawei.com (10.193.5.203) by dfweml202-edg.china.huawei.com (172.18.9.108) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 23 May 2012 18:01:55 -0700 Received: from SZXEML437-HUB.china.huawei.com (10.72.61.72) by dfweml404-hub.china.huawei.com (10.193.5.203) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 23 May 2012 18:01:53 -0700 Received: from SZXEML505-MBS.china.huawei.com ([169.254.2.245]) by szxeml437-hub.china.huawei.com ([10.72.61.72]) with mapi id 14.01.0323.003; Thu, 24 May 2012 09:01:42 +0800 From: h chan To: Peter McCann , jouni korhonen Thread-Topic: [DMM] draft requirement REQ-4: compatibility Thread-Index: AQHNNIlbtoqbJ5yETkOkjeylInPSyJbPpE0QgAiD+UA= Date: Thu, 24 May 2012 01:01:42 +0000 Message-ID: <6E31144C030982429702B11D6746B98C1DE04DF1@SZXEML505-MBS.china.huawei.com> References: <6E31144C030982429702B11D6746B98C1DDFB532@SZXEML505-MBS.china.huawei.com> <570967EC-D26C-4605-833F-267AD2C5AFD0@gmail.com> <5963DDF1F751474D8DEEFDCDBEE43AE716E0426B@dfweml512-mbx.china.huawei.com> In-Reply-To: <5963DDF1F751474D8DEEFDCDBEE43AE716E0426B@dfweml512-mbx.china.huawei.com> Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.144.148] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "dmm@ietf.org" Subject: Re: [DMM] draft requirement REQ-4: compatibility X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 May 2012 01:03:03 -0000 An attempt to clean up the text for REQ-4: REQ-4: compatibility=20 The DMM solutions SHALL support existing network deployment with IPv6 (e.g.= existing IPv6 address assignment), be compatible with other mobility proto= cols, and be interoperable with the network or the mobile hosts/routers tha= t do not support the DMM enabling protocol so that the existing network dep= loyments and end hosts are not broken. REQ-4M (Motivation for REQ-4) Motivation: The motivation of this requirement is not to break existing net= work deployments and end hosts.=20 OTHER related problem O-PS3: Complicated deployment with too many variants and extensions of MIP Deployment is complicated with many variants and extensions of MIP. When in= troducing new functions which may add to the complicity, existing solutions= are more vulnerable to break. H Anthony Chan -----Original Message----- From: Peter McCann=20 Sent: Friday, May 18, 2012 10:00 AM To: jouni korhonen; h chan Cc: dmm@ietf.org Subject: RE: [DMM] draft requirement REQ-4: compatibility Hi, Jouni, jouni korhonen wrote: >=20 > On May 7, 2012, at 9:04 PM, h chan wrote: >=20 >> REQ-4: compatibility >> The DMM solutions SHALL support existing network deployment with >> IPv6 >> (e.g. existing IPv6 address assignment), be compatible with other >> mobility protocols, and be interoperable with the network or the >> mobile hosts/routers that do not support the DMM enabling protocol so >> that the existing network deployments are unaffected. >>=20 >> REQ-4M (Motivation for REQ-4) >> Motivation: The motivation of this requirement is to be able to work >> with network architectures of both hierarchical networks and flattened >> networks, so that the mobility management protocol possesses enough >> flexibility to support different networks, and so that the existing >> networks and hosts are not affected and do not break. >=20 > Isn't the motivation just "SHALL not break existing network > deployments and end hosts" ? > Either the network or the host may not have any idea of the solutions > developed in DMM. I think that's a reasonable simplification. We need a strategy for backwards compatibility. -Pete > - JOuni >=20 >>=20 >> OTHER related problem O-PS3: Complicated deployment with too many >> variants and extensions of MIP Deployment is complicated with many >> variants and extensions of > MIP. When introducing new functions which may add to the complicity, > existing solutions are more vulnerable to break. >>=20 >> (The above has been drafted with contributions, inputs and discussions >> from various people. Additional contributions and comments are most >> welcome.) >>=20 >> H Anthony Chan >>=20 >>=20 >> _______________________________________________ >> dmm mailing list >> dmm@ietf.org >> https://www.ietf.org/mailman/listinfo/dmm >=20 > _______________________________________________ > dmm mailing list > dmm@ietf.org > https://www.ietf.org/mailman/listinfo/dmm From karagian@cs.utwente.nl Wed May 23 23:06:33 2012 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2330121F84AF for ; Wed, 23 May 2012 23:06:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.504 X-Spam-Level: X-Spam-Status: No, score=-0.504 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545] 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 oznITJL60LSV for ; Wed, 23 May 2012 23:06:31 -0700 (PDT) Received: from EXEDGE02.ad.utwente.nl (exedge02.ad.utwente.nl [130.89.5.49]) by ietfa.amsl.com (Postfix) with ESMTP id 255B021F846F for ; Wed, 23 May 2012 23:06:30 -0700 (PDT) Received: from EXHUB01.ad.utwente.nl (130.89.4.228) by EXEDGE02.ad.utwente.nl (130.89.5.49) with Microsoft SMTP Server (TLS) id 14.1.339.1; Thu, 24 May 2012 08:06:32 +0200 Received: from EXMBX04.ad.utwente.nl ([169.254.4.13]) by EXHUB01.ad.utwente.nl ([130.89.4.228]) with mapi id 14.01.0339.001; Thu, 24 May 2012 08:06:28 +0200 From: To: Thread-Topic: [DMM] draft requirement REQ-1: Distributed deployment (single-operator and cross-operator?) Thread-Index: AQHNOXNOO5na3TLobEKwTYGTBLu3pw== Date: Thu, 24 May 2012 06:06:27 +0000 Message-ID: Accept-Language: nl-NL, en-US Content-Language: nl-NL X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [80.60.223.107] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: dmm@ietf.org Subject: Re: [DMM] draft requirement REQ-1: Distributed deployment (single-operator and cross-operator?) X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 May 2012 06:06:33 -0000 Hi Anthony, Hi all, During the last DMM meeting in Paris, I have raised the issue of cross-ope= rator mobility management support.=20 Not sure if this issue can be satisfied by incorporating it into REQ-1 Dist= ributed deployment, or if it will be needed to create an additional require= ment that incorporates the need of supporting both single-operator and cros= s-operator mobility management. Best regards, Georgios ________________________________________ Van: dmm-bounces@ietf.org [dmm-bounces@ietf.org] namens h chan [h.anthony.c= han@huawei.com] Verzonden: donderdag 24 mei 2012 1:20 Aan: Jouni; Peter McCann CC: dmm@ietf.org Onderwerp: Re: [DMM] draft requirement REQ-1: Distributed deployment An attempt to clean up the text for REQ-1 below: REQ-1: Distributed deployment IP mobility, network access and routing solutions provided by DMM SHALL ena= ble a distributed deployment of mobility management of IP sessions so that = the traffic can be routed in an optimal manner without traversing centrally= deployed mobility anchors. REQ-1M (Motivation for REQ-1) The goals of this requirement are to match mobility deployment with current= trend in network evolution: more cost and resource effective to cache and = distribute contents when combining distributed anchors with caching systems= (e.g., CDN); improve scalability; avoid single point of failure; mitigate = threats being focused on a centrally deployed anchor, e.g., home agent and = local mobility anchor. RELEVANT problems: PS1: Non-optimal routes Routing via a centralized anchor often results in a longer route, and the p= roblem is especially manifested when accessing a local or cache server of a= Content Delivery Network (CDN). PS2: Non-optimality in Evolved Network Architecture The centralized mobility management becomes non-optimal as network architec= ture evolves and flattens. PS3: Low scalability of centralized route and mobility context maintenance Setting up such special routes and maintaining the mobility context includi= ng the tunnel state for each MN is more difficult to scale in a centralized= design with a large number of MNs. Distributing the route maintenance func= tion and the mobility context maintenance function among different networks= can be more scalable. PS4: Single point of failure and attack Centralized anchoring may be more vulnerable to single point of failure and= attack than a distributed system. H Anthony Chan -----Original Message----- From: Jouni [mailto:jouni.nospam@gmail.com] Sent: Saturday, May 19, 2012 4:23 AM To: Peter McCann Cc: h chan; dmm@ietf.org Subject: Re: [DMM] draft requirement REQ-1: Distributed deployment Hi On May 18, 2012, at 5:55 PM, Peter McCann wrote: > Hi, Jouni, > > jouni korhonen wrote: >> Breaking the silence.. >> >> On May 7, 2012, at 8:55 PM, h chan wrote: >> >>> REQ-1: Distributed deployment >>> IP mobility, network access and routing solutions provided by DMM >>> SHALL enable the functions of mobility management of IP sessions to be >>> distributed so that the traffic is routed in an optimal manner without >>> relying on centrally deployed anchors. >> >> Few comments/questions.. >> o "SHALL enable the functions of mobility management" does that imply >> the >> DMM "solution" must always involve or extend a mobility protocol? IMHO >> that should not be a SHALL requirement. > > To the extent that DMM provides an "IP mobility...solution" I think it do= es > involve or extend a mobility protocol. However, I don't think the requir= ement > implies that we will necessarily extend an existing mobility protocol. Excerpt from the charter: on managing the use of care-of versus home addresses in an efficient manner for different types of communications. Just making sure the right flavor or address is used does not necessarily extend or require any mobility protocol support. >> o "centrally deployed anchors" what if the access network routing is >> laid >> out in a way that even pure IP routing would lead packets to go >> through a central site/edge router? Doesn't that lead to similar >> deficiencies than with mobility anchors? > > It does indeed, which is why a good network deployment will have redundan= t > back-up paths throughout the network. Unfortunately, it is difficult to > provide redundancy when the path involves tunnel state at an anchor point= . > >>> REQ-1M (Motivation for REQ-1) >>> The goals of this requirement are to match mobility deployment with >>> current trend in network evolution: >>> more cost and resource effective to cache and distribute contents when >>> combining distributed anchors with caching systems (e.g., CDN); >>> improve scalability; reduce signaling overhead; avoid single point of >>> failure; mitigate threats being focused on a centrally deployed >>> anchor, e.g., home agent and local mobility anchor. >> >> Reduce signaling overhead.. is a very good goal. However, if any DMM >> solution builds on top of an existing mobility protocol that hardly >> reduces anything. Also if setting up optimal routes require >> establishing new tunnels, signaling is bound to increase. I would say >> here "does not increase the amount of present signaling" and the aim >> for solutions that would reduce it somehow. > > It should be possible to completely avoid mobility management signaling > when the MN is stationary or doesn't need a fixed address. I would say > that reduces signaling. >From that point view ok. Extra care is then needed that one does not move the signaling to another layer.. take DSMIP6 (S2c) as an example, which avoids BU/BA exchange but then expanded the IKE signaling :) >>> RELEVANT problems: >>> PS1: Non-optimal routes >>> Routing via a centralized anchor often results in a longer route, >>> and >>> the problem is especially manifested when accessing a local or cache >>> server of a Content Delivery Network (CDN). >>> PS2: Non-optimality in Evolved Network Architecture The centralized >>> mobility management can become non-optimal as Network architecture >>> evolves and become more flattened. >> >> More flat is kind of superfluous.. take e.g. EPS example. You have, in >> an optimal case, an eNodeB connected directly to a combined SGW/PGW >> from the user plane point of view. And the SGW/PGW you can allocate >> close to you eNodeB based on its topological location. How you can >> make that more flat? SGW relocation changes the situation a bit but stil= l.. > > Putting an SGW/PGW (or an LGW) inside in eNB would indeed be a maximally Putting SGW/PGW into eNodeB is not too realistic for a wider are deployment. LGWs we already got out there but the mobility in that case ain't too great as far as I remember. > flat architecture. However, we would then need to deal with a change of > anchor point during the life of a session, which is something that wasn't > contemplated by 3GPP. That is exactly the area that DMM should focus on, > IMHO. With a cost of additional signaling and new tunnel state? >>> PS3: Low scalability of centralized route and mobility context >>> maintenance Setting up such special routes and maintaining the >>> mobility context for each MN is more difficult to scale in a >>> centralized design with a large number of MNs. >> >> Can I assume the mobility context involves a possible per MN tunnel >> state? > > Yes, I think the per-MN tunnel state is part of the mobility context > being talked about here. - Jouni > > -Pete > >>> Distributing the route maintenance function and the mobility context >>> maintenance function among different networks can be more scalable. >>> PS4: Single point of failure and attack Centralized anchoring may be >>> more vulnerable to single point of failure and attack than a >>> distributed system. >>> >>> (The above is drafted with contributions, inputs and discussions >>> from various people. Additional contributions and comments are most >>> welcome.) >>> >> >> - Jouni >> >> >> >>> H Anthony Chan >>> >>> >>> _______________________________________________ >>> dmm mailing list >>> dmm@ietf.org >>> https://www.ietf.org/mailman/listinfo/dmm >> >> _______________________________________________ >> dmm mailing list >> dmm@ietf.org >> https://www.ietf.org/mailman/listinfo/dmm > > > _______________________________________________ dmm mailing list dmm@ietf.org https://www.ietf.org/mailman/listinfo/dmm= From rkoodli@cisco.com Tue May 22 16:41:30 2012 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B83D21F86B0 for ; Tue, 22 May 2012 16:41:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] 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 TqLOt4gfNvNE for ; Tue, 22 May 2012 16:41:29 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id 84B4321F86AD for ; Tue, 22 May 2012 16:41:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=rkoodli@cisco.com; l=4604; q=dns/txt; s=iport; t=1337730089; x=1338939689; h=date:subject:from:to:cc:message-id:in-reply-to: mime-version:content-transfer-encoding; bh=pmCt7e3Ak+/qh8UCf6/NBV/kZVMSlF/xYeNLXgsjsPA=; b=IAJv4LOL/+qP4OvVh8vCke7aFrgOxsLdgU29mhneqwl7HVl33BimT/Jl bx+ctKVNgX7b2kwA+T9I1V1i+95Qd08/cO8X5ffj9WhNE8wYQ4pFo00zp ncDAASlQ2nnFh53CTl8/uMaiAURhx6K0gsG6Amtcsc7qSYYygPHfi21ND 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAL0jvE+tJXG+/2dsb2JhbABEtByBB4IVAQEBAwEBAQEPAScCATELBQ0BCBhPBjACBAENBRsHh14DBgULmn6WCg2JTgSKGm6FPQOIQ4xZineDFYFkgwqBNh4 X-IronPort-AV: E=Sophos;i="4.75,641,1330905600"; d="scan'208";a="85666539" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-2.cisco.com with ESMTP; 22 May 2012 23:41:28 +0000 Received: from xbh-rcd-201.cisco.com (xbh-rcd-201.cisco.com [72.163.62.200]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id q4MNfRih012986; Tue, 22 May 2012 23:41:27 GMT Received: from xmb-rcd-214.cisco.com ([72.163.62.221]) by xbh-rcd-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 22 May 2012 18:41:27 -0500 Received: from 10.155.70.210 ([10.155.70.210]) by XMB-RCD-214.cisco.com ([72.163.62.221]) with Microsoft Exchange Server HTTP-DAV ; Tue, 22 May 2012 23:41:27 +0000 User-Agent: Microsoft-Entourage/12.24.0.100205 Date: Tue, 22 May 2012 16:48:16 -0700 From: Rajeev Koodli To: Peter McCann , jouni korhonen , h chan Message-ID: Thread-Topic: [DMM] draft requirement REQ-2: Transparency to Upper Layers Thread-Index: AQHNNIjOdy4Iz0JRzEuH1W1r3jhvK5bPIpiAgAB5o6CABuVq2w== In-Reply-To: <5963DDF1F751474D8DEEFDCDBEE43AE716E04231@dfweml512-mbx.china.huawei.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 22 May 2012 23:41:27.0588 (UTC) FILETIME=[68012640:01CD3874] X-Mailman-Approved-At: Thu, 24 May 2012 10:26:17 -0700 Cc: "dmm@ietf.org" Subject: Re: [DMM] draft requirement REQ-2: Transparency to Upper Layers X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 May 2012 23:41:30 -0000 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 On 5/18/12 7:36 AM, "Peter McCann" wrote: > 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: >> >> 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" 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? >>> >>>> >>>> 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? >>> >>>> >>>> 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? >>> >>> - 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 >>>> dmm@ietf.org >>>> https://www.ietf.org/mailman/listinfo/dmm >>> >>> _______________________________________________ >>> dmm mailing list >>> dmm@ietf.org >>> https://www.ietf.org/mailman/listinfo/dmm >> >> _______________________________________________ >> dmm mailing list >> dmm@ietf.org >> https://www.ietf.org/mailman/listinfo/dmm > > > From h.anthony.chan@huawei.com Thu May 24 10:39:37 2012 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 10CCA21F864D for ; Thu, 24 May 2012 10:39:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.437 X-Spam-Level: X-Spam-Status: No, score=-6.437 tagged_above=-999 required=5 tests=[AWL=0.162, 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 JjbJituG0H9Z for ; Thu, 24 May 2012 10:39:36 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id 5A09521F8601 for ; Thu, 24 May 2012 10:39:35 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml202-edg.china.huawei.com) ([172.18.9.243]) by dfwrg01-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AGM67302; Thu, 24 May 2012 13:39:30 -0400 (EDT) Received: from DFWEML406-HUB.china.huawei.com (10.193.5.131) by dfweml202-edg.china.huawei.com (172.18.9.108) with Microsoft SMTP Server (TLS) id 14.1.323.3; Thu, 24 May 2012 10:37:07 -0700 Received: from SZXEML410-HUB.china.huawei.com (10.82.67.137) by dfweml406-hub.china.huawei.com (10.193.5.131) with Microsoft SMTP Server (TLS) id 14.1.323.3; Thu, 24 May 2012 10:37:05 -0700 Received: from SZXEML505-MBS.china.huawei.com ([169.254.2.245]) by szxeml410-hub.china.huawei.com ([10.82.67.137]) with mapi id 14.01.0323.003; Fri, 25 May 2012 01:36:58 +0800 From: h chan To: "karagian@cs.utwente.nl" Thread-Topic: [DMM] draft requirement REQ-1: Distributed deployment (single-operator and cross-operator?) Thread-Index: AQHNOXNOO5na3TLobEKwTYGTBLu3p5bZMw+Q Date: Thu, 24 May 2012 17:36:58 +0000 Message-ID: <6E31144C030982429702B11D6746B98C1DE04EBB@SZXEML505-MBS.china.huawei.com> References: In-Reply-To: Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.144.73] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "dmm@ietf.org" Subject: Re: [DMM] draft requirement REQ-1: Distributed deployment (single-operator and cross-operator?) X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 May 2012 17:39:37 -0000 Georgios, Do you think whether REQ-4 may be a better place to discuss. REQ-4 is talki= ng about compatibility. It already includes compatibility with other (such = as 3GPP) mobility protocols. We can check what else are needed there for cr= oss-operator mobility. If you agree, we can move this cross-operator issue over the REQ-4 thread.= =20 H Anthony Chan -----Original Message----- From: karagian@cs.utwente.nl [mailto:karagian@cs.utwente.nl]=20 Sent: Thursday, May 24, 2012 1:06 AM To: h chan Cc: dmm@ietf.org Subject: RE: [DMM] draft requirement REQ-1: Distributed deployment (single-= operator and cross-operator?) Hi Anthony, Hi all, During the last DMM meeting in Paris, I have raised the issue of cross-ope= rator mobility management support.=20 Not sure if this issue can be satisfied by incorporating it into REQ-1 Dist= ributed deployment, or if it will be needed to create an additional require= ment that incorporates the need of supporting both single-operator and cros= s-operator mobility management. Best regards, Georgios ________________________________________ Van: dmm-bounces@ietf.org [dmm-bounces@ietf.org] namens h chan [h.anthony.c= han@huawei.com] Verzonden: donderdag 24 mei 2012 1:20 Aan: Jouni; Peter McCann CC: dmm@ietf.org Onderwerp: Re: [DMM] draft requirement REQ-1: Distributed deployment An attempt to clean up the text for REQ-1 below: REQ-1: Distributed deployment IP mobility, network access and routing solutions provided by DMM SHALL ena= ble a distributed deployment of mobility management of IP sessions so that = the traffic can be routed in an optimal manner without traversing centrally= deployed mobility anchors. REQ-1M (Motivation for REQ-1) The goals of this requirement are to match mobility deployment with current= trend in network evolution: more cost and resource effective to cache and = distribute contents when combining distributed anchors with caching systems= (e.g., CDN); improve scalability; avoid single point of failure; mitigate = threats being focused on a centrally deployed anchor, e.g., home agent and = local mobility anchor. RELEVANT problems: PS1: Non-optimal routes Routing via a centralized anchor often results in a longer route, and the p= roblem is especially manifested when accessing a local or cache server of a= Content Delivery Network (CDN). PS2: Non-optimality in Evolved Network Architecture The centralized mobility management becomes non-optimal as network architec= ture evolves and flattens. PS3: Low scalability of centralized route and mobility context maintenance Setting up such special routes and maintaining the mobility context includi= ng the tunnel state for each MN is more difficult to scale in a centralized= design with a large number of MNs. Distributing the route maintenance func= tion and the mobility context maintenance function among different networks= can be more scalable. PS4: Single point of failure and attack Centralized anchoring may be more vulnerable to single point of failure and= attack than a distributed system. H Anthony Chan -----Original Message----- From: Jouni [mailto:jouni.nospam@gmail.com] Sent: Saturday, May 19, 2012 4:23 AM To: Peter McCann Cc: h chan; dmm@ietf.org Subject: Re: [DMM] draft requirement REQ-1: Distributed deployment Hi On May 18, 2012, at 5:55 PM, Peter McCann wrote: > Hi, Jouni, > > jouni korhonen wrote: >> Breaking the silence.. >> >> On May 7, 2012, at 8:55 PM, h chan wrote: >> >>> REQ-1: Distributed deployment >>> IP mobility, network access and routing solutions provided by DMM >>> SHALL enable the functions of mobility management of IP sessions to be >>> distributed so that the traffic is routed in an optimal manner without >>> relying on centrally deployed anchors. >> >> Few comments/questions.. >> o "SHALL enable the functions of mobility management" does that imply >> the >> DMM "solution" must always involve or extend a mobility protocol? IMHO >> that should not be a SHALL requirement. > > To the extent that DMM provides an "IP mobility...solution" I think it do= es > involve or extend a mobility protocol. However, I don't think the requir= ement > implies that we will necessarily extend an existing mobility protocol. Excerpt from the charter: on managing the use of care-of versus home addresses in an efficient manner for different types of communications. Just making sure the right flavor or address is used does not necessarily extend or require any mobility protocol support. >> o "centrally deployed anchors" what if the access network routing is >> laid >> out in a way that even pure IP routing would lead packets to go >> through a central site/edge router? Doesn't that lead to similar >> deficiencies than with mobility anchors? > > It does indeed, which is why a good network deployment will have redundan= t > back-up paths throughout the network. Unfortunately, it is difficult to > provide redundancy when the path involves tunnel state at an anchor point= . > >>> REQ-1M (Motivation for REQ-1) >>> The goals of this requirement are to match mobility deployment with >>> current trend in network evolution: >>> more cost and resource effective to cache and distribute contents when >>> combining distributed anchors with caching systems (e.g., CDN); >>> improve scalability; reduce signaling overhead; avoid single point of >>> failure; mitigate threats being focused on a centrally deployed >>> anchor, e.g., home agent and local mobility anchor. >> >> Reduce signaling overhead.. is a very good goal. However, if any DMM >> solution builds on top of an existing mobility protocol that hardly >> reduces anything. Also if setting up optimal routes require >> establishing new tunnels, signaling is bound to increase. I would say >> here "does not increase the amount of present signaling" and the aim >> for solutions that would reduce it somehow. > > It should be possible to completely avoid mobility management signaling > when the MN is stationary or doesn't need a fixed address. I would say > that reduces signaling. >From that point view ok. Extra care is then needed that one does not move the signaling to another layer.. take DSMIP6 (S2c) as an example, which avoids BU/BA exchange but then expanded the IKE signaling :) >>> RELEVANT problems: >>> PS1: Non-optimal routes >>> Routing via a centralized anchor often results in a longer route, >>> and >>> the problem is especially manifested when accessing a local or cache >>> server of a Content Delivery Network (CDN). >>> PS2: Non-optimality in Evolved Network Architecture The centralized >>> mobility management can become non-optimal as Network architecture >>> evolves and become more flattened. >> >> More flat is kind of superfluous.. take e.g. EPS example. You have, in >> an optimal case, an eNodeB connected directly to a combined SGW/PGW >> from the user plane point of view. And the SGW/PGW you can allocate >> close to you eNodeB based on its topological location. How you can >> make that more flat? SGW relocation changes the situation a bit but stil= l.. > > Putting an SGW/PGW (or an LGW) inside in eNB would indeed be a maximally Putting SGW/PGW into eNodeB is not too realistic for a wider are deployment. LGWs we already got out there but the mobility in that case ain't too great as far as I remember. > flat architecture. However, we would then need to deal with a change of > anchor point during the life of a session, which is something that wasn't > contemplated by 3GPP. That is exactly the area that DMM should focus on, > IMHO. With a cost of additional signaling and new tunnel state? >>> PS3: Low scalability of centralized route and mobility context >>> maintenance Setting up such special routes and maintaining the >>> mobility context for each MN is more difficult to scale in a >>> centralized design with a large number of MNs. >> >> Can I assume the mobility context involves a possible per MN tunnel >> state? > > Yes, I think the per-MN tunnel state is part of the mobility context > being talked about here. - Jouni > > -Pete > >>> Distributing the route maintenance function and the mobility context >>> maintenance function among different networks can be more scalable. >>> PS4: Single point of failure and attack Centralized anchoring may be >>> more vulnerable to single point of failure and attack than a >>> distributed system. >>> >>> (The above is drafted with contributions, inputs and discussions >>> from various people. Additional contributions and comments are most >>> welcome.) >>> >> >> - Jouni >> >> >> >>> H Anthony Chan >>> >>> >>> _______________________________________________ >>> dmm mailing list >>> dmm@ietf.org >>> https://www.ietf.org/mailman/listinfo/dmm >> >> _______________________________________________ >> dmm mailing list >> dmm@ietf.org >> https://www.ietf.org/mailman/listinfo/dmm > > > _______________________________________________ dmm mailing list dmm@ietf.org https://www.ietf.org/mailman/listinfo/dmm From karagian@cs.utwente.nl Thu May 24 22:49:26 2012 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 106CB11E80AF for ; Thu, 24 May 2012 22:49:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.504 X-Spam-Level: X-Spam-Status: No, score=-0.504 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545] 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 LQM3J6lQ5r+i for ; Thu, 24 May 2012 22:49:25 -0700 (PDT) Received: from EXEDGE02.ad.utwente.nl (exedge02.ad.utwente.nl [130.89.5.49]) by ietfa.amsl.com (Postfix) with ESMTP id 9C84711E8079 for ; Thu, 24 May 2012 22:49:23 -0700 (PDT) Received: from EXHUB01.ad.utwente.nl (130.89.4.228) by EXEDGE02.ad.utwente.nl (130.89.5.49) with Microsoft SMTP Server (TLS) id 14.1.339.1; Fri, 25 May 2012 07:49:25 +0200 Received: from EXMBX04.ad.utwente.nl ([169.254.4.13]) by EXHUB01.ad.utwente.nl ([130.89.4.228]) with mapi id 14.01.0339.001; Fri, 25 May 2012 07:49:22 +0200 From: To: Thread-Topic: [DMM] draft requirement REQ-1: Distributed deployment (single-operator and cross-operator?) Thread-Index: AQHNOXNOO5na3TLobEKwTYGTBLu3p5bZMw+QgADNa28= Date: Fri, 25 May 2012 05:49:21 +0000 Message-ID: References: , <6E31144C030982429702B11D6746B98C1DE04EBB@SZXEML505-MBS.china.huawei.com> In-Reply-To: <6E31144C030982429702B11D6746B98C1DE04EBB@SZXEML505-MBS.china.huawei.com> Accept-Language: nl-NL, en-US Content-Language: nl-NL X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [80.60.223.107] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: dmm@ietf.org Subject: Re: [DMM] draft requirement REQ-1: Distributed deployment (single-operator and cross-operator?) X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 May 2012 05:49:26 -0000 Hi Anthony, I am not sure whether it can be incorporated in REQ-4 or whether it could b= e considered as being an additional requirement! I am in favour of adding a new requirement that satisfies this issue! Best regards, Georgios ________________________________________ Van: h chan [h.anthony.chan@huawei.com] Verzonden: donderdag 24 mei 2012 19:36 Aan: Karagiannis, G. (EWI) CC: dmm@ietf.org Onderwerp: RE: [DMM] draft requirement REQ-1: Distributed deployment (singl= e-operator and cross-operator?) Georgios, Do you think whether REQ-4 may be a better place to discuss. REQ-4 is talki= ng about compatibility. It already includes compatibility with other (such = as 3GPP) mobility protocols. We can check what else are needed there for cr= oss-operator mobility. If you agree, we can move this cross-operator issue over the REQ-4 thread. H Anthony Chan -----Original Message----- From: karagian@cs.utwente.nl [mailto:karagian@cs.utwente.nl] Sent: Thursday, May 24, 2012 1:06 AM To: h chan Cc: dmm@ietf.org Subject: RE: [DMM] draft requirement REQ-1: Distributed deployment (single-= operator and cross-operator?) Hi Anthony, Hi all, During the last DMM meeting in Paris, I have raised the issue of cross-ope= rator mobility management support. Not sure if this issue can be satisfied by incorporating it into REQ-1 Dist= ributed deployment, or if it will be needed to create an additional require= ment that incorporates the need of supporting both single-operator and cros= s-operator mobility management. Best regards, Georgios ________________________________________ Van: dmm-bounces@ietf.org [dmm-bounces@ietf.org] namens h chan [h.anthony.c= han@huawei.com] Verzonden: donderdag 24 mei 2012 1:20 Aan: Jouni; Peter McCann CC: dmm@ietf.org Onderwerp: Re: [DMM] draft requirement REQ-1: Distributed deployment An attempt to clean up the text for REQ-1 below: REQ-1: Distributed deployment IP mobility, network access and routing solutions provided by DMM SHALL ena= ble a distributed deployment of mobility management of IP sessions so that = the traffic can be routed in an optimal manner without traversing centrally= deployed mobility anchors. REQ-1M (Motivation for REQ-1) The goals of this requirement are to match mobility deployment with current= trend in network evolution: more cost and resource effective to cache and = distribute contents when combining distributed anchors with caching systems= (e.g., CDN); improve scalability; avoid single point of failure; mitigate = threats being focused on a centrally deployed anchor, e.g., home agent and = local mobility anchor. RELEVANT problems: PS1: Non-optimal routes Routing via a centralized anchor often results in a longer route, and the p= roblem is especially manifested when accessing a local or cache server of a= Content Delivery Network (CDN). PS2: Non-optimality in Evolved Network Architecture The centralized mobility management becomes non-optimal as network architec= ture evolves and flattens. PS3: Low scalability of centralized route and mobility context maintenance Setting up such special routes and maintaining the mobility context includi= ng the tunnel state for each MN is more difficult to scale in a centralized= design with a large number of MNs. Distributing the route maintenance func= tion and the mobility context maintenance function among different networks= can be more scalable. PS4: Single point of failure and attack Centralized anchoring may be more vulnerable to single point of failure and= attack than a distributed system. H Anthony Chan -----Original Message----- From: Jouni [mailto:jouni.nospam@gmail.com] Sent: Saturday, May 19, 2012 4:23 AM To: Peter McCann Cc: h chan; dmm@ietf.org Subject: Re: [DMM] draft requirement REQ-1: Distributed deployment Hi On May 18, 2012, at 5:55 PM, Peter McCann wrote: > Hi, Jouni, > > jouni korhonen wrote: >> Breaking the silence.. >> >> On May 7, 2012, at 8:55 PM, h chan wrote: >> >>> REQ-1: Distributed deployment >>> IP mobility, network access and routing solutions provided by DMM >>> SHALL enable the functions of mobility management of IP sessions to be >>> distributed so that the traffic is routed in an optimal manner without >>> relying on centrally deployed anchors. >> >> Few comments/questions.. >> o "SHALL enable the functions of mobility management" does that imply >> the >> DMM "solution" must always involve or extend a mobility protocol? IMHO >> that should not be a SHALL requirement. > > To the extent that DMM provides an "IP mobility...solution" I think it do= es > involve or extend a mobility protocol. However, I don't think the requir= ement > implies that we will necessarily extend an existing mobility protocol. Excerpt from the charter: on managing the use of care-of versus home addresses in an efficient manner for different types of communications. Just making sure the right flavor or address is used does not necessarily extend or require any mobility protocol support. >> o "centrally deployed anchors" what if the access network routing is >> laid >> out in a way that even pure IP routing would lead packets to go >> through a central site/edge router? Doesn't that lead to similar >> deficiencies than with mobility anchors? > > It does indeed, which is why a good network deployment will have redundan= t > back-up paths throughout the network. Unfortunately, it is difficult to > provide redundancy when the path involves tunnel state at an anchor point= . > >>> REQ-1M (Motivation for REQ-1) >>> The goals of this requirement are to match mobility deployment with >>> current trend in network evolution: >>> more cost and resource effective to cache and distribute contents when >>> combining distributed anchors with caching systems (e.g., CDN); >>> improve scalability; reduce signaling overhead; avoid single point of >>> failure; mitigate threats being focused on a centrally deployed >>> anchor, e.g., home agent and local mobility anchor. >> >> Reduce signaling overhead.. is a very good goal. However, if any DMM >> solution builds on top of an existing mobility protocol that hardly >> reduces anything. Also if setting up optimal routes require >> establishing new tunnels, signaling is bound to increase. I would say >> here "does not increase the amount of present signaling" and the aim >> for solutions that would reduce it somehow. > > It should be possible to completely avoid mobility management signaling > when the MN is stationary or doesn't need a fixed address. I would say > that reduces signaling. >From that point view ok. Extra care is then needed that one does not move the signaling to another layer.. take DSMIP6 (S2c) as an example, which avoids BU/BA exchange but then expanded the IKE signaling :) >>> RELEVANT problems: >>> PS1: Non-optimal routes >>> Routing via a centralized anchor often results in a longer route, >>> and >>> the problem is especially manifested when accessing a local or cache >>> server of a Content Delivery Network (CDN). >>> PS2: Non-optimality in Evolved Network Architecture The centralized >>> mobility management can become non-optimal as Network architecture >>> evolves and become more flattened. >> >> More flat is kind of superfluous.. take e.g. EPS example. You have, in >> an optimal case, an eNodeB connected directly to a combined SGW/PGW >> from the user plane point of view. And the SGW/PGW you can allocate >> close to you eNodeB based on its topological location. How you can >> make that more flat? SGW relocation changes the situation a bit but stil= l.. > > Putting an SGW/PGW (or an LGW) inside in eNB would indeed be a maximally Putting SGW/PGW into eNodeB is not too realistic for a wider are deployment. LGWs we already got out there but the mobility in that case ain't too great as far as I remember. > flat architecture. However, we would then need to deal with a change of > anchor point during the life of a session, which is something that wasn't > contemplated by 3GPP. That is exactly the area that DMM should focus on, > IMHO. With a cost of additional signaling and new tunnel state? >>> PS3: Low scalability of centralized route and mobility context >>> maintenance Setting up such special routes and maintaining the >>> mobility context for each MN is more difficult to scale in a >>> centralized design with a large number of MNs. >> >> Can I assume the mobility context involves a possible per MN tunnel >> state? > > Yes, I think the per-MN tunnel state is part of the mobility context > being talked about here. - Jouni > > -Pete > >>> Distributing the route maintenance function and the mobility context >>> maintenance function among different networks can be more scalable. >>> PS4: Single point of failure and attack Centralized anchoring may be >>> more vulnerable to single point of failure and attack than a >>> distributed system. >>> >>> (The above is drafted with contributions, inputs and discussions >>> from various people. Additional contributions and comments are most >>> welcome.) >>> >> >> - Jouni >> >> >> >>> H Anthony Chan >>> >>> >>> _______________________________________________ >>> dmm mailing list >>> dmm@ietf.org >>> https://www.ietf.org/mailman/listinfo/dmm >> >> _______________________________________________ >> dmm mailing list >> dmm@ietf.org >> https://www.ietf.org/mailman/listinfo/dmm > > > _______________________________________________ dmm mailing list dmm@ietf.org https://www.ietf.org/mailman/listinfo/dmm= From pierrick.seite@orange.com Fri May 25 00:48:56 2012 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E692E21F85CD for ; Fri, 25 May 2012 00:48:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, 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 iL+my13eTcgX for ; Fri, 25 May 2012 00:48:55 -0700 (PDT) Received: from r-mail2.rd.francetelecom.com (r-mail2.rd.francetelecom.com [217.108.152.42]) by ietfa.amsl.com (Postfix) with ESMTP id 2F34A21F85C6 for ; Fri, 25 May 2012 00:48:55 -0700 (PDT) Received: from r-mail2.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 4CD8616C002; Fri, 25 May 2012 09:48:53 +0200 (CEST) Received: from ftrdsmtp1.rd.francetelecom.fr (unknown [10.192.128.46]) by r-mail2.rd.francetelecom.com (Postfix) with ESMTP id 351D55D86D0; Fri, 25 May 2012 09:48:53 +0200 (CEST) Received: from ftrdmel0.rd.francetelecom.fr ([10.192.128.56]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Fri, 25 May 2012 09:48:53 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Fri, 25 May 2012 09:48:51 +0200 Message-ID: <843DA8228A1BA74CA31FB4E111A5C462025AC262@ftrdmel0.rd.francetelecom.fr> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [DMM] draft requirement REQ-1: Distributed deployment (single-operator and cross-operator?) Thread-Index: AQHNOXNOO5na3TLobEKwTYGTBLu3p5bZMw+QgADNa2+AAB+IcA== References: , <6E31144C030982429702B11D6746B98C1DE04EBB@SZXEML505-MBS.china.huawei.com> From: To: , X-OriginalArrivalTime: 25 May 2012 07:48:53.0149 (UTC) FILETIME=[D48B1CD0:01CD3A4A] Cc: dmm@ietf.org Subject: Re: [DMM] draft requirement REQ-1: Distributed deployment (single-operator and cross-operator?) X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 May 2012 07:48:57 -0000 Hi Georgios, It seems to me that the requirement: "need of supporting both = single-operator and cross-operator mobility management" is a deployment = requirement. I understand the requirement but I do not see how to = "translate it" into an IP generic wording. FSo, fcusing only on = protocols (as we are supposed to) how would you reformulate your = requirement? Is talking about "capability to establish security = associations between mobility entities" would be acceptable? Br, Pierrick > -----Message d'origine----- > De=A0: dmm-bounces@ietf.org [mailto:dmm-bounces@ietf.org] De la part = de > karagian@cs.utwente.nl > Envoy=E9=A0: vendredi 25 mai 2012 07:49 > =C0=A0: h.anthony.chan@huawei.com > Cc=A0: dmm@ietf.org > Objet=A0: Re: [DMM] draft requirement REQ-1: Distributed deployment > (single-operator and cross-operator?) >=20 > Hi Anthony, >=20 > I am not sure whether it can be incorporated in REQ-4 or whether it > could be considered as being an additional requirement! > I am in favour of adding a new requirement that satisfies this issue! >=20 > Best regards, > Georgios >=20 > ________________________________________ > Van: h chan [h.anthony.chan@huawei.com] > Verzonden: donderdag 24 mei 2012 19:36 > Aan: Karagiannis, G. (EWI) > CC: dmm@ietf.org > Onderwerp: RE: [DMM] draft requirement REQ-1: Distributed deployment > (single-operator and cross-operator?) >=20 > Georgios, >=20 > Do you think whether REQ-4 may be a better place to discuss. REQ-4 is > talking about compatibility. It already includes compatibility with > other (such as 3GPP) mobility protocols. We can check what else are > needed there for cross-operator mobility. >=20 > If you agree, we can move this cross-operator issue over the REQ-4 > thread. >=20 > H Anthony Chan >=20 > -----Original Message----- > From: karagian@cs.utwente.nl [mailto:karagian@cs.utwente.nl] > Sent: Thursday, May 24, 2012 1:06 AM > To: h chan > Cc: dmm@ietf.org > Subject: RE: [DMM] draft requirement REQ-1: Distributed deployment > (single-operator and cross-operator?) >=20 > Hi Anthony, Hi all, >=20 > During the last DMM meeting in Paris, I have raised the issue of > cross-operator mobility management support. > Not sure if this issue can be satisfied by incorporating it into REQ-1 > Distributed deployment, or if it will be needed to create an = additional > requirement that incorporates the need of supporting both single- > operator and cross-operator mobility management. >=20 > Best regards, > Georgios >=20 > ________________________________________ > Van: dmm-bounces@ietf.org [dmm-bounces@ietf.org] namens h chan > [h.anthony.chan@huawei.com] > Verzonden: donderdag 24 mei 2012 1:20 > Aan: Jouni; Peter McCann > CC: dmm@ietf.org > Onderwerp: Re: [DMM] draft requirement REQ-1: Distributed deployment >=20 > An attempt to clean up the text for REQ-1 below: >=20 > REQ-1: Distributed deployment > IP mobility, network access and routing solutions provided by DMM = SHALL > enable a distributed deployment of mobility management of IP sessions > so that the traffic can be routed in an optimal manner without > traversing centrally deployed mobility anchors. > REQ-1M (Motivation for REQ-1) > The goals of this requirement are to match mobility deployment with > current trend in network evolution: more cost and resource effective = to > cache and distribute contents when combining distributed anchors with > caching systems (e.g., CDN); improve scalability; avoid single point = of > failure; mitigate threats being focused on a centrally deployed = anchor, > e.g., home agent and local mobility anchor. > RELEVANT problems: > PS1: Non-optimal routes > Routing via a centralized anchor often results in a longer route, and > the problem is especially manifested when accessing a local or cache > server of a Content Delivery Network (CDN). > PS2: Non-optimality in Evolved Network Architecture > The centralized mobility management becomes non-optimal as network > architecture evolves and flattens. > PS3: Low scalability of centralized route and mobility context > maintenance > Setting up such special routes and maintaining the mobility context > including the tunnel state for each MN is more difficult to scale in a > centralized design with a large number of MNs. Distributing the route > maintenance function and the mobility context maintenance function > among different networks can be more scalable. > PS4: Single point of failure and attack > Centralized anchoring may be more vulnerable to single point of = failure > and attack than a distributed system. >=20 > H Anthony Chan >=20 > -----Original Message----- > From: Jouni [mailto:jouni.nospam@gmail.com] > Sent: Saturday, May 19, 2012 4:23 AM > To: Peter McCann > Cc: h chan; dmm@ietf.org > Subject: Re: [DMM] draft requirement REQ-1: Distributed deployment >=20 >=20 > Hi >=20 > On May 18, 2012, at 5:55 PM, Peter McCann wrote: >=20 > > Hi, Jouni, > > > > jouni korhonen wrote: > >> Breaking the silence.. > >> > >> On May 7, 2012, at 8:55 PM, h chan wrote: > >> > >>> REQ-1: Distributed deployment > >>> IP mobility, network access and routing solutions provided by DMM > >>> SHALL enable the functions of mobility management of IP sessions = to > be > >>> distributed so that the traffic is routed in an optimal manner > without > >>> relying on centrally deployed anchors. > >> > >> Few comments/questions.. > >> o "SHALL enable the functions of mobility management" does that > imply > >> the > >> DMM "solution" must always involve or extend a mobility protocol? > IMHO > >> that should not be a SHALL requirement. > > > > To the extent that DMM provides an "IP mobility...solution" I think > it does > > involve or extend a mobility protocol. However, I don't think the > requirement > > implies that we will necessarily extend an existing mobility > protocol. >=20 > Excerpt from the charter: >=20 > on managing the use of care-of versus home addresses in an > efficient manner for different types of communications. >=20 > Just making sure the right flavor or address is used does not > necessarily > extend or require any mobility protocol support. >=20 > >> o "centrally deployed anchors" what if the access network routing = is > >> laid > >> out in a way that even pure IP routing would lead packets to go > >> through a central site/edge router? Doesn't that lead to similar > >> deficiencies than with mobility anchors? > > > > It does indeed, which is why a good network deployment will have > redundant > > back-up paths throughout the network. Unfortunately, it is = difficult > to > > provide redundancy when the path involves tunnel state at an anchor > point. > > > >>> REQ-1M (Motivation for REQ-1) > >>> The goals of this requirement are to match mobility deployment = with > >>> current trend in network evolution: > >>> more cost and resource effective to cache and distribute contents > when > >>> combining distributed anchors with caching systems (e.g., CDN); > >>> improve scalability; reduce signaling overhead; avoid single point > of > >>> failure; mitigate threats being focused on a centrally deployed > >>> anchor, e.g., home agent and local mobility anchor. > >> > >> Reduce signaling overhead.. is a very good goal. However, if any = DMM > >> solution builds on top of an existing mobility protocol that hardly > >> reduces anything. Also if setting up optimal routes require > >> establishing new tunnels, signaling is bound to increase. I would > say > >> here "does not increase the amount of present signaling" and the = aim > >> for solutions that would reduce it somehow. > > > > It should be possible to completely avoid mobility management > signaling > > when the MN is stationary or doesn't need a fixed address. I would > say > > that reduces signaling. >=20 > From that point view ok. Extra care is then needed that one does not > move the signaling to another layer.. take DSMIP6 (S2c) as an example, > which avoids BU/BA exchange but then expanded the IKE signaling :) >=20 > >>> RELEVANT problems: > >>> PS1: Non-optimal routes > >>> Routing via a centralized anchor often results in a longer route, > >>> and > >>> the problem is especially manifested when accessing a local or > cache > >>> server of a Content Delivery Network (CDN). > >>> PS2: Non-optimality in Evolved Network Architecture The = centralized > >>> mobility management can become non-optimal as Network architecture > >>> evolves and become more flattened. > >> > >> More flat is kind of superfluous.. take e.g. EPS example. You have, > in > >> an optimal case, an eNodeB connected directly to a combined SGW/PGW > >> from the user plane point of view. And the SGW/PGW you can allocate > >> close to you eNodeB based on its topological location. How you can > >> make that more flat? SGW relocation changes the situation a bit but > still.. > > > > Putting an SGW/PGW (or an LGW) inside in eNB would indeed be a > maximally >=20 > Putting SGW/PGW into eNodeB is not too realistic for a wider are > deployment. LGWs we already got out there but the mobility in that > case ain't too great as far as I remember. >=20 > > flat architecture. However, we would then need to deal with a = change > of > > anchor point during the life of a session, which is something that > wasn't > > contemplated by 3GPP. That is exactly the area that DMM should = focus > on, > > IMHO. >=20 > With a cost of additional signaling and new tunnel state? >=20 > >>> PS3: Low scalability of centralized route and mobility context > >>> maintenance Setting up such special routes and maintaining the > >>> mobility context for each MN is more difficult to scale in a > >>> centralized design with a large number of MNs. > >> > >> Can I assume the mobility context involves a possible per MN tunnel > >> state? > > > > Yes, I think the per-MN tunnel state is part of the mobility context > > being talked about here. >=20 > - Jouni >=20 >=20 > > > > -Pete > > > >>> Distributing the route maintenance function and the mobility > context > >>> maintenance function among different networks can be more = scalable. > >>> PS4: Single point of failure and attack Centralized anchoring may > be > >>> more vulnerable to single point of failure and attack than a > >>> distributed system. > >>> > >>> (The above is drafted with contributions, inputs and discussions > >>> from various people. Additional contributions and comments are = most > >>> welcome.) > >>> > >> > >> - Jouni > >> > >> > >> > >>> H Anthony Chan > >>> > >>> > >>> _______________________________________________ > >>> dmm mailing list > >>> dmm@ietf.org > >>> https://www.ietf.org/mailman/listinfo/dmm > >> > >> _______________________________________________ > >> dmm mailing list > >> dmm@ietf.org > >> https://www.ietf.org/mailman/listinfo/dmm > > > > > > >=20 > _______________________________________________ > dmm mailing list > dmm@ietf.org > https://www.ietf.org/mailman/listinfo/dmm > _______________________________________________ > dmm mailing list > dmm@ietf.org > https://www.ietf.org/mailman/listinfo/dmm From karagian@cs.utwente.nl Fri May 25 03:27:54 2012 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3688621F85FF for ; Fri, 25 May 2012 03:27:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.504 X-Spam-Level: X-Spam-Status: No, score=-0.504 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545] 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 SaHhhXpeJ6ir for ; Fri, 25 May 2012 03:27:53 -0700 (PDT) Received: from EXEDGE02.ad.utwente.nl (exedge02.ad.utwente.nl [130.89.5.49]) by ietfa.amsl.com (Postfix) with ESMTP id 8DD5521F85FD for ; Fri, 25 May 2012 03:27:52 -0700 (PDT) Received: from EXHUB02.ad.utwente.nl (130.89.4.229) by EXEDGE02.ad.utwente.nl (130.89.5.49) with Microsoft SMTP Server (TLS) id 14.1.339.1; Fri, 25 May 2012 12:27:54 +0200 Received: from EXMBX04.ad.utwente.nl ([169.254.4.13]) by EXHUB02.ad.utwente.nl ([130.89.4.229]) with mapi id 14.01.0339.001; Fri, 25 May 2012 12:27:51 +0200 From: To: , Thread-Topic: [DMM] draft requirement REQ-1: Distributed deployment (single-operator and cross-operator?) Thread-Index: AQHNOXNOO5na3TLobEKwTYGTBLu3p5bZMw+QgADNa2+AAB+IcIAAJeSA Date: Fri, 25 May 2012 10:27:50 +0000 Message-ID: References: , <6E31144C030982429702B11D6746B98C1DE04EBB@SZXEML505-MBS.china.huawei.com> <843DA8228A1BA74CA31FB4E111A5C462025AC262@ftrdmel0.rd.francetelecom.fr> In-Reply-To: <843DA8228A1BA74CA31FB4E111A5C462025AC262@ftrdmel0.rd.francetelecom.fr> Accept-Language: nl-NL, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.89.12.129] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: dmm@ietf.org Subject: Re: [DMM] draft requirement REQ-1: Distributed deployment (single-operator and cross-operator?) X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 May 2012 10:27:54 -0000 Hi Pierrick, The goal of such a requirement is to emphasize that the DMM protocol(s) tha= t will be designed/specified by the DMM WG should be agnostic to whether us= ers are roaming/moving into wireless coverage area(s) managed by either one= single operator or by more than one operators. I think that this will have an impact on some of the requirements listed a= lready by Anthony! Security association is one such requirement, other requirements are relate= d to for example the possibility of the DMM protocol(s) to (1) easily use = the user profile and mobility information when users are roaming away from = their home operator, (2) use and support seamless, real time and dynamic ch= ange of the mobility anchors that could be located in different communicati= on area(s) managed by different operators. Best regards, Georgios > -----Original Message----- > From: pierrick.seite@orange.com [mailto:pierrick.seite@orange.com] > Sent: vrijdag 25 mei 2012 9:49 > To: Karagiannis, G. (EWI); h.anthony.chan@huawei.com > Cc: dmm@ietf.org > Subject: RE: [DMM] draft requirement REQ-1: Distributed deployment > (single-operator and cross-operator?) >=20 > Hi Georgios, >=20 > It seems to me that the requirement: "need of supporting both single- > operator and cross-operator mobility management" is a deployment > requirement. I understand the requirement but I do not see how to > "translate it" into an IP generic wording. FSo, fcusing only on protocols= (as we > are supposed to) how would you reformulate your requirement? Is talking > about "capability to establish security associations between mobility ent= ities" > would be acceptable? >=20 > Br, > Pierrick >=20 > > -----Message d'origine----- > > De=A0: dmm-bounces@ietf.org [mailto:dmm-bounces@ietf.org] De la part de > > karagian@cs.utwente.nl Envoy=E9=A0: vendredi 25 mai 2012 07:49 =C0=A0: > > h.anthony.chan@huawei.com Cc=A0: dmm@ietf.org Objet=A0: Re: [DMM] draft > > requirement REQ-1: Distributed deployment (single-operator and > > cross-operator?) > > > > Hi Anthony, > > > > I am not sure whether it can be incorporated in REQ-4 or whether it > > could be considered as being an additional requirement! > > I am in favour of adding a new requirement that satisfies this issue! > > > > Best regards, > > Georgios > > > > ________________________________________ > > Van: h chan [h.anthony.chan@huawei.com] > > Verzonden: donderdag 24 mei 2012 19:36 > > Aan: Karagiannis, G. (EWI) > > CC: dmm@ietf.org > > Onderwerp: RE: [DMM] draft requirement REQ-1: Distributed deployment > > (single-operator and cross-operator?) > > > > Georgios, > > > > Do you think whether REQ-4 may be a better place to discuss. REQ-4 is > > talking about compatibility. It already includes compatibility with > > other (such as 3GPP) mobility protocols. We can check what else are > > needed there for cross-operator mobility. > > > > If you agree, we can move this cross-operator issue over the REQ-4 > > thread. > > > > H Anthony Chan > > > > -----Original Message----- > > From: karagian@cs.utwente.nl [mailto:karagian@cs.utwente.nl] > > Sent: Thursday, May 24, 2012 1:06 AM > > To: h chan > > Cc: dmm@ietf.org > > Subject: RE: [DMM] draft requirement REQ-1: Distributed deployment > > (single-operator and cross-operator?) > > > > Hi Anthony, Hi all, > > > > During the last DMM meeting in Paris, I have raised the issue of > > cross-operator mobility management support. > > Not sure if this issue can be satisfied by incorporating it into REQ-1 > > Distributed deployment, or if it will be needed to create an > > additional requirement that incorporates the need of supporting both > > single- operator and cross-operator mobility management. > > > > Best regards, > > Georgios > > > > ________________________________________ > > Van: dmm-bounces@ietf.org [dmm-bounces@ietf.org] namens h chan > > [h.anthony.chan@huawei.com] > > Verzonden: donderdag 24 mei 2012 1:20 > > Aan: Jouni; Peter McCann > > CC: dmm@ietf.org > > Onderwerp: Re: [DMM] draft requirement REQ-1: Distributed deployment > > > > An attempt to clean up the text for REQ-1 below: > > > > REQ-1: Distributed deployment > > IP mobility, network access and routing solutions provided by DMM > > SHALL enable a distributed deployment of mobility management of IP > > sessions so that the traffic can be routed in an optimal manner > > without traversing centrally deployed mobility anchors. > > REQ-1M (Motivation for REQ-1) > > The goals of this requirement are to match mobility deployment with > > current trend in network evolution: more cost and resource effective > > to cache and distribute contents when combining distributed anchors > > with caching systems (e.g., CDN); improve scalability; avoid single > > point of failure; mitigate threats being focused on a centrally > > deployed anchor, e.g., home agent and local mobility anchor. > > RELEVANT problems: > > PS1: Non-optimal routes > > Routing via a centralized anchor often results in a longer route, and > > the problem is especially manifested when accessing a local or cache > > server of a Content Delivery Network (CDN). > > PS2: Non-optimality in Evolved Network Architecture The centralized > > mobility management becomes non-optimal as network architecture > > evolves and flattens. > > PS3: Low scalability of centralized route and mobility context > > maintenance Setting up such special routes and maintaining the > > mobility context including the tunnel state for each MN is more > > difficult to scale in a centralized design with a large number of MNs. > > Distributing the route maintenance function and the mobility context > > maintenance function among different networks can be more scalable. > > PS4: Single point of failure and attack Centralized anchoring may be > > more vulnerable to single point of failure and attack than a > > distributed system. > > > > H Anthony Chan > > > > -----Original Message----- > > From: Jouni [mailto:jouni.nospam@gmail.com] > > Sent: Saturday, May 19, 2012 4:23 AM > > To: Peter McCann > > Cc: h chan; dmm@ietf.org > > Subject: Re: [DMM] draft requirement REQ-1: Distributed deployment > > > > > > Hi > > > > On May 18, 2012, at 5:55 PM, Peter McCann wrote: > > > > > Hi, Jouni, > > > > > > jouni korhonen wrote: > > >> Breaking the silence.. > > >> > > >> On May 7, 2012, at 8:55 PM, h chan wrote: > > >> > > >>> REQ-1: Distributed deployment > > >>> IP mobility, network access and routing solutions provided by DMM > > >>> SHALL enable the functions of mobility management of IP sessions > > >>> to > > be > > >>> distributed so that the traffic is routed in an optimal manner > > without > > >>> relying on centrally deployed anchors. > > >> > > >> Few comments/questions.. > > >> o "SHALL enable the functions of mobility management" does that > > imply > > >> the > > >> DMM "solution" must always involve or extend a mobility protocol? > > IMHO > > >> that should not be a SHALL requirement. > > > > > > To the extent that DMM provides an "IP mobility...solution" I think > > it does > > > involve or extend a mobility protocol. However, I don't think the > > requirement > > > implies that we will necessarily extend an existing mobility > > protocol. > > > > Excerpt from the charter: > > > > on managing the use of care-of versus home addresses in an > > efficient manner for different types of communications. > > > > Just making sure the right flavor or address is used does not > > necessarily extend or require any mobility protocol support. > > > > >> o "centrally deployed anchors" what if the access network routing > > >> is laid out in a way that even pure IP routing would lead packets > > >> to go through a central site/edge router? Doesn't that lead to > > >> similar deficiencies than with mobility anchors? > > > > > > It does indeed, which is why a good network deployment will have > > redundant > > > back-up paths throughout the network. Unfortunately, it is > > > difficult > > to > > > provide redundancy when the path involves tunnel state at an anchor > > point. > > > > > >>> REQ-1M (Motivation for REQ-1) > > >>> The goals of this requirement are to match mobility deployment > > >>> with current trend in network evolution: > > >>> more cost and resource effective to cache and distribute contents > > when > > >>> combining distributed anchors with caching systems (e.g., CDN); > > >>> improve scalability; reduce signaling overhead; avoid single point > > of > > >>> failure; mitigate threats being focused on a centrally deployed > > >>> anchor, e.g., home agent and local mobility anchor. > > >> > > >> Reduce signaling overhead.. is a very good goal. However, if any > > >> DMM solution builds on top of an existing mobility protocol that > > >> hardly reduces anything. Also if setting up optimal routes require > > >> establishing new tunnels, signaling is bound to increase. I would > > say > > >> here "does not increase the amount of present signaling" and the > > >> aim for solutions that would reduce it somehow. > > > > > > It should be possible to completely avoid mobility management > > signaling > > > when the MN is stationary or doesn't need a fixed address. I would > > say > > > that reduces signaling. > > > > From that point view ok. Extra care is then needed that one does not > > move the signaling to another layer.. take DSMIP6 (S2c) as an example, > > which avoids BU/BA exchange but then expanded the IKE signaling :) > > > > >>> RELEVANT problems: > > >>> PS1: Non-optimal routes > > >>> Routing via a centralized anchor often results in a longer route, > > >>> and the problem is especially manifested when accessing a local or > > cache > > >>> server of a Content Delivery Network (CDN). > > >>> PS2: Non-optimality in Evolved Network Architecture The > > >>> centralized mobility management can become non-optimal as Network > > >>> architecture evolves and become more flattened. > > >> > > >> More flat is kind of superfluous.. take e.g. EPS example. You have, > > in > > >> an optimal case, an eNodeB connected directly to a combined > SGW/PGW > > >> from the user plane point of view. And the SGW/PGW you can allocate > > >> close to you eNodeB based on its topological location. How you can > > >> make that more flat? SGW relocation changes the situation a bit but > > still.. > > > > > > Putting an SGW/PGW (or an LGW) inside in eNB would indeed be a > > maximally > > > > Putting SGW/PGW into eNodeB is not too realistic for a wider are > > deployment. LGWs we already got out there but the mobility in that > > case ain't too great as far as I remember. > > > > > flat architecture. However, we would then need to deal with a > > > change > > of > > > anchor point during the life of a session, which is something that > > wasn't > > > contemplated by 3GPP. That is exactly the area that DMM should > > > focus > > on, > > > IMHO. > > > > With a cost of additional signaling and new tunnel state? > > > > >>> PS3: Low scalability of centralized route and mobility context > > >>> maintenance Setting up such special routes and maintaining the > > >>> mobility context for each MN is more difficult to scale in a > > >>> centralized design with a large number of MNs. > > >> > > >> Can I assume the mobility context involves a possible per MN tunnel > > >> state? > > > > > > Yes, I think the per-MN tunnel state is part of the mobility context > > > being talked about here. > > > > - Jouni > > > > > > > > > > -Pete > > > > > >>> Distributing the route maintenance function and the mobility > > context > > >>> maintenance function among different networks can be more scalable. > > >>> PS4: Single point of failure and attack Centralized anchoring may > > be > > >>> more vulnerable to single point of failure and attack than a > > >>> distributed system. > > >>> > > >>> (The above is drafted with contributions, inputs and discussions > > >>> from various people. Additional contributions and comments are > > >>> most > > >>> welcome.) > > >>> > > >> > > >> - Jouni > > >> > > >> > > >> > > >>> H Anthony Chan > > >>> > > >>> > > >>> _______________________________________________ > > >>> dmm mailing list > > >>> dmm@ietf.org > > >>> https://www.ietf.org/mailman/listinfo/dmm > > >> > > >> _______________________________________________ > > >> dmm mailing list > > >> dmm@ietf.org > > >> https://www.ietf.org/mailman/listinfo/dmm > > > > > > > > > > > > > _______________________________________________ > > dmm mailing list > > dmm@ietf.org > > https://www.ietf.org/mailman/listinfo/dmm > > _______________________________________________ > > dmm mailing list > > dmm@ietf.org > > https://www.ietf.org/mailman/listinfo/dmm From pierrick.seite@orange.com Fri May 25 05:00:34 2012 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D143B21F85FD for ; Fri, 25 May 2012 05:00:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, 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 G2GVeYYJSBcW for ; Fri, 25 May 2012 05:00:33 -0700 (PDT) Received: from r-mail1.rd.francetelecom.com (r-mail1.rd.francetelecom.com [217.108.152.41]) by ietfa.amsl.com (Postfix) with ESMTP id F211421F85FB for ; Fri, 25 May 2012 05:00:32 -0700 (PDT) Received: from r-mail1.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 9DAD9A440AF; Fri, 25 May 2012 14:02:04 +0200 (CEST) Received: from ftrdsmtp2.rd.francetelecom.fr (unknown [10.192.128.47]) by r-mail1.rd.francetelecom.com (Postfix) with ESMTP id 8EE33A440AE; Fri, 25 May 2012 14:02:04 +0200 (CEST) Received: from ftrdmel0.rd.francetelecom.fr ([10.192.128.56]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Fri, 25 May 2012 14:00:31 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Fri, 25 May 2012 14:00:29 +0200 Message-ID: <843DA8228A1BA74CA31FB4E111A5C462025AC2EC@ftrdmel0.rd.francetelecom.fr> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [DMM] draft requirement REQ-1: Distributed deployment (single-operator and cross-operator?) Thread-Index: AQHNOXNOO5na3TLobEKwTYGTBLu3p5bZMw+QgADNa2+AAB+IcIAAJeSAgAAZDCA= References: , <6E31144C030982429702B11D6746B98C1DE04EBB@SZXEML505-MBS.china.huawei.com> <843DA8228A1BA74CA31FB4E111A5C462025AC262@ftrdmel0.rd.francetelecom.fr> From: To: , X-OriginalArrivalTime: 25 May 2012 12:00:31.0241 (UTC) FILETIME=[FBB51F90:01CD3A6D] Cc: dmm@ietf.org Subject: Re: [DMM] draft requirement REQ-1: Distributed deployment (single-operator and cross-operator?) X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 May 2012 12:00:34 -0000 Hi, As an operator guy, I will not dispute a use-case dealing with roaming = :-). However I think that it is out of the scope of our considerations = here (I mean, from the IETF standpoint). IMU, the goal of DMM is not to = specify a full system architecture (to which statement (1) below seems = to refer); the goal of DMM is, in a first stage, to assess the use of = legacy protocols in a distributed anchoring deployment.=20 Moreover, statement (2) below, is more a solution hints than a = requirement. Typically, (2) is about HA/LMA relocation which may be, or = not, a solution to meet Anthony's req#1. So, IMHO, req#1 addresses your = concern. That's only my opinion; let's see what others think. BR, Pierrick > -----Message d'origine----- > De=A0: karagian@cs.utwente.nl [mailto:karagian@cs.utwente.nl] > Envoy=E9=A0: vendredi 25 mai 2012 12:28 > =C0=A0: SEITE Pierrick RD-RESA-REN; h.anthony.chan@huawei.com > Cc=A0: dmm@ietf.org > Objet=A0: RE: [DMM] draft requirement REQ-1: Distributed deployment > (single-operator and cross-operator?) >=20 > Hi Pierrick, >=20 > The goal of such a requirement is to emphasize that the DMM = protocol(s) > that will be designed/specified by the DMM WG should be agnostic to > whether users are roaming/moving into wireless coverage area(s) = managed > by either one single operator or by more than one operators. > I think that this will have an impact on some of the requirements > listed already by Anthony! > Security association is one such requirement, other requirements are > related to for example the possibility of the DMM protocol(s) to (1) > easily use the user profile and mobility information when users are > roaming away from their home operator, (2) use and support seamless, > real time and dynamic change of the mobility anchors that could be > located in different communication area(s) managed by different > operators. >=20 > Best regards, > Georgios >=20 >=20 >=20 >=20 >=20 > > -----Original Message----- > > From: pierrick.seite@orange.com [mailto:pierrick.seite@orange.com] > > Sent: vrijdag 25 mei 2012 9:49 > > To: Karagiannis, G. (EWI); h.anthony.chan@huawei.com > > Cc: dmm@ietf.org > > Subject: RE: [DMM] draft requirement REQ-1: Distributed deployment > > (single-operator and cross-operator?) > > > > Hi Georgios, > > > > It seems to me that the requirement: "need of supporting both = single- > > operator and cross-operator mobility management" is a deployment > > requirement. I understand the requirement but I do not see how to > > "translate it" into an IP generic wording. FSo, fcusing only on > protocols (as we > > are supposed to) how would you reformulate your requirement? Is > talking > > about "capability to establish security associations between = mobility > entities" > > would be acceptable? > > > > Br, > > Pierrick > > > > > -----Message d'origine----- > > > De=A0: dmm-bounces@ietf.org [mailto:dmm-bounces@ietf.org] De la = part > de > > > karagian@cs.utwente.nl Envoy=E9=A0: vendredi 25 mai 2012 07:49 = =C0=A0: > > > h.anthony.chan@huawei.com Cc=A0: dmm@ietf.org Objet=A0: Re: [DMM] = draft > > > requirement REQ-1: Distributed deployment (single-operator and > > > cross-operator?) > > > > > > Hi Anthony, > > > > > > I am not sure whether it can be incorporated in REQ-4 or whether = it > > > could be considered as being an additional requirement! > > > I am in favour of adding a new requirement that satisfies this > issue! > > > > > > Best regards, > > > Georgios > > > > > > ________________________________________ > > > Van: h chan [h.anthony.chan@huawei.com] > > > Verzonden: donderdag 24 mei 2012 19:36 > > > Aan: Karagiannis, G. (EWI) > > > CC: dmm@ietf.org > > > Onderwerp: RE: [DMM] draft requirement REQ-1: Distributed > deployment > > > (single-operator and cross-operator?) > > > > > > Georgios, > > > > > > Do you think whether REQ-4 may be a better place to discuss. REQ-4 > is > > > talking about compatibility. It already includes compatibility = with > > > other (such as 3GPP) mobility protocols. We can check what else = are > > > needed there for cross-operator mobility. > > > > > > If you agree, we can move this cross-operator issue over the REQ-4 > > > thread. > > > > > > H Anthony Chan > > > > > > -----Original Message----- > > > From: karagian@cs.utwente.nl [mailto:karagian@cs.utwente.nl] > > > Sent: Thursday, May 24, 2012 1:06 AM > > > To: h chan > > > Cc: dmm@ietf.org > > > Subject: RE: [DMM] draft requirement REQ-1: Distributed deployment > > > (single-operator and cross-operator?) > > > > > > Hi Anthony, Hi all, > > > > > > During the last DMM meeting in Paris, I have raised the issue of > > > cross-operator mobility management support. > > > Not sure if this issue can be satisfied by incorporating it into > REQ-1 > > > Distributed deployment, or if it will be needed to create an > > > additional requirement that incorporates the need of supporting > both > > > single- operator and cross-operator mobility management. > > > > > > Best regards, > > > Georgios > > > > > > ________________________________________ > > > Van: dmm-bounces@ietf.org [dmm-bounces@ietf.org] namens h chan > > > [h.anthony.chan@huawei.com] > > > Verzonden: donderdag 24 mei 2012 1:20 > > > Aan: Jouni; Peter McCann > > > CC: dmm@ietf.org > > > Onderwerp: Re: [DMM] draft requirement REQ-1: Distributed > deployment > > > > > > An attempt to clean up the text for REQ-1 below: > > > > > > REQ-1: Distributed deployment > > > IP mobility, network access and routing solutions provided by DMM > > > SHALL enable a distributed deployment of mobility management of IP > > > sessions so that the traffic can be routed in an optimal manner > > > without traversing centrally deployed mobility anchors. > > > REQ-1M (Motivation for REQ-1) > > > The goals of this requirement are to match mobility deployment = with > > > current trend in network evolution: more cost and resource > effective > > > to cache and distribute contents when combining distributed = anchors > > > with caching systems (e.g., CDN); improve scalability; avoid = single > > > point of failure; mitigate threats being focused on a centrally > > > deployed anchor, e.g., home agent and local mobility anchor. > > > RELEVANT problems: > > > PS1: Non-optimal routes > > > Routing via a centralized anchor often results in a longer route, > and > > > the problem is especially manifested when accessing a local or > cache > > > server of a Content Delivery Network (CDN). > > > PS2: Non-optimality in Evolved Network Architecture The = centralized > > > mobility management becomes non-optimal as network architecture > > > evolves and flattens. > > > PS3: Low scalability of centralized route and mobility context > > > maintenance Setting up such special routes and maintaining the > > > mobility context including the tunnel state for each MN is more > > > difficult to scale in a centralized design with a large number of > MNs. > > > Distributing the route maintenance function and the mobility > context > > > maintenance function among different networks can be more = scalable. > > > PS4: Single point of failure and attack Centralized anchoring may > be > > > more vulnerable to single point of failure and attack than a > > > distributed system. > > > > > > H Anthony Chan > > > > > > -----Original Message----- > > > From: Jouni [mailto:jouni.nospam@gmail.com] > > > Sent: Saturday, May 19, 2012 4:23 AM > > > To: Peter McCann > > > Cc: h chan; dmm@ietf.org > > > Subject: Re: [DMM] draft requirement REQ-1: Distributed deployment > > > > > > > > > Hi > > > > > > On May 18, 2012, at 5:55 PM, Peter McCann wrote: > > > > > > > Hi, Jouni, > > > > > > > > jouni korhonen wrote: > > > >> Breaking the silence.. > > > >> > > > >> On May 7, 2012, at 8:55 PM, h chan wrote: > > > >> > > > >>> REQ-1: Distributed deployment > > > >>> IP mobility, network access and routing solutions provided by > DMM > > > >>> SHALL enable the functions of mobility management of IP > sessions > > > >>> to > > > be > > > >>> distributed so that the traffic is routed in an optimal manner > > > without > > > >>> relying on centrally deployed anchors. > > > >> > > > >> Few comments/questions.. > > > >> o "SHALL enable the functions of mobility management" does that > > > imply > > > >> the > > > >> DMM "solution" must always involve or extend a mobility > protocol? > > > IMHO > > > >> that should not be a SHALL requirement. > > > > > > > > To the extent that DMM provides an "IP mobility...solution" I > think > > > it does > > > > involve or extend a mobility protocol. However, I don't think > the > > > requirement > > > > implies that we will necessarily extend an existing mobility > > > protocol. > > > > > > Excerpt from the charter: > > > > > > on managing the use of care-of versus home addresses in an > > > efficient manner for different types of communications. > > > > > > Just making sure the right flavor or address is used does not > > > necessarily extend or require any mobility protocol support. > > > > > > >> o "centrally deployed anchors" what if the access network > routing > > > >> is laid out in a way that even pure IP routing would lead > packets > > > >> to go through a central site/edge router? Doesn't that lead to > > > >> similar deficiencies than with mobility anchors? > > > > > > > > It does indeed, which is why a good network deployment will have > > > redundant > > > > back-up paths throughout the network. Unfortunately, it is > > > > difficult > > > to > > > > provide redundancy when the path involves tunnel state at an > anchor > > > point. > > > > > > > >>> REQ-1M (Motivation for REQ-1) > > > >>> The goals of this requirement are to match mobility deployment > > > >>> with current trend in network evolution: > > > >>> more cost and resource effective to cache and distribute > contents > > > when > > > >>> combining distributed anchors with caching systems (e.g., = CDN); > > > >>> improve scalability; reduce signaling overhead; avoid single > point > > > of > > > >>> failure; mitigate threats being focused on a centrally = deployed > > > >>> anchor, e.g., home agent and local mobility anchor. > > > >> > > > >> Reduce signaling overhead.. is a very good goal. However, if = any > > > >> DMM solution builds on top of an existing mobility protocol = that > > > >> hardly reduces anything. Also if setting up optimal routes > require > > > >> establishing new tunnels, signaling is bound to increase. I > would > > > say > > > >> here "does not increase the amount of present signaling" and = the > > > >> aim for solutions that would reduce it somehow. > > > > > > > > It should be possible to completely avoid mobility management > > > signaling > > > > when the MN is stationary or doesn't need a fixed address. I > would > > > say > > > > that reduces signaling. > > > > > > From that point view ok. Extra care is then needed that one does > not > > > move the signaling to another layer.. take DSMIP6 (S2c) as an > example, > > > which avoids BU/BA exchange but then expanded the IKE signaling :) > > > > > > >>> RELEVANT problems: > > > >>> PS1: Non-optimal routes > > > >>> Routing via a centralized anchor often results in a longer > route, > > > >>> and the problem is especially manifested when accessing a = local > or > > > cache > > > >>> server of a Content Delivery Network (CDN). > > > >>> PS2: Non-optimality in Evolved Network Architecture The > > > >>> centralized mobility management can become non-optimal as > Network > > > >>> architecture evolves and become more flattened. > > > >> > > > >> More flat is kind of superfluous.. take e.g. EPS example. You > have, > > > in > > > >> an optimal case, an eNodeB connected directly to a combined > > SGW/PGW > > > >> from the user plane point of view. And the SGW/PGW you can > allocate > > > >> close to you eNodeB based on its topological location. How you > can > > > >> make that more flat? SGW relocation changes the situation a bit > but > > > still.. > > > > > > > > Putting an SGW/PGW (or an LGW) inside in eNB would indeed be a > > > maximally > > > > > > Putting SGW/PGW into eNodeB is not too realistic for a wider are > > > deployment. LGWs we already got out there but the mobility in that > > > case ain't too great as far as I remember. > > > > > > > flat architecture. However, we would then need to deal with a > > > > change > > > of > > > > anchor point during the life of a session, which is something > that > > > wasn't > > > > contemplated by 3GPP. That is exactly the area that DMM should > > > > focus > > > on, > > > > IMHO. > > > > > > With a cost of additional signaling and new tunnel state? > > > > > > >>> PS3: Low scalability of centralized route and mobility context > > > >>> maintenance Setting up such special routes and maintaining the > > > >>> mobility context for each MN is more difficult to scale in a > > > >>> centralized design with a large number of MNs. > > > >> > > > >> Can I assume the mobility context involves a possible per MN > tunnel > > > >> state? > > > > > > > > Yes, I think the per-MN tunnel state is part of the mobility > context > > > > being talked about here. > > > > > > - Jouni > > > > > > > > > > > > > > -Pete > > > > > > > >>> Distributing the route maintenance function and the mobility > > > context > > > >>> maintenance function among different networks can be more > scalable. > > > >>> PS4: Single point of failure and attack Centralized anchoring > may > > > be > > > >>> more vulnerable to single point of failure and attack than a > > > >>> distributed system. > > > >>> > > > >>> (The above is drafted with contributions, inputs and > discussions > > > >>> from various people. Additional contributions and comments are > > > >>> most > > > >>> welcome.) > > > >>> > > > >> > > > >> - Jouni > > > >> > > > >> > > > >> > > > >>> H Anthony Chan > > > >>> > > > >>> > > > >>> _______________________________________________ > > > >>> dmm mailing list > > > >>> dmm@ietf.org > > > >>> https://www.ietf.org/mailman/listinfo/dmm > > > >> > > > >> _______________________________________________ > > > >> dmm mailing list > > > >> dmm@ietf.org > > > >> https://www.ietf.org/mailman/listinfo/dmm > > > > > > > > > > > > > > > > > > _______________________________________________ > > > dmm mailing list > > > dmm@ietf.org > > > https://www.ietf.org/mailman/listinfo/dmm > > > _______________________________________________ > > > dmm mailing list > > > dmm@ietf.org > > > https://www.ietf.org/mailman/listinfo/dmm From karagian@cs.utwente.nl Fri May 25 05:21:44 2012 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3CA9221F85FB for ; Fri, 25 May 2012 05:21:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.504 X-Spam-Level: X-Spam-Status: No, score=-0.504 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545] 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 Qkx3iWOn3VJQ for ; Fri, 25 May 2012 05:21:43 -0700 (PDT) Received: from EXEDGE01.ad.utwente.nl (exedge01.ad.utwente.nl [130.89.5.48]) by ietfa.amsl.com (Postfix) with ESMTP id 820F121F85EA for ; Fri, 25 May 2012 05:21:41 -0700 (PDT) Received: from EXHUB02.ad.utwente.nl (130.89.4.229) by EXEDGE01.ad.utwente.nl (130.89.5.48) with Microsoft SMTP Server (TLS) id 14.1.339.1; Fri, 25 May 2012 14:21:50 +0200 Received: from EXMBX04.ad.utwente.nl ([169.254.4.13]) by EXHUB02.ad.utwente.nl ([130.89.4.229]) with mapi id 14.01.0339.001; Fri, 25 May 2012 14:21:40 +0200 From: To: , Thread-Topic: [DMM] draft requirement REQ-1: Distributed deployment (single-operator and cross-operator?) Thread-Index: AQHNOXNOO5na3TLobEKwTYGTBLu3p5bZMw+QgADNa2+AAB+IcIAAJeSAgAAZDCCAAAs9kA== Date: Fri, 25 May 2012 12:21:39 +0000 Message-ID: References: , <6E31144C030982429702B11D6746B98C1DE04EBB@SZXEML505-MBS.china.huawei.com> <843DA8228A1BA74CA31FB4E111A5C462025AC262@ftrdmel0.rd.francetelecom.fr> <843DA8228A1BA74CA31FB4E111A5C462025AC2EC@ftrdmel0.rd.francetelecom.fr> In-Reply-To: <843DA8228A1BA74CA31FB4E111A5C462025AC2EC@ftrdmel0.rd.francetelecom.fr> Accept-Language: nl-NL, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.89.12.129] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: dmm@ietf.org Subject: Re: [DMM] draft requirement REQ-1: Distributed deployment (single-operator and cross-operator?) X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 May 2012 12:21:44 -0000 Hi Pierrick, Please see in line! > -----Original Message----- > From: pierrick.seite@orange.com [mailto:pierrick.seite@orange.com] > Sent: vrijdag 25 mei 2012 14:00 > To: Karagiannis, G. (EWI); h.anthony.chan@huawei.com > Cc: dmm@ietf.org > Subject: RE: [DMM] draft requirement REQ-1: Distributed deployment > (single-operator and cross-operator?) >=20 > Hi, >=20 > As an operator guy, I will not dispute a use-case dealing with roaming :-= ). > However I think that it is out of the scope of our considerations here (I= mean, > from the IETF standpoint). IMU, the goal of DMM is not to specify a full > system architecture (to which statement (1) below seems to refer); the go= al > of DMM is, in a first stage, to assess the use of legacy protocols in a > distributed anchoring deployment. Georgios: Not really defining a system architecture, but more the protocol = framework! The definition of the "distribution anchoring deployment" border= s is part of that! >=20 > Moreover, statement (2) below, is more a solution hints than a requiremen= t. > Typically, (2) is about HA/LMA relocation which may be, or not, a solutio= n to > meet Anthony's req#1. So, IMHO, req#1 addresses your concern. Georgios: I think that the current description of REQ-1 is not really addre= ssing my concern! Best regards, Georgios >=20 > That's only my opinion; let's see what others think. >=20 > BR, > Pierrick >=20 > > -----Message d'origine----- > > De=A0: karagian@cs.utwente.nl [mailto:karagian@cs.utwente.nl] Envoy=E9= =A0: > > vendredi 25 mai 2012 12:28 =C0=A0: SEITE Pierrick RD-RESA-REN; > > h.anthony.chan@huawei.com Cc=A0: dmm@ietf.org Objet=A0: RE: [DMM] draft > > requirement REQ-1: Distributed deployment (single-operator and > > cross-operator?) > > > > Hi Pierrick, > > > > The goal of such a requirement is to emphasize that the DMM > > protocol(s) that will be designed/specified by the DMM WG should be > > agnostic to whether users are roaming/moving into wireless coverage > > area(s) managed by either one single operator or by more than one > operators. > > I think that this will have an impact on some of the requirements > > listed already by Anthony! > > Security association is one such requirement, other requirements are > > related to for example the possibility of the DMM protocol(s) to (1) > > easily use the user profile and mobility information when users are > > roaming away from their home operator, (2) use and support seamless, > > real time and dynamic change of the mobility anchors that could be > > located in different communication area(s) managed by different > > operators. > > > > Best regards, > > Georgios > > > > > > > > > > > > > -----Original Message----- > > > From: pierrick.seite@orange.com [mailto:pierrick.seite@orange.com] > > > Sent: vrijdag 25 mei 2012 9:49 > > > To: Karagiannis, G. (EWI); h.anthony.chan@huawei.com > > > Cc: dmm@ietf.org > > > Subject: RE: [DMM] draft requirement REQ-1: Distributed deployment > > > (single-operator and cross-operator?) > > > > > > Hi Georgios, > > > > > > It seems to me that the requirement: "need of supporting both > > > single- operator and cross-operator mobility management" is a > > > deployment requirement. I understand the requirement but I do not > > > see how to "translate it" into an IP generic wording. FSo, fcusing > > > only on > > protocols (as we > > > are supposed to) how would you reformulate your requirement? Is > > talking > > > about "capability to establish security associations between > > > mobility > > entities" > > > would be acceptable? > > > > > > Br, > > > Pierrick > > > > > > > -----Message d'origine----- > > > > De=A0: dmm-bounces@ietf.org [mailto:dmm-bounces@ietf.org] De la par= t > > de > > > > karagian@cs.utwente.nl Envoy=E9=A0: vendredi 25 mai 2012 07:49 =C0= =A0: > > > > h.anthony.chan@huawei.com Cc=A0: dmm@ietf.org Objet=A0: Re: [DMM] > > > > draft requirement REQ-1: Distributed deployment (single-operator > > > > and > > > > cross-operator?) > > > > > > > > Hi Anthony, > > > > > > > > I am not sure whether it can be incorporated in REQ-4 or whether > > > > it could be considered as being an additional requirement! > > > > I am in favour of adding a new requirement that satisfies this > > issue! > > > > > > > > Best regards, > > > > Georgios > > > > > > > > ________________________________________ > > > > Van: h chan [h.anthony.chan@huawei.com] > > > > Verzonden: donderdag 24 mei 2012 19:36 > > > > Aan: Karagiannis, G. (EWI) > > > > CC: dmm@ietf.org > > > > Onderwerp: RE: [DMM] draft requirement REQ-1: Distributed > > deployment > > > > (single-operator and cross-operator?) > > > > > > > > Georgios, > > > > > > > > Do you think whether REQ-4 may be a better place to discuss. REQ-4 > > is > > > > talking about compatibility. It already includes compatibility > > > > with other (such as 3GPP) mobility protocols. We can check what > > > > else are needed there for cross-operator mobility. > > > > > > > > If you agree, we can move this cross-operator issue over the REQ-4 > > > > thread. > > > > > > > > H Anthony Chan > > > > > > > > -----Original Message----- > > > > From: karagian@cs.utwente.nl [mailto:karagian@cs.utwente.nl] > > > > Sent: Thursday, May 24, 2012 1:06 AM > > > > To: h chan > > > > Cc: dmm@ietf.org > > > > Subject: RE: [DMM] draft requirement REQ-1: Distributed deployment > > > > (single-operator and cross-operator?) > > > > > > > > Hi Anthony, Hi all, > > > > > > > > During the last DMM meeting in Paris, I have raised the issue of > > > > cross-operator mobility management support. > > > > Not sure if this issue can be satisfied by incorporating it into > > REQ-1 > > > > Distributed deployment, or if it will be needed to create an > > > > additional requirement that incorporates the need of supporting > > both > > > > single- operator and cross-operator mobility management. > > > > > > > > Best regards, > > > > Georgios > > > > > > > > ________________________________________ > > > > Van: dmm-bounces@ietf.org [dmm-bounces@ietf.org] namens h chan > > > > [h.anthony.chan@huawei.com] > > > > Verzonden: donderdag 24 mei 2012 1:20 > > > > Aan: Jouni; Peter McCann > > > > CC: dmm@ietf.org > > > > Onderwerp: Re: [DMM] draft requirement REQ-1: Distributed > > deployment > > > > > > > > An attempt to clean up the text for REQ-1 below: > > > > > > > > REQ-1: Distributed deployment > > > > IP mobility, network access and routing solutions provided by DMM > > > > SHALL enable a distributed deployment of mobility management of IP > > > > sessions so that the traffic can be routed in an optimal manner > > > > without traversing centrally deployed mobility anchors. > > > > REQ-1M (Motivation for REQ-1) > > > > The goals of this requirement are to match mobility deployment > > > > with current trend in network evolution: more cost and resource > > effective > > > > to cache and distribute contents when combining distributed > > > > anchors with caching systems (e.g., CDN); improve scalability; > > > > avoid single point of failure; mitigate threats being focused on a > > > > centrally deployed anchor, e.g., home agent and local mobility anch= or. > > > > RELEVANT problems: > > > > PS1: Non-optimal routes > > > > Routing via a centralized anchor often results in a longer route, > > and > > > > the problem is especially manifested when accessing a local or > > cache > > > > server of a Content Delivery Network (CDN). > > > > PS2: Non-optimality in Evolved Network Architecture The > > > > centralized mobility management becomes non-optimal as network > > > > architecture evolves and flattens. > > > > PS3: Low scalability of centralized route and mobility context > > > > maintenance Setting up such special routes and maintaining the > > > > mobility context including the tunnel state for each MN is more > > > > difficult to scale in a centralized design with a large number of > > MNs. > > > > Distributing the route maintenance function and the mobility > > context > > > > maintenance function among different networks can be more scalable. > > > > PS4: Single point of failure and attack Centralized anchoring may > > be > > > > more vulnerable to single point of failure and attack than a > > > > distributed system. > > > > > > > > H Anthony Chan > > > > > > > > -----Original Message----- > > > > From: Jouni [mailto:jouni.nospam@gmail.com] > > > > Sent: Saturday, May 19, 2012 4:23 AM > > > > To: Peter McCann > > > > Cc: h chan; dmm@ietf.org > > > > Subject: Re: [DMM] draft requirement REQ-1: Distributed deployment > > > > > > > > > > > > Hi > > > > > > > > On May 18, 2012, at 5:55 PM, Peter McCann wrote: > > > > > > > > > Hi, Jouni, > > > > > > > > > > jouni korhonen wrote: > > > > >> Breaking the silence.. > > > > >> > > > > >> On May 7, 2012, at 8:55 PM, h chan wrote: > > > > >> > > > > >>> REQ-1: Distributed deployment > > > > >>> IP mobility, network access and routing solutions provided by > > DMM > > > > >>> SHALL enable the functions of mobility management of IP > > sessions > > > > >>> to > > > > be > > > > >>> distributed so that the traffic is routed in an optimal manner > > > > without > > > > >>> relying on centrally deployed anchors. > > > > >> > > > > >> Few comments/questions.. > > > > >> o "SHALL enable the functions of mobility management" does that > > > > imply > > > > >> the > > > > >> DMM "solution" must always involve or extend a mobility > > protocol? > > > > IMHO > > > > >> that should not be a SHALL requirement. > > > > > > > > > > To the extent that DMM provides an "IP mobility...solution" I > > think > > > > it does > > > > > involve or extend a mobility protocol. However, I don't think > > the > > > > requirement > > > > > implies that we will necessarily extend an existing mobility > > > > protocol. > > > > > > > > Excerpt from the charter: > > > > > > > > on managing the use of care-of versus home addresses in an > > > > efficient manner for different types of communications. > > > > > > > > Just making sure the right flavor or address is used does not > > > > necessarily extend or require any mobility protocol support. > > > > > > > > >> o "centrally deployed anchors" what if the access network > > routing > > > > >> is laid out in a way that even pure IP routing would lead > > packets > > > > >> to go through a central site/edge router? Doesn't that lead to > > > > >> similar deficiencies than with mobility anchors? > > > > > > > > > > It does indeed, which is why a good network deployment will have > > > > redundant > > > > > back-up paths throughout the network. Unfortunately, it is > > > > > difficult > > > > to > > > > > provide redundancy when the path involves tunnel state at an > > anchor > > > > point. > > > > > > > > > >>> REQ-1M (Motivation for REQ-1) > > > > >>> The goals of this requirement are to match mobility deployment > > > > >>> with current trend in network evolution: > > > > >>> more cost and resource effective to cache and distribute > > contents > > > > when > > > > >>> combining distributed anchors with caching systems (e.g., > > > > >>> CDN); improve scalability; reduce signaling overhead; avoid > > > > >>> single > > point > > > > of > > > > >>> failure; mitigate threats being focused on a centrally > > > > >>> deployed anchor, e.g., home agent and local mobility anchor. > > > > >> > > > > >> Reduce signaling overhead.. is a very good goal. However, if > > > > >> any DMM solution builds on top of an existing mobility protocol > > > > >> that hardly reduces anything. Also if setting up optimal routes > > require > > > > >> establishing new tunnels, signaling is bound to increase. I > > would > > > > say > > > > >> here "does not increase the amount of present signaling" and > > > > >> the aim for solutions that would reduce it somehow. > > > > > > > > > > It should be possible to completely avoid mobility management > > > > signaling > > > > > when the MN is stationary or doesn't need a fixed address. I > > would > > > > say > > > > > that reduces signaling. > > > > > > > > From that point view ok. Extra care is then needed that one does > > not > > > > move the signaling to another layer.. take DSMIP6 (S2c) as an > > example, > > > > which avoids BU/BA exchange but then expanded the IKE signaling :) > > > > > > > > >>> RELEVANT problems: > > > > >>> PS1: Non-optimal routes > > > > >>> Routing via a centralized anchor often results in a longer > > route, > > > > >>> and the problem is especially manifested when accessing a > > > > >>> local > > or > > > > cache > > > > >>> server of a Content Delivery Network (CDN). > > > > >>> PS2: Non-optimality in Evolved Network Architecture The > > > > >>> centralized mobility management can become non-optimal as > > Network > > > > >>> architecture evolves and become more flattened. > > > > >> > > > > >> More flat is kind of superfluous.. take e.g. EPS example. You > > have, > > > > in > > > > >> an optimal case, an eNodeB connected directly to a combined > > > SGW/PGW > > > > >> from the user plane point of view. And the SGW/PGW you can > > allocate > > > > >> close to you eNodeB based on its topological location. How you > > can > > > > >> make that more flat? SGW relocation changes the situation a bit > > but > > > > still.. > > > > > > > > > > Putting an SGW/PGW (or an LGW) inside in eNB would indeed be a > > > > maximally > > > > > > > > Putting SGW/PGW into eNodeB is not too realistic for a wider are > > > > deployment. LGWs we already got out there but the mobility in that > > > > case ain't too great as far as I remember. > > > > > > > > > flat architecture. However, we would then need to deal with a > > > > > change > > > > of > > > > > anchor point during the life of a session, which is something > > that > > > > wasn't > > > > > contemplated by 3GPP. That is exactly the area that DMM should > > > > > focus > > > > on, > > > > > IMHO. > > > > > > > > With a cost of additional signaling and new tunnel state? > > > > > > > > >>> PS3: Low scalability of centralized route and mobility context > > > > >>> maintenance Setting up such special routes and maintaining the > > > > >>> mobility context for each MN is more difficult to scale in a > > > > >>> centralized design with a large number of MNs. > > > > >> > > > > >> Can I assume the mobility context involves a possible per MN > > tunnel > > > > >> state? > > > > > > > > > > Yes, I think the per-MN tunnel state is part of the mobility > > context > > > > > being talked about here. > > > > > > > > - Jouni > > > > > > > > > > > > > > > > > > -Pete > > > > > > > > > >>> Distributing the route maintenance function and the mobility > > > > context > > > > >>> maintenance function among different networks can be more > > scalable. > > > > >>> PS4: Single point of failure and attack Centralized anchoring > > may > > > > be > > > > >>> more vulnerable to single point of failure and attack than a > > > > >>> distributed system. > > > > >>> > > > > >>> (The above is drafted with contributions, inputs and > > discussions > > > > >>> from various people. Additional contributions and comments are > > > > >>> most > > > > >>> welcome.) > > > > >>> > > > > >> > > > > >> - Jouni > > > > >> > > > > >> > > > > >> > > > > >>> H Anthony Chan > > > > >>> > > > > >>> > > > > >>> _______________________________________________ > > > > >>> dmm mailing list > > > > >>> dmm@ietf.org > > > > >>> https://www.ietf.org/mailman/listinfo/dmm > > > > >> > > > > >> _______________________________________________ > > > > >> dmm mailing list > > > > >> dmm@ietf.org > > > > >> https://www.ietf.org/mailman/listinfo/dmm > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > dmm mailing list > > > > dmm@ietf.org > > > > https://www.ietf.org/mailman/listinfo/dmm > > > > _______________________________________________ > > > > dmm mailing list > > > > dmm@ietf.org > > > > https://www.ietf.org/mailman/listinfo/dmm From jouni.nospam@gmail.com Fri May 25 05:48:41 2012 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 772BA21F8646 for ; Fri, 25 May 2012 05:48:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.449 X-Spam-Level: X-Spam-Status: No, score=-3.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 6xvI2mtDTtMO for ; Fri, 25 May 2012 05:48:40 -0700 (PDT) Received: from mail-wi0-f178.google.com (mail-wi0-f178.google.com [209.85.212.178]) by ietfa.amsl.com (Postfix) with ESMTP id B601721F8647 for ; Fri, 25 May 2012 05:48:39 -0700 (PDT) Received: by wibhn6 with SMTP id hn6so712673wib.13 for ; Fri, 25 May 2012 05:48:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=niH8aoTbs4vff9uXPZdSJoGKZwQ3HclAUA5pCRcEm+A=; b=BEpGfG93A+pbeKcQnM4hCvNYL7ujZnM/5VMQ1R/cZDpNKZj9FL+QjsBIRFlHCHRhpE GOIb1Y5GrEn9C8w3HPL20du5+lfZrWcsZlp2YGewoqxV0Uw8QBrUVfZHsUOJnbJzEsra PHPARGPT4Qq/Brtd0zXD41ua/7RszraV8mZvccouwhBWRnvw0+DaPEp4FhnaLBl8eqzO x1gaBl1MpM2naz1HwpcROYYSJUK8LJ4DFGwHeXchkgPfLC4m1ciM5jWOXp4NMFqh2InM vjR72pr80YyHJbKVw3JC6Ty3xu9l8bz7cOrXjatP8QthAGuRHacrGmAa3dlJiB2HlBpN xzkg== Received: by 10.216.202.170 with SMTP id d42mr1644824weo.83.1337950118786; Fri, 25 May 2012 05:48:38 -0700 (PDT) Received: from [188.117.15.110] ([188.117.15.110]) by mx.google.com with ESMTPS id fl2sm19964510wib.2.2012.05.25.05.48.36 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 25 May 2012 05:48:38 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=iso-8859-1 From: Jouni In-Reply-To: Date: Fri, 25 May 2012 15:48:35 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <23FDCF80-B4DC-44B1-AEC8-0CA01F033DB1@gmail.com> References: , <6E31144C030982429702B11D6746B98C1DE04EBB@SZXEML505-MBS.china.huawei.com> <843DA8228A1BA74CA31FB4E111A5C462025AC262@ftrdmel0.rd.francetelecom.fr> <843DA8228A1BA74CA31FB4E111A5C462025AC2EC@ftrdmel0.rd.francetelecom.fr> To: X-Mailer: Apple Mail (2.1257) Cc: dmm@ietf.org Subject: Re: [DMM] draft requirement REQ-1: Distributed deployment (single-operator and cross-operator?) X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 May 2012 12:48:41 -0000 On May 25, 2012, at 3:21 PM, = wrote: > Hi Pierrick, >=20 > Please see in line! >=20 >=20 >> -----Original Message----- >> From: pierrick.seite@orange.com [mailto:pierrick.seite@orange.com] >> Sent: vrijdag 25 mei 2012 14:00 >> To: Karagiannis, G. (EWI); h.anthony.chan@huawei.com >> Cc: dmm@ietf.org >> Subject: RE: [DMM] draft requirement REQ-1: Distributed deployment >> (single-operator and cross-operator?) >>=20 >> Hi, >>=20 >> As an operator guy, I will not dispute a use-case dealing with = roaming :-). >> However I think that it is out of the scope of our considerations = here (I mean, >> from the IETF standpoint). IMU, the goal of DMM is not to specify a = full >> system architecture (to which statement (1) below seems to refer); = the goal >> of DMM is, in a first stage, to assess the use of legacy protocols in = a >> distributed anchoring deployment. >=20 > Georgios: Not really defining a system architecture, but more the = protocol framework! The definition of the "distribution anchoring = deployment" borders is part of that! =46rom my point of view, the protocol solutions (even what we have today = in=20 mobility area) do not prohibit cross administrative domain mobility. It is more a deployment decision loaded with non-techninal far from trivial issues. I do not like seeing this as a requirement. At least we need to make a distinction what cross administrative domain would mean: a) is it the MN moving across administrative domains or b) possibly (current) IP level anchor changing across administrative domains. - Jouni >=20 >>=20 >> Moreover, statement (2) below, is more a solution hints than a = requirement. >> Typically, (2) is about HA/LMA relocation which may be, or not, a = solution to >> meet Anthony's req#1. So, IMHO, req#1 addresses your concern. >=20 > Georgios: I think that the current description of REQ-1 is not really = addressing my concern! >=20 > Best regards, > Georgios >=20 >>=20 >> That's only my opinion; let's see what others think. >>=20 >> BR, >> Pierrick >>=20 >>> -----Message d'origine----- >>> De : karagian@cs.utwente.nl [mailto:karagian@cs.utwente.nl] Envoy=E9 = : >>> vendredi 25 mai 2012 12:28 =C0 : SEITE Pierrick RD-RESA-REN; >>> h.anthony.chan@huawei.com Cc : dmm@ietf.org Objet : RE: [DMM] draft >>> requirement REQ-1: Distributed deployment (single-operator and >>> cross-operator?) >>>=20 >>> Hi Pierrick, >>>=20 >>> The goal of such a requirement is to emphasize that the DMM >>> protocol(s) that will be designed/specified by the DMM WG should be >>> agnostic to whether users are roaming/moving into wireless coverage >>> area(s) managed by either one single operator or by more than one >> operators. >>> I think that this will have an impact on some of the requirements >>> listed already by Anthony! >>> Security association is one such requirement, other requirements are >>> related to for example the possibility of the DMM protocol(s) to = (1) >>> easily use the user profile and mobility information when users are >>> roaming away from their home operator, (2) use and support seamless, >>> real time and dynamic change of the mobility anchors that could be >>> located in different communication area(s) managed by different >>> operators. >>>=20 >>> Best regards, >>> Georgios >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>> -----Original Message----- >>>> From: pierrick.seite@orange.com [mailto:pierrick.seite@orange.com] >>>> Sent: vrijdag 25 mei 2012 9:49 >>>> To: Karagiannis, G. (EWI); h.anthony.chan@huawei.com >>>> Cc: dmm@ietf.org >>>> Subject: RE: [DMM] draft requirement REQ-1: Distributed deployment >>>> (single-operator and cross-operator?) >>>>=20 >>>> Hi Georgios, >>>>=20 >>>> It seems to me that the requirement: "need of supporting both >>>> single- operator and cross-operator mobility management" is a >>>> deployment requirement. I understand the requirement but I do not >>>> see how to "translate it" into an IP generic wording. FSo, fcusing >>>> only on >>> protocols (as we >>>> are supposed to) how would you reformulate your requirement? Is >>> talking >>>> about "capability to establish security associations between >>>> mobility >>> entities" >>>> would be acceptable? >>>>=20 >>>> Br, >>>> Pierrick >>>>=20 >>>>> -----Message d'origine----- >>>>> De : dmm-bounces@ietf.org [mailto:dmm-bounces@ietf.org] De la part >>> de >>>>> karagian@cs.utwente.nl Envoy=E9 : vendredi 25 mai 2012 07:49 =C0 : >>>>> h.anthony.chan@huawei.com Cc : dmm@ietf.org Objet : Re: [DMM] >>>>> draft requirement REQ-1: Distributed deployment (single-operator >>>>> and >>>>> cross-operator?) >>>>>=20 >>>>> Hi Anthony, >>>>>=20 >>>>> I am not sure whether it can be incorporated in REQ-4 or whether >>>>> it could be considered as being an additional requirement! >>>>> I am in favour of adding a new requirement that satisfies this >>> issue! >>>>>=20 >>>>> Best regards, >>>>> Georgios >>>>>=20 >>>>> ________________________________________ >>>>> Van: h chan [h.anthony.chan@huawei.com] >>>>> Verzonden: donderdag 24 mei 2012 19:36 >>>>> Aan: Karagiannis, G. (EWI) >>>>> CC: dmm@ietf.org >>>>> Onderwerp: RE: [DMM] draft requirement REQ-1: Distributed >>> deployment >>>>> (single-operator and cross-operator?) >>>>>=20 >>>>> Georgios, >>>>>=20 >>>>> Do you think whether REQ-4 may be a better place to discuss. REQ-4 >>> is >>>>> talking about compatibility. It already includes compatibility >>>>> with other (such as 3GPP) mobility protocols. We can check what >>>>> else are needed there for cross-operator mobility. >>>>>=20 >>>>> If you agree, we can move this cross-operator issue over the REQ-4 >>>>> thread. >>>>>=20 >>>>> H Anthony Chan >>>>>=20 >>>>> -----Original Message----- >>>>> From: karagian@cs.utwente.nl [mailto:karagian@cs.utwente.nl] >>>>> Sent: Thursday, May 24, 2012 1:06 AM >>>>> To: h chan >>>>> Cc: dmm@ietf.org >>>>> Subject: RE: [DMM] draft requirement REQ-1: Distributed deployment >>>>> (single-operator and cross-operator?) >>>>>=20 >>>>> Hi Anthony, Hi all, >>>>>=20 >>>>> During the last DMM meeting in Paris, I have raised the issue of >>>>> cross-operator mobility management support. >>>>> Not sure if this issue can be satisfied by incorporating it into >>> REQ-1 >>>>> Distributed deployment, or if it will be needed to create an >>>>> additional requirement that incorporates the need of supporting >>> both >>>>> single- operator and cross-operator mobility management. >>>>>=20 >>>>> Best regards, >>>>> Georgios >>>>>=20 >>>>> ________________________________________ >>>>> Van: dmm-bounces@ietf.org [dmm-bounces@ietf.org] namens h chan >>>>> [h.anthony.chan@huawei.com] >>>>> Verzonden: donderdag 24 mei 2012 1:20 >>>>> Aan: Jouni; Peter McCann >>>>> CC: dmm@ietf.org >>>>> Onderwerp: Re: [DMM] draft requirement REQ-1: Distributed >>> deployment >>>>>=20 >>>>> An attempt to clean up the text for REQ-1 below: >>>>>=20 >>>>> REQ-1: Distributed deployment >>>>> IP mobility, network access and routing solutions provided by DMM >>>>> SHALL enable a distributed deployment of mobility management of IP >>>>> sessions so that the traffic can be routed in an optimal manner >>>>> without traversing centrally deployed mobility anchors. >>>>> REQ-1M (Motivation for REQ-1) >>>>> The goals of this requirement are to match mobility deployment >>>>> with current trend in network evolution: more cost and resource >>> effective >>>>> to cache and distribute contents when combining distributed >>>>> anchors with caching systems (e.g., CDN); improve scalability; >>>>> avoid single point of failure; mitigate threats being focused on a >>>>> centrally deployed anchor, e.g., home agent and local mobility = anchor. >>>>> RELEVANT problems: >>>>> PS1: Non-optimal routes >>>>> Routing via a centralized anchor often results in a longer route, >>> and >>>>> the problem is especially manifested when accessing a local or >>> cache >>>>> server of a Content Delivery Network (CDN). >>>>> PS2: Non-optimality in Evolved Network Architecture The >>>>> centralized mobility management becomes non-optimal as network >>>>> architecture evolves and flattens. >>>>> PS3: Low scalability of centralized route and mobility context >>>>> maintenance Setting up such special routes and maintaining the >>>>> mobility context including the tunnel state for each MN is more >>>>> difficult to scale in a centralized design with a large number of >>> MNs. >>>>> Distributing the route maintenance function and the mobility >>> context >>>>> maintenance function among different networks can be more = scalable. >>>>> PS4: Single point of failure and attack Centralized anchoring may >>> be >>>>> more vulnerable to single point of failure and attack than a >>>>> distributed system. >>>>>=20 >>>>> H Anthony Chan >>>>>=20 >>>>> -----Original Message----- >>>>> From: Jouni [mailto:jouni.nospam@gmail.com] >>>>> Sent: Saturday, May 19, 2012 4:23 AM >>>>> To: Peter McCann >>>>> Cc: h chan; dmm@ietf.org >>>>> Subject: Re: [DMM] draft requirement REQ-1: Distributed deployment >>>>>=20 >>>>>=20 >>>>> Hi >>>>>=20 >>>>> On May 18, 2012, at 5:55 PM, Peter McCann wrote: >>>>>=20 >>>>>> Hi, Jouni, >>>>>>=20 >>>>>> jouni korhonen wrote: >>>>>>> Breaking the silence.. >>>>>>>=20 >>>>>>> On May 7, 2012, at 8:55 PM, h chan wrote: >>>>>>>=20 >>>>>>>> REQ-1: Distributed deployment >>>>>>>> IP mobility, network access and routing solutions provided by >>> DMM >>>>>>>> SHALL enable the functions of mobility management of IP >>> sessions >>>>>>>> to >>>>> be >>>>>>>> distributed so that the traffic is routed in an optimal manner >>>>> without >>>>>>>> relying on centrally deployed anchors. >>>>>>>=20 >>>>>>> Few comments/questions.. >>>>>>> o "SHALL enable the functions of mobility management" does that >>>>> imply >>>>>>> the >>>>>>> DMM "solution" must always involve or extend a mobility >>> protocol? >>>>> IMHO >>>>>>> that should not be a SHALL requirement. >>>>>>=20 >>>>>> To the extent that DMM provides an "IP mobility...solution" I >>> think >>>>> it does >>>>>> involve or extend a mobility protocol. However, I don't think >>> the >>>>> requirement >>>>>> implies that we will necessarily extend an existing mobility >>>>> protocol. >>>>>=20 >>>>> Excerpt from the charter: >>>>>=20 >>>>> on managing the use of care-of versus home addresses in an >>>>> efficient manner for different types of communications. >>>>>=20 >>>>> Just making sure the right flavor or address is used does not >>>>> necessarily extend or require any mobility protocol support. >>>>>=20 >>>>>>> o "centrally deployed anchors" what if the access network >>> routing >>>>>>> is laid out in a way that even pure IP routing would lead >>> packets >>>>>>> to go through a central site/edge router? Doesn't that lead to >>>>>>> similar deficiencies than with mobility anchors? >>>>>>=20 >>>>>> It does indeed, which is why a good network deployment will have >>>>> redundant >>>>>> back-up paths throughout the network. Unfortunately, it is >>>>>> difficult >>>>> to >>>>>> provide redundancy when the path involves tunnel state at an >>> anchor >>>>> point. >>>>>>=20 >>>>>>>> REQ-1M (Motivation for REQ-1) >>>>>>>> The goals of this requirement are to match mobility deployment >>>>>>>> with current trend in network evolution: >>>>>>>> more cost and resource effective to cache and distribute >>> contents >>>>> when >>>>>>>> combining distributed anchors with caching systems (e.g., >>>>>>>> CDN); improve scalability; reduce signaling overhead; avoid >>>>>>>> single >>> point >>>>> of >>>>>>>> failure; mitigate threats being focused on a centrally >>>>>>>> deployed anchor, e.g., home agent and local mobility anchor. >>>>>>>=20 >>>>>>> Reduce signaling overhead.. is a very good goal. However, if >>>>>>> any DMM solution builds on top of an existing mobility protocol >>>>>>> that hardly reduces anything. Also if setting up optimal routes >>> require >>>>>>> establishing new tunnels, signaling is bound to increase. I >>> would >>>>> say >>>>>>> here "does not increase the amount of present signaling" and >>>>>>> the aim for solutions that would reduce it somehow. >>>>>>=20 >>>>>> It should be possible to completely avoid mobility management >>>>> signaling >>>>>> when the MN is stationary or doesn't need a fixed address. I >>> would >>>>> say >>>>>> that reduces signaling. >>>>>=20 >>>>> =46rom that point view ok. Extra care is then needed that one does >>> not >>>>> move the signaling to another layer.. take DSMIP6 (S2c) as an >>> example, >>>>> which avoids BU/BA exchange but then expanded the IKE signaling :) >>>>>=20 >>>>>>>> RELEVANT problems: >>>>>>>> PS1: Non-optimal routes >>>>>>>> Routing via a centralized anchor often results in a longer >>> route, >>>>>>>> and the problem is especially manifested when accessing a >>>>>>>> local >>> or >>>>> cache >>>>>>>> server of a Content Delivery Network (CDN). >>>>>>>> PS2: Non-optimality in Evolved Network Architecture The >>>>>>>> centralized mobility management can become non-optimal as >>> Network >>>>>>>> architecture evolves and become more flattened. >>>>>>>=20 >>>>>>> More flat is kind of superfluous.. take e.g. EPS example. You >>> have, >>>>> in >>>>>>> an optimal case, an eNodeB connected directly to a combined >>>> SGW/PGW >>>>>>> from the user plane point of view. And the SGW/PGW you can >>> allocate >>>>>>> close to you eNodeB based on its topological location. How you >>> can >>>>>>> make that more flat? SGW relocation changes the situation a bit >>> but >>>>> still.. >>>>>>=20 >>>>>> Putting an SGW/PGW (or an LGW) inside in eNB would indeed be a >>>>> maximally >>>>>=20 >>>>> Putting SGW/PGW into eNodeB is not too realistic for a wider are >>>>> deployment. LGWs we already got out there but the mobility in that >>>>> case ain't too great as far as I remember. >>>>>=20 >>>>>> flat architecture. However, we would then need to deal with a >>>>>> change >>>>> of >>>>>> anchor point during the life of a session, which is something >>> that >>>>> wasn't >>>>>> contemplated by 3GPP. That is exactly the area that DMM should >>>>>> focus >>>>> on, >>>>>> IMHO. >>>>>=20 >>>>> With a cost of additional signaling and new tunnel state? >>>>>=20 >>>>>>>> PS3: Low scalability of centralized route and mobility context >>>>>>>> maintenance Setting up such special routes and maintaining the >>>>>>>> mobility context for each MN is more difficult to scale in a >>>>>>>> centralized design with a large number of MNs. >>>>>>>=20 >>>>>>> Can I assume the mobility context involves a possible per MN >>> tunnel >>>>>>> state? >>>>>>=20 >>>>>> Yes, I think the per-MN tunnel state is part of the mobility >>> context >>>>>> being talked about here. >>>>>=20 >>>>> - Jouni >>>>>=20 >>>>>=20 >>>>>>=20 >>>>>> -Pete >>>>>>=20 >>>>>>>> Distributing the route maintenance function and the mobility >>>>> context >>>>>>>> maintenance function among different networks can be more >>> scalable. >>>>>>>> PS4: Single point of failure and attack Centralized anchoring >>> may >>>>> be >>>>>>>> more vulnerable to single point of failure and attack than a >>>>>>>> distributed system. >>>>>>>>=20 >>>>>>>> (The above is drafted with contributions, inputs and >>> discussions >>>>>>>> from various people. Additional contributions and comments are >>>>>>>> most >>>>>>>> welcome.) >>>>>>>>=20 >>>>>>>=20 >>>>>>> - Jouni >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>> H Anthony Chan >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> _______________________________________________ >>>>>>>> dmm mailing list >>>>>>>> dmm@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/dmm >>>>>>>=20 >>>>>>> _______________________________________________ >>>>>>> dmm mailing list >>>>>>> dmm@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/dmm >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>=20 >>>>> _______________________________________________ >>>>> dmm mailing list >>>>> dmm@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/dmm >>>>> _______________________________________________ >>>>> dmm mailing list >>>>> dmm@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/dmm > _______________________________________________ > dmm mailing list > dmm@ietf.org > https://www.ietf.org/mailman/listinfo/dmm From karagian@cs.utwente.nl Fri May 25 05:57:39 2012 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 704BE21F8656 for ; Fri, 25 May 2012 05:57:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.504 X-Spam-Level: X-Spam-Status: No, score=-0.504 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545] 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 akvnfQJJms7z for ; Fri, 25 May 2012 05:57:38 -0700 (PDT) Received: from EXEDGE02.ad.utwente.nl (exedge02.ad.utwente.nl [130.89.5.49]) by ietfa.amsl.com (Postfix) with ESMTP id 7EF1621F8655 for ; Fri, 25 May 2012 05:57:37 -0700 (PDT) Received: from EXHUB01.ad.utwente.nl (130.89.4.228) by EXEDGE02.ad.utwente.nl (130.89.5.49) with Microsoft SMTP Server (TLS) id 14.1.339.1; Fri, 25 May 2012 14:57:40 +0200 Received: from EXMBX04.ad.utwente.nl ([169.254.4.13]) by EXHUB01.ad.utwente.nl ([130.89.4.228]) with mapi id 14.01.0339.001; Fri, 25 May 2012 14:57:36 +0200 From: To: Thread-Topic: [DMM] draft requirement REQ-1: Distributed deployment (single-operator and cross-operator?) Thread-Index: AQHNOXNOO5na3TLobEKwTYGTBLu3p5bZMw+QgADNa2+AAB+IcIAAJeSAgAAZDCCAAAs9kP//6siAgAAitPA= Date: Fri, 25 May 2012 12:57:33 +0000 Message-ID: References: , <6E31144C030982429702B11D6746B98C1DE04EBB@SZXEML505-MBS.china.huawei.com> <843DA8228A1BA74CA31FB4E111A5C462025AC262@ftrdmel0.rd.francetelecom.fr> <843DA8228A1BA74CA31FB4E111A5C462025AC2EC@ftrdmel0.rd.francetelecom.fr> <23FDCF80-B4DC-44B1-AEC8-0CA01F033DB1@gmail.com> In-Reply-To: <23FDCF80-B4DC-44B1-AEC8-0CA01F033DB1@gmail.com> Accept-Language: nl-NL, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.89.12.129] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: dmm@ietf.org Subject: Re: [DMM] draft requirement REQ-1: Distributed deployment (single-operator and cross-operator?) X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 May 2012 12:57:39 -0000 Hi Jouni, Answering to your question(s): >At least we need to make a > distinction what cross administrative domain would mean: a) is it the MN > moving across administrative domains or b) possibly (current) IP level an= chor > changing across administrative domains. Georgios: Please note that I was referring to both cases! Best regards, Georgios > -----Original Message----- > From: Jouni [mailto:jouni.nospam@gmail.com] > Sent: vrijdag 25 mei 2012 14:49 > To: Karagiannis, G. (EWI) > Cc: pierrick.seite@orange.com; h.anthony.chan@huawei.com; > dmm@ietf.org > Subject: Re: [DMM] draft requirement REQ-1: Distributed deployment > (single-operator and cross-operator?) >=20 >=20 > On May 25, 2012, at 3:21 PM, > wrote: >=20 > > Hi Pierrick, > > > > Please see in line! > > > > > >> -----Original Message----- > >> From: pierrick.seite@orange.com [mailto:pierrick.seite@orange.com] > >> Sent: vrijdag 25 mei 2012 14:00 > >> To: Karagiannis, G. (EWI); h.anthony.chan@huawei.com > >> Cc: dmm@ietf.org > >> Subject: RE: [DMM] draft requirement REQ-1: Distributed deployment > >> (single-operator and cross-operator?) > >> > >> Hi, > >> > >> As an operator guy, I will not dispute a use-case dealing with roaming= :-). > >> However I think that it is out of the scope of our considerations > >> here (I mean, from the IETF standpoint). IMU, the goal of DMM is not > >> to specify a full system architecture (to which statement (1) below > >> seems to refer); the goal of DMM is, in a first stage, to assess the > >> use of legacy protocols in a distributed anchoring deployment. > > > > Georgios: Not really defining a system architecture, but more the proto= col > framework! The definition of the "distribution anchoring deployment" > borders is part of that! >=20 > From my point of view, the protocol solutions (even what we have today in > mobility area) do not prohibit cross administrative domain mobility. It i= s more > a deployment decision loaded with non-techninal far from trivial issues. >=20 > I do not like seeing this as a requirement. At least we need to make a > distinction what cross administrative domain would mean: a) is it the MN > moving across administrative domains or b) possibly (current) IP level an= chor > changing across administrative domains. >=20 > - Jouni >=20 >=20 >=20 > > > >> > >> Moreover, statement (2) below, is more a solution hints than a > requirement. > >> Typically, (2) is about HA/LMA relocation which may be, or not, a > >> solution to meet Anthony's req#1. So, IMHO, req#1 addresses your > concern. > > > > Georgios: I think that the current description of REQ-1 is not really > addressing my concern! > > > > Best regards, > > Georgios > > > >> > >> That's only my opinion; let's see what others think. > >> > >> BR, > >> Pierrick > >> > >>> -----Message d'origine----- > >>> De : karagian@cs.utwente.nl [mailto:karagian@cs.utwente.nl] Envoy=E9 = : > >>> vendredi 25 mai 2012 12:28 =C0 : SEITE Pierrick RD-RESA-REN; > >>> h.anthony.chan@huawei.com Cc : dmm@ietf.org Objet : RE: [DMM] > draft > >>> requirement REQ-1: Distributed deployment (single-operator and > >>> cross-operator?) > >>> > >>> Hi Pierrick, > >>> > >>> The goal of such a requirement is to emphasize that the DMM > >>> protocol(s) that will be designed/specified by the DMM WG should be > >>> agnostic to whether users are roaming/moving into wireless coverage > >>> area(s) managed by either one single operator or by more than one > >> operators. > >>> I think that this will have an impact on some of the requirements > >>> listed already by Anthony! > >>> Security association is one such requirement, other requirements are > >>> related to for example the possibility of the DMM protocol(s) to > >>> (1) easily use the user profile and mobility information when users > >>> are roaming away from their home operator, (2) use and support > >>> seamless, real time and dynamic change of the mobility anchors that > >>> could be located in different communication area(s) managed by > >>> different operators. > >>> > >>> Best regards, > >>> Georgios > >>> > >>> > >>> > >>> > >>> > >>>> -----Original Message----- > >>>> From: pierrick.seite@orange.com [mailto:pierrick.seite@orange.com] > >>>> Sent: vrijdag 25 mei 2012 9:49 > >>>> To: Karagiannis, G. (EWI); h.anthony.chan@huawei.com > >>>> Cc: dmm@ietf.org > >>>> Subject: RE: [DMM] draft requirement REQ-1: Distributed deployment > >>>> (single-operator and cross-operator?) > >>>> > >>>> Hi Georgios, > >>>> > >>>> It seems to me that the requirement: "need of supporting both > >>>> single- operator and cross-operator mobility management" is a > >>>> deployment requirement. I understand the requirement but I do not > >>>> see how to "translate it" into an IP generic wording. FSo, fcusing > >>>> only on > >>> protocols (as we > >>>> are supposed to) how would you reformulate your requirement? Is > >>> talking > >>>> about "capability to establish security associations between > >>>> mobility > >>> entities" > >>>> would be acceptable? > >>>> > >>>> Br, > >>>> Pierrick > >>>> > >>>>> -----Message d'origine----- > >>>>> De : dmm-bounces@ietf.org [mailto:dmm-bounces@ietf.org] De la > part > >>> de > >>>>> karagian@cs.utwente.nl Envoy=E9 : vendredi 25 mai 2012 07:49 =C0 : > >>>>> h.anthony.chan@huawei.com Cc : dmm@ietf.org Objet : Re: [DMM] > >>>>> draft requirement REQ-1: Distributed deployment (single-operator > >>>>> and > >>>>> cross-operator?) > >>>>> > >>>>> Hi Anthony, > >>>>> > >>>>> I am not sure whether it can be incorporated in REQ-4 or whether > >>>>> it could be considered as being an additional requirement! > >>>>> I am in favour of adding a new requirement that satisfies this > >>> issue! > >>>>> > >>>>> Best regards, > >>>>> Georgios > >>>>> > >>>>> ________________________________________ > >>>>> Van: h chan [h.anthony.chan@huawei.com] > >>>>> Verzonden: donderdag 24 mei 2012 19:36 > >>>>> Aan: Karagiannis, G. (EWI) > >>>>> CC: dmm@ietf.org > >>>>> Onderwerp: RE: [DMM] draft requirement REQ-1: Distributed > >>> deployment > >>>>> (single-operator and cross-operator?) > >>>>> > >>>>> Georgios, > >>>>> > >>>>> Do you think whether REQ-4 may be a better place to discuss. REQ-4 > >>> is > >>>>> talking about compatibility. It already includes compatibility > >>>>> with other (such as 3GPP) mobility protocols. We can check what > >>>>> else are needed there for cross-operator mobility. > >>>>> > >>>>> If you agree, we can move this cross-operator issue over the REQ-4 > >>>>> thread. > >>>>> > >>>>> H Anthony Chan > >>>>> > >>>>> -----Original Message----- > >>>>> From: karagian@cs.utwente.nl [mailto:karagian@cs.utwente.nl] > >>>>> Sent: Thursday, May 24, 2012 1:06 AM > >>>>> To: h chan > >>>>> Cc: dmm@ietf.org > >>>>> Subject: RE: [DMM] draft requirement REQ-1: Distributed deployment > >>>>> (single-operator and cross-operator?) > >>>>> > >>>>> Hi Anthony, Hi all, > >>>>> > >>>>> During the last DMM meeting in Paris, I have raised the issue of > >>>>> cross-operator mobility management support. > >>>>> Not sure if this issue can be satisfied by incorporating it into > >>> REQ-1 > >>>>> Distributed deployment, or if it will be needed to create an > >>>>> additional requirement that incorporates the need of supporting > >>> both > >>>>> single- operator and cross-operator mobility management. > >>>>> > >>>>> Best regards, > >>>>> Georgios > >>>>> > >>>>> ________________________________________ > >>>>> Van: dmm-bounces@ietf.org [dmm-bounces@ietf.org] namens h > chan > >>>>> [h.anthony.chan@huawei.com] > >>>>> Verzonden: donderdag 24 mei 2012 1:20 > >>>>> Aan: Jouni; Peter McCann > >>>>> CC: dmm@ietf.org > >>>>> Onderwerp: Re: [DMM] draft requirement REQ-1: Distributed > >>> deployment > >>>>> > >>>>> An attempt to clean up the text for REQ-1 below: > >>>>> > >>>>> REQ-1: Distributed deployment > >>>>> IP mobility, network access and routing solutions provided by DMM > >>>>> SHALL enable a distributed deployment of mobility management of IP > >>>>> sessions so that the traffic can be routed in an optimal manner > >>>>> without traversing centrally deployed mobility anchors. > >>>>> REQ-1M (Motivation for REQ-1) > >>>>> The goals of this requirement are to match mobility deployment > >>>>> with current trend in network evolution: more cost and resource > >>> effective > >>>>> to cache and distribute contents when combining distributed > >>>>> anchors with caching systems (e.g., CDN); improve scalability; > >>>>> avoid single point of failure; mitigate threats being focused on a > >>>>> centrally deployed anchor, e.g., home agent and local mobility anch= or. > >>>>> RELEVANT problems: > >>>>> PS1: Non-optimal routes > >>>>> Routing via a centralized anchor often results in a longer route, > >>> and > >>>>> the problem is especially manifested when accessing a local or > >>> cache > >>>>> server of a Content Delivery Network (CDN). > >>>>> PS2: Non-optimality in Evolved Network Architecture The > >>>>> centralized mobility management becomes non-optimal as network > >>>>> architecture evolves and flattens. > >>>>> PS3: Low scalability of centralized route and mobility context > >>>>> maintenance Setting up such special routes and maintaining the > >>>>> mobility context including the tunnel state for each MN is more > >>>>> difficult to scale in a centralized design with a large number of > >>> MNs. > >>>>> Distributing the route maintenance function and the mobility > >>> context > >>>>> maintenance function among different networks can be more > scalable. > >>>>> PS4: Single point of failure and attack Centralized anchoring may > >>> be > >>>>> more vulnerable to single point of failure and attack than a > >>>>> distributed system. > >>>>> > >>>>> H Anthony Chan > >>>>> > >>>>> -----Original Message----- > >>>>> From: Jouni [mailto:jouni.nospam@gmail.com] > >>>>> Sent: Saturday, May 19, 2012 4:23 AM > >>>>> To: Peter McCann > >>>>> Cc: h chan; dmm@ietf.org > >>>>> Subject: Re: [DMM] draft requirement REQ-1: Distributed > deployment > >>>>> > >>>>> > >>>>> Hi > >>>>> > >>>>> On May 18, 2012, at 5:55 PM, Peter McCann wrote: > >>>>> > >>>>>> Hi, Jouni, > >>>>>> > >>>>>> jouni korhonen wrote: > >>>>>>> Breaking the silence.. > >>>>>>> > >>>>>>> On May 7, 2012, at 8:55 PM, h chan wrote: > >>>>>>> > >>>>>>>> REQ-1: Distributed deployment > >>>>>>>> IP mobility, network access and routing solutions provided by > >>> DMM > >>>>>>>> SHALL enable the functions of mobility management of IP > >>> sessions > >>>>>>>> to > >>>>> be > >>>>>>>> distributed so that the traffic is routed in an optimal manner > >>>>> without > >>>>>>>> relying on centrally deployed anchors. > >>>>>>> > >>>>>>> Few comments/questions.. > >>>>>>> o "SHALL enable the functions of mobility management" does that > >>>>> imply > >>>>>>> the > >>>>>>> DMM "solution" must always involve or extend a mobility > >>> protocol? > >>>>> IMHO > >>>>>>> that should not be a SHALL requirement. > >>>>>> > >>>>>> To the extent that DMM provides an "IP mobility...solution" I > >>> think > >>>>> it does > >>>>>> involve or extend a mobility protocol. However, I don't think > >>> the > >>>>> requirement > >>>>>> implies that we will necessarily extend an existing mobility > >>>>> protocol. > >>>>> > >>>>> Excerpt from the charter: > >>>>> > >>>>> on managing the use of care-of versus home addresses in an > >>>>> efficient manner for different types of communications. > >>>>> > >>>>> Just making sure the right flavor or address is used does not > >>>>> necessarily extend or require any mobility protocol support. > >>>>> > >>>>>>> o "centrally deployed anchors" what if the access network > >>> routing > >>>>>>> is laid out in a way that even pure IP routing would lead > >>> packets > >>>>>>> to go through a central site/edge router? Doesn't that lead to > >>>>>>> similar deficiencies than with mobility anchors? > >>>>>> > >>>>>> It does indeed, which is why a good network deployment will have > >>>>> redundant > >>>>>> back-up paths throughout the network. Unfortunately, it is > >>>>>> difficult > >>>>> to > >>>>>> provide redundancy when the path involves tunnel state at an > >>> anchor > >>>>> point. > >>>>>> > >>>>>>>> REQ-1M (Motivation for REQ-1) > >>>>>>>> The goals of this requirement are to match mobility deployment > >>>>>>>> with current trend in network evolution: > >>>>>>>> more cost and resource effective to cache and distribute > >>> contents > >>>>> when > >>>>>>>> combining distributed anchors with caching systems (e.g., CDN); > >>>>>>>> improve scalability; reduce signaling overhead; avoid single > >>> point > >>>>> of > >>>>>>>> failure; mitigate threats being focused on a centrally deployed > >>>>>>>> anchor, e.g., home agent and local mobility anchor. > >>>>>>> > >>>>>>> Reduce signaling overhead.. is a very good goal. However, if any > >>>>>>> DMM solution builds on top of an existing mobility protocol that > >>>>>>> hardly reduces anything. Also if setting up optimal routes > >>> require > >>>>>>> establishing new tunnels, signaling is bound to increase. I > >>> would > >>>>> say > >>>>>>> here "does not increase the amount of present signaling" and the > >>>>>>> aim for solutions that would reduce it somehow. > >>>>>> > >>>>>> It should be possible to completely avoid mobility management > >>>>> signaling > >>>>>> when the MN is stationary or doesn't need a fixed address. I > >>> would > >>>>> say > >>>>>> that reduces signaling. > >>>>> > >>>>> From that point view ok. Extra care is then needed that one does > >>> not > >>>>> move the signaling to another layer.. take DSMIP6 (S2c) as an > >>> example, > >>>>> which avoids BU/BA exchange but then expanded the IKE signaling :) > >>>>> > >>>>>>>> RELEVANT problems: > >>>>>>>> PS1: Non-optimal routes > >>>>>>>> Routing via a centralized anchor often results in a longer > >>> route, > >>>>>>>> and the problem is especially manifested when accessing a local > >>> or > >>>>> cache > >>>>>>>> server of a Content Delivery Network (CDN). > >>>>>>>> PS2: Non-optimality in Evolved Network Architecture The > >>>>>>>> centralized mobility management can become non-optimal as > >>> Network > >>>>>>>> architecture evolves and become more flattened. > >>>>>>> > >>>>>>> More flat is kind of superfluous.. take e.g. EPS example. You > >>> have, > >>>>> in > >>>>>>> an optimal case, an eNodeB connected directly to a combined > >>>> SGW/PGW > >>>>>>> from the user plane point of view. And the SGW/PGW you can > >>> allocate > >>>>>>> close to you eNodeB based on its topological location. How you > >>> can > >>>>>>> make that more flat? SGW relocation changes the situation a bit > >>> but > >>>>> still.. > >>>>>> > >>>>>> Putting an SGW/PGW (or an LGW) inside in eNB would indeed be a > >>>>> maximally > >>>>> > >>>>> Putting SGW/PGW into eNodeB is not too realistic for a wider are > >>>>> deployment. LGWs we already got out there but the mobility in that > >>>>> case ain't too great as far as I remember. > >>>>> > >>>>>> flat architecture. However, we would then need to deal with a > >>>>>> change > >>>>> of > >>>>>> anchor point during the life of a session, which is something > >>> that > >>>>> wasn't > >>>>>> contemplated by 3GPP. That is exactly the area that DMM should > >>>>>> focus > >>>>> on, > >>>>>> IMHO. > >>>>> > >>>>> With a cost of additional signaling and new tunnel state? > >>>>> > >>>>>>>> PS3: Low scalability of centralized route and mobility context > >>>>>>>> maintenance Setting up such special routes and maintaining the > >>>>>>>> mobility context for each MN is more difficult to scale in a > >>>>>>>> centralized design with a large number of MNs. > >>>>>>> > >>>>>>> Can I assume the mobility context involves a possible per MN > >>> tunnel > >>>>>>> state? > >>>>>> > >>>>>> Yes, I think the per-MN tunnel state is part of the mobility > >>> context > >>>>>> being talked about here. > >>>>> > >>>>> - Jouni > >>>>> > >>>>> > >>>>>> > >>>>>> -Pete > >>>>>> > >>>>>>>> Distributing the route maintenance function and the mobility > >>>>> context > >>>>>>>> maintenance function among different networks can be more > >>> scalable. > >>>>>>>> PS4: Single point of failure and attack Centralized anchoring > >>> may > >>>>> be > >>>>>>>> more vulnerable to single point of failure and attack than a > >>>>>>>> distributed system. > >>>>>>>> > >>>>>>>> (The above is drafted with contributions, inputs and > >>> discussions > >>>>>>>> from various people. Additional contributions and comments are > >>>>>>>> most > >>>>>>>> welcome.) > >>>>>>>> > >>>>>>> > >>>>>>> - Jouni > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>>> H Anthony Chan > >>>>>>>> > >>>>>>>> > >>>>>>>> _______________________________________________ > >>>>>>>> dmm mailing list > >>>>>>>> dmm@ietf.org > >>>>>>>> https://www.ietf.org/mailman/listinfo/dmm > >>>>>>> > >>>>>>> _______________________________________________ > >>>>>>> dmm mailing list > >>>>>>> dmm@ietf.org > >>>>>>> https://www.ietf.org/mailman/listinfo/dmm > >>>>>> > >>>>>> > >>>>>> > >>>>> > >>>>> _______________________________________________ > >>>>> dmm mailing list > >>>>> dmm@ietf.org > >>>>> https://www.ietf.org/mailman/listinfo/dmm > >>>>> _______________________________________________ > >>>>> dmm mailing list > >>>>> dmm@ietf.org > >>>>> https://www.ietf.org/mailman/listinfo/dmm > > _______________________________________________ > > dmm mailing list > > dmm@ietf.org > > https://www.ietf.org/mailman/listinfo/dmm From jouni.nospam@gmail.com Sat May 26 07:13:23 2012 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6883921F8568 for ; Sat, 26 May 2012 07:13:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.479 X-Spam-Level: X-Spam-Status: No, score=-3.479 tagged_above=-999 required=5 tests=[AWL=0.120, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 jT0DYKvwBZvE for ; Sat, 26 May 2012 07:13:22 -0700 (PDT) Received: from mail-wg0-f44.google.com (mail-wg0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id 6BFCF21F8570 for ; Sat, 26 May 2012 07:13:21 -0700 (PDT) Received: by wgbdr13 with SMTP id dr13so1184357wgb.13 for ; Sat, 26 May 2012 07:13:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=u6idASxtNc/4O/LRMsGpB4erfKHe5UgvG/wFzxebS34=; b=vagkch1edJlxwoUB6pL+OZXyCs8Ch2grRUgi+5c9WJUDXxrxPfEKlqzhO0SCGH5MLc 9r76sUAVzppUPPxnFaKO96nSkEiotdn6AHLqxduWY7Mhu6HC3diASrnO+5t9D454E+VL 0JkF6YqLcZCO0DisY35RHsdF2lf+Bs0xo/p9kRgWwRGSDqW10DunU9SGulrbwxVWHro7 dvIiLgEGfDmu4URO4rAO5hMIvgp8zqKIw3fDtnmKsp355WZXf65Rw+f0fqVTP4x+kNgy er/UwGccBcw8iXaDLJ8mmRv4iSQ5AvAfE8QLQgjVn6l5HCdScyz02NKLi+wI+rZz4VuX kz4Q== Received: by 10.180.95.136 with SMTP id dk8mr3840178wib.0.1338041600429; Sat, 26 May 2012 07:13:20 -0700 (PDT) Received: from [188.117.15.110] ([188.117.15.110]) by mx.google.com with ESMTPS id dg2sm8278986wib.4.2012.05.26.07.13.16 (version=TLSv1/SSLv3 cipher=OTHER); Sat, 26 May 2012 07:13:18 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=iso-8859-1 From: Jouni In-Reply-To: Date: Sat, 26 May 2012 17:13:14 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <39FF7960-3478-4B05-A4EF-9D81B8C8B17F@gmail.com> References: , <6E31144C030982429702B11D6746B98C1DE04EBB@SZXEML505-MBS.china.huawei.com> <843DA8228A1BA74CA31FB4E111A5C462025AC262@ftrdmel0.rd.francetelecom.fr> <843DA8228A1BA74CA31FB4E111A5C462025AC2EC@ftrdmel0.rd.francetelecom.fr> <23FDCF80-B4DC-44B1-AEC8-0CA01F033DB1@gmail.com> To: X-Mailer: Apple Mail (2.1257) Cc: dmm@ietf.org Subject: Re: [DMM] draft requirement REQ-1: Distributed deployment (single-operator and cross-operator?) X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 May 2012 14:13:23 -0000 Hi, On May 25, 2012, at 3:57 PM, = wrote: > Hi Jouni, >=20 > Answering to your question(s): >=20 >> At least we need to make a >> distinction what cross administrative domain would mean: a) is it the = MN >> moving across administrative domains or b) possibly (current) IP = level anchor >> changing across administrative domains. >=20 > Georgios: Please note that I was referring to both cases! Since I have difficulties believing b) would be a successful requirement without slicing it into different use cases, I would ask you to list up what use cases you think b) is needed for and what assumptions there are for IP anchoring & possible tunnel state. - Jouni >=20 > Best regards, > Georgios >=20 >=20 >=20 >=20 >> -----Original Message----- >> From: Jouni [mailto:jouni.nospam@gmail.com] >> Sent: vrijdag 25 mei 2012 14:49 >> To: Karagiannis, G. (EWI) >> Cc: pierrick.seite@orange.com; h.anthony.chan@huawei.com; >> dmm@ietf.org >> Subject: Re: [DMM] draft requirement REQ-1: Distributed deployment >> (single-operator and cross-operator?) >>=20 >>=20 >> On May 25, 2012, at 3:21 PM, >> wrote: >>=20 >>> Hi Pierrick, >>>=20 >>> Please see in line! >>>=20 >>>=20 >>>> -----Original Message----- >>>> From: pierrick.seite@orange.com [mailto:pierrick.seite@orange.com] >>>> Sent: vrijdag 25 mei 2012 14:00 >>>> To: Karagiannis, G. (EWI); h.anthony.chan@huawei.com >>>> Cc: dmm@ietf.org >>>> Subject: RE: [DMM] draft requirement REQ-1: Distributed deployment >>>> (single-operator and cross-operator?) >>>>=20 >>>> Hi, >>>>=20 >>>> As an operator guy, I will not dispute a use-case dealing with = roaming :-). >>>> However I think that it is out of the scope of our considerations >>>> here (I mean, from the IETF standpoint). IMU, the goal of DMM is = not >>>> to specify a full system architecture (to which statement (1) below >>>> seems to refer); the goal of DMM is, in a first stage, to assess = the >>>> use of legacy protocols in a distributed anchoring deployment. >>>=20 >>> Georgios: Not really defining a system architecture, but more the = protocol >> framework! The definition of the "distribution anchoring deployment" >> borders is part of that! >>=20 >> =46rom my point of view, the protocol solutions (even what we have = today in >> mobility area) do not prohibit cross administrative domain mobility. = It is more >> a deployment decision loaded with non-techninal far from trivial = issues. >>=20 >> I do not like seeing this as a requirement. At least we need to make = a >> distinction what cross administrative domain would mean: a) is it the = MN >> moving across administrative domains or b) possibly (current) IP = level anchor >> changing across administrative domains. >>=20 >> - Jouni >>=20 >>=20 >>=20 >>>=20 >>>>=20 >>>> Moreover, statement (2) below, is more a solution hints than a >> requirement. >>>> Typically, (2) is about HA/LMA relocation which may be, or not, a >>>> solution to meet Anthony's req#1. So, IMHO, req#1 addresses your >> concern. >>>=20 >>> Georgios: I think that the current description of REQ-1 is not = really >> addressing my concern! >>>=20 >>> Best regards, >>> Georgios >>>=20 >>>>=20 >>>> That's only my opinion; let's see what others think. >>>>=20 >>>> BR, >>>> Pierrick >>>>=20 >>>>> -----Message d'origine----- >>>>> De : karagian@cs.utwente.nl [mailto:karagian@cs.utwente.nl] Envoy=E9= : >>>>> vendredi 25 mai 2012 12:28 =C0 : SEITE Pierrick RD-RESA-REN; >>>>> h.anthony.chan@huawei.com Cc : dmm@ietf.org Objet : RE: [DMM] >> draft >>>>> requirement REQ-1: Distributed deployment (single-operator and >>>>> cross-operator?) >>>>>=20 >>>>> Hi Pierrick, >>>>>=20 >>>>> The goal of such a requirement is to emphasize that the DMM >>>>> protocol(s) that will be designed/specified by the DMM WG should = be >>>>> agnostic to whether users are roaming/moving into wireless = coverage >>>>> area(s) managed by either one single operator or by more than one >>>> operators. >>>>> I think that this will have an impact on some of the requirements >>>>> listed already by Anthony! >>>>> Security association is one such requirement, other requirements = are >>>>> related to for example the possibility of the DMM protocol(s) to >>>>> (1) easily use the user profile and mobility information when = users >>>>> are roaming away from their home operator, (2) use and support >>>>> seamless, real time and dynamic change of the mobility anchors = that >>>>> could be located in different communication area(s) managed by >>>>> different operators. >>>>>=20 >>>>> Best regards, >>>>> Georgios >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>> -----Original Message----- >>>>>> From: pierrick.seite@orange.com = [mailto:pierrick.seite@orange.com] >>>>>> Sent: vrijdag 25 mei 2012 9:49 >>>>>> To: Karagiannis, G. (EWI); h.anthony.chan@huawei.com >>>>>> Cc: dmm@ietf.org >>>>>> Subject: RE: [DMM] draft requirement REQ-1: Distributed = deployment >>>>>> (single-operator and cross-operator?) >>>>>>=20 >>>>>> Hi Georgios, >>>>>>=20 >>>>>> It seems to me that the requirement: "need of supporting both >>>>>> single- operator and cross-operator mobility management" is a >>>>>> deployment requirement. I understand the requirement but I do not >>>>>> see how to "translate it" into an IP generic wording. FSo, = fcusing >>>>>> only on >>>>> protocols (as we >>>>>> are supposed to) how would you reformulate your requirement? Is >>>>> talking >>>>>> about "capability to establish security associations between >>>>>> mobility >>>>> entities" >>>>>> would be acceptable? >>>>>>=20 >>>>>> Br, >>>>>> Pierrick >>>>>>=20 >>>>>>> -----Message d'origine----- >>>>>>> De : dmm-bounces@ietf.org [mailto:dmm-bounces@ietf.org] De la >> part >>>>> de >>>>>>> karagian@cs.utwente.nl Envoy=E9 : vendredi 25 mai 2012 07:49 =C0 = : >>>>>>> h.anthony.chan@huawei.com Cc : dmm@ietf.org Objet : Re: [DMM] >>>>>>> draft requirement REQ-1: Distributed deployment (single-operator >>>>>>> and >>>>>>> cross-operator?) >>>>>>>=20 >>>>>>> Hi Anthony, >>>>>>>=20 >>>>>>> I am not sure whether it can be incorporated in REQ-4 or whether >>>>>>> it could be considered as being an additional requirement! >>>>>>> I am in favour of adding a new requirement that satisfies this >>>>> issue! >>>>>>>=20 >>>>>>> Best regards, >>>>>>> Georgios >>>>>>>=20 >>>>>>> ________________________________________ >>>>>>> Van: h chan [h.anthony.chan@huawei.com] >>>>>>> Verzonden: donderdag 24 mei 2012 19:36 >>>>>>> Aan: Karagiannis, G. (EWI) >>>>>>> CC: dmm@ietf.org >>>>>>> Onderwerp: RE: [DMM] draft requirement REQ-1: Distributed >>>>> deployment >>>>>>> (single-operator and cross-operator?) >>>>>>>=20 >>>>>>> Georgios, >>>>>>>=20 >>>>>>> Do you think whether REQ-4 may be a better place to discuss. = REQ-4 >>>>> is >>>>>>> talking about compatibility. It already includes compatibility >>>>>>> with other (such as 3GPP) mobility protocols. We can check what >>>>>>> else are needed there for cross-operator mobility. >>>>>>>=20 >>>>>>> If you agree, we can move this cross-operator issue over the = REQ-4 >>>>>>> thread. >>>>>>>=20 >>>>>>> H Anthony Chan >>>>>>>=20 >>>>>>> -----Original Message----- >>>>>>> From: karagian@cs.utwente.nl [mailto:karagian@cs.utwente.nl] >>>>>>> Sent: Thursday, May 24, 2012 1:06 AM >>>>>>> To: h chan >>>>>>> Cc: dmm@ietf.org >>>>>>> Subject: RE: [DMM] draft requirement REQ-1: Distributed = deployment >>>>>>> (single-operator and cross-operator?) >>>>>>>=20 >>>>>>> Hi Anthony, Hi all, >>>>>>>=20 >>>>>>> During the last DMM meeting in Paris, I have raised the issue = of >>>>>>> cross-operator mobility management support. >>>>>>> Not sure if this issue can be satisfied by incorporating it into >>>>> REQ-1 >>>>>>> Distributed deployment, or if it will be needed to create an >>>>>>> additional requirement that incorporates the need of supporting >>>>> both >>>>>>> single- operator and cross-operator mobility management. >>>>>>>=20 >>>>>>> Best regards, >>>>>>> Georgios >>>>>>>=20 >>>>>>> ________________________________________ >>>>>>> Van: dmm-bounces@ietf.org [dmm-bounces@ietf.org] namens h >> chan >>>>>>> [h.anthony.chan@huawei.com] >>>>>>> Verzonden: donderdag 24 mei 2012 1:20 >>>>>>> Aan: Jouni; Peter McCann >>>>>>> CC: dmm@ietf.org >>>>>>> Onderwerp: Re: [DMM] draft requirement REQ-1: Distributed >>>>> deployment >>>>>>>=20 >>>>>>> An attempt to clean up the text for REQ-1 below: >>>>>>>=20 >>>>>>> REQ-1: Distributed deployment >>>>>>> IP mobility, network access and routing solutions provided by = DMM >>>>>>> SHALL enable a distributed deployment of mobility management of = IP >>>>>>> sessions so that the traffic can be routed in an optimal manner >>>>>>> without traversing centrally deployed mobility anchors. >>>>>>> REQ-1M (Motivation for REQ-1) >>>>>>> The goals of this requirement are to match mobility deployment >>>>>>> with current trend in network evolution: more cost and resource >>>>> effective >>>>>>> to cache and distribute contents when combining distributed >>>>>>> anchors with caching systems (e.g., CDN); improve scalability; >>>>>>> avoid single point of failure; mitigate threats being focused on = a >>>>>>> centrally deployed anchor, e.g., home agent and local mobility = anchor. >>>>>>> RELEVANT problems: >>>>>>> PS1: Non-optimal routes >>>>>>> Routing via a centralized anchor often results in a longer = route, >>>>> and >>>>>>> the problem is especially manifested when accessing a local or >>>>> cache >>>>>>> server of a Content Delivery Network (CDN). >>>>>>> PS2: Non-optimality in Evolved Network Architecture The >>>>>>> centralized mobility management becomes non-optimal as network >>>>>>> architecture evolves and flattens. >>>>>>> PS3: Low scalability of centralized route and mobility context >>>>>>> maintenance Setting up such special routes and maintaining the >>>>>>> mobility context including the tunnel state for each MN is more >>>>>>> difficult to scale in a centralized design with a large number = of >>>>> MNs. >>>>>>> Distributing the route maintenance function and the mobility >>>>> context >>>>>>> maintenance function among different networks can be more >> scalable. >>>>>>> PS4: Single point of failure and attack Centralized anchoring = may >>>>> be >>>>>>> more vulnerable to single point of failure and attack than a >>>>>>> distributed system. >>>>>>>=20 >>>>>>> H Anthony Chan >>>>>>>=20 >>>>>>> -----Original Message----- >>>>>>> From: Jouni [mailto:jouni.nospam@gmail.com] >>>>>>> Sent: Saturday, May 19, 2012 4:23 AM >>>>>>> To: Peter McCann >>>>>>> Cc: h chan; dmm@ietf.org >>>>>>> Subject: Re: [DMM] draft requirement REQ-1: Distributed >> deployment >>>>>>>=20 >>>>>>>=20 >>>>>>> Hi >>>>>>>=20 >>>>>>> On May 18, 2012, at 5:55 PM, Peter McCann wrote: >>>>>>>=20 >>>>>>>> Hi, Jouni, >>>>>>>>=20 >>>>>>>> jouni korhonen wrote: >>>>>>>>> Breaking the silence.. >>>>>>>>>=20 >>>>>>>>> On May 7, 2012, at 8:55 PM, h chan wrote: >>>>>>>>>=20 >>>>>>>>>> REQ-1: Distributed deployment >>>>>>>>>> IP mobility, network access and routing solutions provided by >>>>> DMM >>>>>>>>>> SHALL enable the functions of mobility management of IP >>>>> sessions >>>>>>>>>> to >>>>>>> be >>>>>>>>>> distributed so that the traffic is routed in an optimal = manner >>>>>>> without >>>>>>>>>> relying on centrally deployed anchors. >>>>>>>>>=20 >>>>>>>>> Few comments/questions.. >>>>>>>>> o "SHALL enable the functions of mobility management" does = that >>>>>>> imply >>>>>>>>> the >>>>>>>>> DMM "solution" must always involve or extend a mobility >>>>> protocol? >>>>>>> IMHO >>>>>>>>> that should not be a SHALL requirement. >>>>>>>>=20 >>>>>>>> To the extent that DMM provides an "IP mobility...solution" I >>>>> think >>>>>>> it does >>>>>>>> involve or extend a mobility protocol. However, I don't think >>>>> the >>>>>>> requirement >>>>>>>> implies that we will necessarily extend an existing mobility >>>>>>> protocol. >>>>>>>=20 >>>>>>> Excerpt from the charter: >>>>>>>=20 >>>>>>> on managing the use of care-of versus home addresses in an >>>>>>> efficient manner for different types of communications. >>>>>>>=20 >>>>>>> Just making sure the right flavor or address is used does not >>>>>>> necessarily extend or require any mobility protocol support. >>>>>>>=20 >>>>>>>>> o "centrally deployed anchors" what if the access network >>>>> routing >>>>>>>>> is laid out in a way that even pure IP routing would lead >>>>> packets >>>>>>>>> to go through a central site/edge router? Doesn't that lead = to >>>>>>>>> similar deficiencies than with mobility anchors? >>>>>>>>=20 >>>>>>>> It does indeed, which is why a good network deployment will = have >>>>>>> redundant >>>>>>>> back-up paths throughout the network. Unfortunately, it is >>>>>>>> difficult >>>>>>> to >>>>>>>> provide redundancy when the path involves tunnel state at an >>>>> anchor >>>>>>> point. >>>>>>>>=20 >>>>>>>>>> REQ-1M (Motivation for REQ-1) >>>>>>>>>> The goals of this requirement are to match mobility = deployment >>>>>>>>>> with current trend in network evolution: >>>>>>>>>> more cost and resource effective to cache and distribute >>>>> contents >>>>>>> when >>>>>>>>>> combining distributed anchors with caching systems (e.g., = CDN); >>>>>>>>>> improve scalability; reduce signaling overhead; avoid single >>>>> point >>>>>>> of >>>>>>>>>> failure; mitigate threats being focused on a centrally = deployed >>>>>>>>>> anchor, e.g., home agent and local mobility anchor. >>>>>>>>>=20 >>>>>>>>> Reduce signaling overhead.. is a very good goal. However, if = any >>>>>>>>> DMM solution builds on top of an existing mobility protocol = that >>>>>>>>> hardly reduces anything. Also if setting up optimal routes >>>>> require >>>>>>>>> establishing new tunnels, signaling is bound to increase. I >>>>> would >>>>>>> say >>>>>>>>> here "does not increase the amount of present signaling" and = the >>>>>>>>> aim for solutions that would reduce it somehow. >>>>>>>>=20 >>>>>>>> It should be possible to completely avoid mobility management >>>>>>> signaling >>>>>>>> when the MN is stationary or doesn't need a fixed address. I >>>>> would >>>>>>> say >>>>>>>> that reduces signaling. >>>>>>>=20 >>>>>>> =46rom that point view ok. Extra care is then needed that one = does >>>>> not >>>>>>> move the signaling to another layer.. take DSMIP6 (S2c) as an >>>>> example, >>>>>>> which avoids BU/BA exchange but then expanded the IKE signaling = :) >>>>>>>=20 >>>>>>>>>> RELEVANT problems: >>>>>>>>>> PS1: Non-optimal routes >>>>>>>>>> Routing via a centralized anchor often results in a longer >>>>> route, >>>>>>>>>> and the problem is especially manifested when accessing a = local >>>>> or >>>>>>> cache >>>>>>>>>> server of a Content Delivery Network (CDN). >>>>>>>>>> PS2: Non-optimality in Evolved Network Architecture The >>>>>>>>>> centralized mobility management can become non-optimal as >>>>> Network >>>>>>>>>> architecture evolves and become more flattened. >>>>>>>>>=20 >>>>>>>>> More flat is kind of superfluous.. take e.g. EPS example. You >>>>> have, >>>>>>> in >>>>>>>>> an optimal case, an eNodeB connected directly to a combined >>>>>> SGW/PGW >>>>>>>>> from the user plane point of view. And the SGW/PGW you can >>>>> allocate >>>>>>>>> close to you eNodeB based on its topological location. How you >>>>> can >>>>>>>>> make that more flat? SGW relocation changes the situation a = bit >>>>> but >>>>>>> still.. >>>>>>>>=20 >>>>>>>> Putting an SGW/PGW (or an LGW) inside in eNB would indeed be a >>>>>>> maximally >>>>>>>=20 >>>>>>> Putting SGW/PGW into eNodeB is not too realistic for a wider are >>>>>>> deployment. LGWs we already got out there but the mobility in = that >>>>>>> case ain't too great as far as I remember. >>>>>>>=20 >>>>>>>> flat architecture. However, we would then need to deal with a >>>>>>>> change >>>>>>> of >>>>>>>> anchor point during the life of a session, which is something >>>>> that >>>>>>> wasn't >>>>>>>> contemplated by 3GPP. That is exactly the area that DMM should >>>>>>>> focus >>>>>>> on, >>>>>>>> IMHO. >>>>>>>=20 >>>>>>> With a cost of additional signaling and new tunnel state? >>>>>>>=20 >>>>>>>>>> PS3: Low scalability of centralized route and mobility = context >>>>>>>>>> maintenance Setting up such special routes and maintaining = the >>>>>>>>>> mobility context for each MN is more difficult to scale in a >>>>>>>>>> centralized design with a large number of MNs. >>>>>>>>>=20 >>>>>>>>> Can I assume the mobility context involves a possible per MN >>>>> tunnel >>>>>>>>> state? >>>>>>>>=20 >>>>>>>> Yes, I think the per-MN tunnel state is part of the mobility >>>>> context >>>>>>>> being talked about here. >>>>>>>=20 >>>>>>> - Jouni >>>>>>>=20 >>>>>>>=20 >>>>>>>>=20 >>>>>>>> -Pete >>>>>>>>=20 >>>>>>>>>> Distributing the route maintenance function and the mobility >>>>>>> context >>>>>>>>>> maintenance function among different networks can be more >>>>> scalable. >>>>>>>>>> PS4: Single point of failure and attack Centralized anchoring >>>>> may >>>>>>> be >>>>>>>>>> more vulnerable to single point of failure and attack than a >>>>>>>>>> distributed system. >>>>>>>>>>=20 >>>>>>>>>> (The above is drafted with contributions, inputs and >>>>> discussions >>>>>>>>>> from various people. Additional contributions and comments = are >>>>>>>>>> most >>>>>>>>>> welcome.) >>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> - Jouni >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>> H Anthony Chan >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>> _______________________________________________ >>>>>>>>>> dmm mailing list >>>>>>>>>> dmm@ietf.org >>>>>>>>>> https://www.ietf.org/mailman/listinfo/dmm >>>>>>>>>=20 >>>>>>>>> _______________________________________________ >>>>>>>>> dmm mailing list >>>>>>>>> dmm@ietf.org >>>>>>>>> https://www.ietf.org/mailman/listinfo/dmm >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>=20 >>>>>>> _______________________________________________ >>>>>>> dmm mailing list >>>>>>> dmm@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/dmm >>>>>>> _______________________________________________ >>>>>>> dmm mailing list >>>>>>> dmm@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/dmm >>> _______________________________________________ >>> dmm mailing list >>> dmm@ietf.org >>> https://www.ietf.org/mailman/listinfo/dmm >=20 From Peter.McCann@huawei.com Sat May 26 18:47:08 2012 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6415521F84A2 for ; Sat, 26 May 2012 18:47:08 -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 cKwmF7qTz8Hj for ; Sat, 26 May 2012 18:47:07 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id D042A21F8484 for ; Sat, 26 May 2012 18:47:06 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml202-edg.china.huawei.com) ([172.18.9.243]) by dfwrg02-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AGH32889; Sat, 26 May 2012 21:47:06 -0400 (EDT) Received: from DFWEML405-HUB.china.huawei.com (10.193.5.102) by dfweml202-edg.china.huawei.com (172.18.9.108) with Microsoft SMTP Server (TLS) id 14.1.323.3; Sat, 26 May 2012 18:47:07 -0700 Received: from dfweml512-mbx.china.huawei.com ([169.254.1.156]) by dfweml405-hub.china.huawei.com ([10.193.5.102]) with mapi id 14.01.0323.003; Sat, 26 May 2012 18:47:02 -0700 From: Peter McCann To: Jouni , "" Thread-Topic: [DMM] draft requirement REQ-1: Distributed deployment (single-operator and cross-operator?) Thread-Index: AQHNO0m+iDL2gQOSkkWzWIQ0ccmMc5bc3aMw Date: Sun, 27 May 2012 01:47:00 +0000 Message-ID: <5963DDF1F751474D8DEEFDCDBEE43AE716E053A3@dfweml512-mbx.china.huawei.com> References: , <6E31144C030982429702B11D6746B98C1DE04EBB@SZXEML505-MBS.china.huawei.com> <843DA8228A1BA74CA31FB4E111A5C462025AC262@ftrdmel0.rd.francetelecom.fr> <843DA8228A1BA74CA31FB4E111A5C462025AC2EC@ftrdmel0.rd.francetelecom.fr> <23FDCF80-B4DC-44B1-AEC8-0CA01F033DB1@gmail.com> <39FF7960-3478-4B05-A4EF-9D81B8C8B17F@gmail.com> In-Reply-To: <39FF7960-3478-4B05-A4EF-9D81B8C8B17F@gmail.com> Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.99.194.198] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "dmm@ietf.org" Subject: Re: [DMM] draft requirement REQ-1: Distributed deployment (single-operator and cross-operator?) X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 May 2012 01:47:08 -0000 Jouni wrote: >=20 > Hi, >=20 > On May 25, 2012, at 3:57 PM, > wrote: >=20 >> Hi Jouni, >>=20 >> Answering to your question(s): >>=20 >>> At least we need to make a distinction what cross administrative >>> domain would mean: a) is it the MN moving across administrative >>> domains or b) possibly (current) IP level anchor changing across >>> administrative domains. >>=20 >> Georgios: Please note that I was referring to both cases! >=20 > Since I have difficulties believing b) would be a successful > requirement without slicing it into different use cases, I would ask > you to list up what use cases you think b) is needed for and what > assumptions there are for IP anchoring & possible tunnel state. Personally I think that network-based DMM should always be focusing on the intra-domain problem, because addressing the inter-domain problem requires all kinds of interworking and security relationships between domains which are hard to manage in a scalable way. Inter-domain mobility should probably always use a client-based mobility scheme, which only requires a relationship between the MN and the first network and can work over any third party network, as long as it provides Internet access. However, I think it would be in scope of DMM to consider methods of rapidly allocating/deallocating a mobility anchor in the first network for use=20 when the MN has moved out of that network into another. This would be accomplished while the MN is in the first network and wouldn't need to require involvement or cooperation from the second network. -Pete >=20 > - Jouni >=20 >=20 >=20 >=20 >=20 >>=20 >> Best regards, >> Georgios >>=20 >>=20 >>=20 >>=20 >>> -----Original Message----- >>> From: Jouni [mailto:jouni.nospam@gmail.com] >>> Sent: vrijdag 25 mei 2012 14:49 >>> To: Karagiannis, G. (EWI) >>> Cc: pierrick.seite@orange.com; h.anthony.chan@huawei.com; >>> dmm@ietf.org >>> Subject: Re: [DMM] draft requirement REQ-1: Distributed deployment >>> (single-operator and cross-operator?) >>>=20 >>>=20 >>> On May 25, 2012, at 3:21 PM, >>> wrote: >>>=20 >>>> Hi Pierrick, >>>>=20 >>>> Please see in line! >>>>=20 >>>>=20 >>>>> -----Original Message----- >>>>> From: pierrick.seite@orange.com >>>>> [mailto:pierrick.seite@orange.com] >>>>> Sent: vrijdag 25 mei 2012 14:00 >>>>> To: Karagiannis, G. (EWI); h.anthony.chan@huawei.com >>>>> Cc: dmm@ietf.org >>>>> Subject: RE: [DMM] draft requirement REQ-1: Distributed >>>>> deployment (single-operator and cross-operator?) >>>>>=20 >>>>> Hi, >>>>>=20 >>>>> As an operator guy, I will not dispute a use-case dealing with >>>>> roaming :-). However I think that it is out of the scope of our >>>>> considerations here (I mean, from the IETF standpoint). IMU, the >>>>> goal of DMM is not to specify a full system architecture (to which >>>>> statement (1) below seems to refer); the goal of DMM is, in a first >>>>> stage, to assess the use of legacy protocols in a distributed >>>>> anchoring > deployment. >>>>=20 >>>> Georgios: Not really defining a system architecture, but more the >>>> protocol >>> framework! The definition of the "distribution anchoring deployment" >>> borders is part of that! >>>=20 >>> From my point of view, the protocol solutions (even what we have today >>> in mobility area) do not prohibit cross administrative domain >>> mobility. It is more a deployment decision loaded with non-techninal >>> far from trivial issues. >>>=20 >>> I do not like seeing this as a requirement. At least we need to >>> make a distinction what cross administrative domain would mean: a) >>> is it the MN moving across administrative domains or b) possibly >>> (current) IP level anchor changing across administrative domains. >>>=20 >>> - Jouni >>>=20 >>>=20 >>>=20 >>>>=20 >>>>>=20 >>>>> Moreover, statement (2) below, is more a solution hints than a >>>>> requirement. Typically, (2) is about HA/LMA relocation which may be, >>>>> or not, a solution to meet Anthony's req#1. So, IMHO, req#1 >>>>> addresses your >>> concern. >>>>=20 >>>> Georgios: I think that the current description of REQ-1 is not really >>>> addressing my concern! >>>>=20 >>>> Best regards, >>>> Georgios >>>>=20 >>>>>=20 >>>>> That's only my opinion; let's see what others think. >>>>>=20 >>>>> BR, >>>>> Pierrick >>>>>=20 >>>>>> -----Message d'origine----- De : karagian@cs.utwente.nl >>>>>> [mailto:karagian@cs.utwente.nl] Envoy=E9 : vendredi 25 mai 2012 12:2= 8 >>>>>> =C0 : SEITE Pierrick RD-RESA-REN; h.anthony.chan@huawei.com Cc : >>>>>> dmm@ietf.org Objet : RE: [DMM] draft requirement REQ-1: Distributed >>>>>> deployment (single-operator and cross-operator?) >>>>>>=20 >>>>>> Hi Pierrick, >>>>>>=20 >>>>>> The goal of such a requirement is to emphasize that the DMM >>>>>> protocol(s) that will be designed/specified by the DMM WG should be >>>>>> agnostic to whether users are roaming/moving into wireless coverage >>>>>> area(s) managed by either one single operator or by more than one >>>>>> operators. I think that this will have an impact on some of the >>>>>> requirements listed already by Anthony! Security association is one >>>>>> such requirement, other requirements are related to for example the >>>>>> possibility of the DMM protocol(s) to (1) easily use the user >>>>>> profile and mobility information when users are roaming away from >>>>>> their home operator, (2) use and support seamless, real time and >>>>>> dynamic change of the mobility anchors that could be located in >>>>>> different communication area(s) managed by different operators. >>>>>>=20 >>>>>> Best regards, >>>>>> Georgios >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>>> -----Original Message----- >>>>>>> From: pierrick.seite@orange.com >>>>>>> [mailto:pierrick.seite@orange.com] >>>>>>> Sent: vrijdag 25 mei 2012 9:49 >>>>>>> To: Karagiannis, G. (EWI); h.anthony.chan@huawei.com >>>>>>> Cc: dmm@ietf.org >>>>>>> Subject: RE: [DMM] draft requirement REQ-1: Distributed >>>>>>> deployment (single-operator and cross-operator?) >>>>>>>=20 >>>>>>> Hi Georgios, >>>>>>>=20 >>>>>>> It seems to me that the requirement: "need of supporting both >>>>>>> single- operator and cross-operator mobility management" is a >>>>>>> deployment requirement. I understand the requirement but I do not >>>>>>> see how to "translate it" into an IP generic wording. FSo, fcusing >>>>>>> only on protocols (as we are supposed to) how would you >>>>>>> reformulate your requirement? Is talking about "capability to >>>>>>> establish security associations between mobility entities" would >>>>>>> be acceptable? >>>>>>>=20 >>>>>>> Br, >>>>>>> Pierrick >>>>>>>=20 >>>>>>>> -----Message d'origine----- >>>>>>>> De : dmm-bounces@ietf.org [mailto:dmm-bounces@ietf.org] De la >>> part >>>>>> de >>>>>>>> karagian@cs.utwente.nl Envoy=E9 : vendredi 25 mai 2012 07:49 =C0 : >>>>>>>> h.anthony.chan@huawei.com Cc : dmm@ietf.org Objet : Re: [DMM] >>>>>>>> draft requirement REQ-1: Distributed deployment (single- operator >>>>>>>> and cross-operator?) >>>>>>>>=20 >>>>>>>> Hi Anthony, >>>>>>>>=20 >>>>>>>> I am not sure whether it can be incorporated in REQ-4 or whether >>>>>>>> it could be considered as being an additional requirement! I am >>>>>>>> in favour of adding a new requirement that satisfies this issue! >>>>>>>>=20 >>>>>>>> Best regards, >>>>>>>> Georgios >>>>>>>>=20 >>>>>>>> ________________________________________ Van: h chan >>>>>>>> [h.anthony.chan@huawei.com] Verzonden: donderdag 24 mei 2012 >>>>>>>> 19:36 Aan: Karagiannis, G. (EWI) CC: dmm@ietf.org Onderwerp: RE: >>>>>>>> [DMM] draft requirement REQ-1: Distributed deployment >>>>>>>> (single-operator and cross-operator?) >>>>>>>>=20 >>>>>>>> Georgios, >>>>>>>>=20 >>>>>>>> Do you think whether REQ-4 may be a better place to discuss. >>>>>>>> REQ-4 is talking about compatibility. It already includes >>>>>>>> compatibility with other (such as 3GPP) mobility protocols. We >>>>>>>> can check what else are needed there for cross-operator mobility. >>>>>>>>=20 >>>>>>>> If you agree, we can move this cross-operator issue over the >>>>>>>> REQ-4 thread. >>>>>>>>=20 >>>>>>>> H Anthony Chan >>>>>>>>=20 >>>>>>>> -----Original Message----- >>>>>>>> From: karagian@cs.utwente.nl [mailto:karagian@cs.utwente.nl] >>>>>>>> Sent: Thursday, May 24, 2012 1:06 AM >>>>>>>> To: h chan >>>>>>>> Cc: dmm@ietf.org >>>>>>>> Subject: RE: [DMM] draft requirement REQ-1: Distributed >>>>>>>> deployment (single-operator and cross-operator?) >>>>>>>>=20 >>>>>>>> Hi Anthony, Hi all, >>>>>>>>=20 >>>>>>>> During the last DMM meeting in Paris, I have raised the issue >>>>>>>> of cross-operator mobility management support. >>>>>>>> Not sure if this issue can be satisfied by incorporating it > into >>>>>> REQ-1 >>>>>>>> Distributed deployment, or if it will be needed to create an >>>>>>>> additional requirement that incorporates the need of supporting >>>>>>>> both single- operator and cross-operator mobility management. >>>>>>>>=20 >>>>>>>> Best regards, >>>>>>>> Georgios >>>>>>>>=20 >>>>>>>> ________________________________________ Van: >>>>>>>> dmm-bounces@ietf.org [dmm-bounces@ietf.org] namens h chan >>>>>>>> [h.anthony.chan@huawei.com] Verzonden: donderdag 24 mei 2012 1:20 >>>>>>>> Aan: Jouni; Peter McCann CC: dmm@ietf.org Onderwerp: Re: [DMM] >>>>>>>> draft requirement REQ-1: Distributed deployment >>>>>>>>=20 >>>>>>>> An attempt to clean up the text for REQ-1 below: >>>>>>>>=20 >>>>>>>> REQ-1: Distributed deployment IP mobility, network access and >>>>>>>> routing solutions provided by DMM SHALL enable a distributed >>>>>>>> deployment of mobility management of IP sessions so that the >>>>>>>> traffic can be routed in an optimal manner without traversing >>>>>>>> centrally deployed mobility anchors. REQ-1M (Motivation for >>>>>>>> REQ-1) The goals of this requirement are to match mobility >>>>>>>> deployment with current trend in network evolution: more cost and >>>>>>>> resource effective to cache and distribute contents when >>>>>>>> combining distributed anchors with caching systems (e.g., CDN); >>>>>>>> improve scalability; avoid single point of failure; mitigate >>>>>>>> threats being focused on a centrally deployed anchor, e.g., home >>>>>>>> agent and local mobility anchor. RELEVANT problems: PS1: >>>>>>>> Non-optimal routes Routing via a centralized anchor often results >>>>>>>> in a longer route, and the problem is especially manifested when >>>>>>>> accessing a local or cache server of a Content Delivery Network >>>>>>>> (CDN). PS2: Non-optimality in Evolved Network Architecture The >>>>>>>> centralized mobility management becomes non-optimal as network >>>>>>>> architecture evolves and flattens. PS3: Low scalability of >>>>>>>> centralized route and mobility context maintenance Setting up >>>>>>>> such special routes and maintaining the mobility context >>>>>>>> including the tunnel state for each MN is more difficult to scale >>>>>>>> in a centralized design with a large number of MNs. Distributing >>>>>>>> the route maintenance function and the mobility context >>>>>>>> maintenance function among different networks can be more >>>>>>>> scalable. PS4: Single point of failure and attack Centralized >>>>>>>> anchoring may be more vulnerable to single point of failure and >>>>>>>> attack than a distributed system. >>>>>>>>=20 >>>>>>>> H Anthony Chan >>>>>>>>=20 >>>>>>>> -----Original Message----- From: Jouni >>>>>>>> [mailto:jouni.nospam@gmail.com] Sent: Saturday, May 19, 2012 4:23 >>>>>>>> AM To: Peter McCann Cc: h chan; dmm@ietf.org Subject: Re: [DMM] >>>>>>>> draft requirement REQ-1: Distributed deployment >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> Hi >>>>>>>>=20 >>>>>>>> On May 18, 2012, at 5:55 PM, Peter McCann wrote: >>>>>>>>=20 >>>>>>>>> Hi, Jouni, >>>>>>>>>=20 >>>>>>>>> jouni korhonen wrote: >>>>>>>>>> Breaking the silence.. >>>>>>>>>>=20 >>>>>>>>>> On May 7, 2012, at 8:55 PM, h chan wrote: >>>>>>>>>>=20 >>>>>>>>>>> REQ-1: Distributed deployment IP mobility, network access and >>>>>>>>>>> routing solutions provided by DMM SHALL enable the functions >>>>>>>>>>> of mobility management of IP sessions to be distributed so >>>>>>>>>>> that the traffic is routed in an optimal manner without >>>>>>>>>>> relying on centrally deployed anchors. >>>>>>>>>>=20 >>>>>>>>>> Few comments/questions.. o "SHALL enable the functions of >>>>>>>>>> mobility management" does that imply the DMM "solution" must >>>>>>>>>> always involve or extend a mobility >>>>>> protocol? >>>>>>>> IMHO >>>>>>>>>> that should not be a SHALL requirement. >>>>>>>>>=20 >>>>>>>>> To the extent that DMM provides an "IP mobility...solution" I >>>>>> think >>>>>>>> it does >>>>>>>>> involve or extend a mobility protocol. However, I don't >>>>>>>>> think >>>>>> the >>>>>>>> requirement >>>>>>>>> implies that we will necessarily extend an existing mobility >>>>>>>> protocol. >>>>>>>>=20 >>>>>>>> Excerpt from the charter: >>>>>>>>=20 >>>>>>>> on managing the use of care-of versus home addresses in an >>>>>>>> efficient manner for different types of communications. >>>>>>>> Just making sure the right flavor or address is used does not >>>>>>>> necessarily extend or require any mobility protocol support. >>>>>>>>=20 >>>>>>>>>> o "centrally deployed anchors" what if the access network >>>>>>>>>> routing is laid out in a way that even pure IP routing would >>>>>>>>>> lead packets to go through a central site/edge router? Doesn't >>>>>>>>>> that lead to similar deficiencies than with mobility anchors? >>>>>>>>>=20 >>>>>>>>> It does indeed, which is why a good network deployment will have >>>>>>>>> redundant back-up paths throughout the network. Unfortunately, >>>>>>>>> it is difficult to provide redundancy when the path involves >>>>>>>>> tunnel state at an >>>>>> anchor >>>>>>>> point. >>>>>>>>>=20 >>>>>>>>>>> REQ-1M (Motivation for REQ-1) The goals of this requirement >>>>>>>>>>> are to match mobility deployment with current trend in >>>>>>>>>>> network evolution: >>>>>>>>>>> more cost and resource effective to cache and distribute >>>>>> contents >>>>>>>> when >>>>>>>>>>> combining distributed anchors with caching systems (e.g., >>>>>>>>>>> CDN); improve scalability; reduce signaling overhead; avoid >>>>>>>>>>> single >>>>>> point >>>>>>>> of >>>>>>>>>>> failure; mitigate threats being focused on a centrally >>>>>>>>>>> deployed anchor, e.g., home agent and local mobility anchor. >>>>>>>>>>=20 >>>>>>>>>> Reduce signaling overhead.. is a very good goal. However, if >>>>>>>>>> any DMM solution builds on top of an existing mobility protocol >>>>>>>>>> that hardly reduces anything. Also if setting up optimal routes >>>>>>>>>> require establishing new tunnels, signaling is bound to >>>>>>>>>> increase. I >>>>>> would >>>>>>>> say >>>>>>>>>> here "does not increase the amount of present signaling" and >>>>>>>>>> the aim for solutions that would reduce it somehow. >>>>>>>>>=20 >>>>>>>>> It should be possible to completely avoid mobility management >>>>>>>>> signaling when the MN is stationary or doesn't need a fixed >>>>>>>>> address. I >>>>>> would >>>>>>>> say >>>>>>>>> that reduces signaling. >>>>>>>>=20 >>>>>>>> From that point view ok. Extra care is then needed that one > does >>>>>> not >>>>>>>> move the signaling to another layer.. take DSMIP6 (S2c) as an >>>>>>>> example, which avoids BU/BA exchange but then expanded the IKE >>>>>>>> signaling :) >>>>>>>>=20 >>>>>>>>>>> RELEVANT problems: PS1: Non-optimal routes Routing via a >>>>>>>>>>> centralized anchor often results in a longer route, and the >>>>>>>>>>> problem is especially manifested when accessing a local >>>>>> or >>>>>>>> cache >>>>>>>>>>> server of a Content Delivery Network (CDN). PS2: >>>>>>>>>>> Non-optimality in Evolved Network Architecture The centralized >>>>>>>>>>> mobility management can become non-optimal as Network >>>>>>>>>>> architecture evolves and become more flattened. >>>>>>>>>>=20 >>>>>>>>>> More flat is kind of superfluous.. take e.g. EPS example. >>>>>>>>>> You >>>>>> have, >>>>>>>> in >>>>>>>>>> an optimal case, an eNodeB connected directly to a combined >>>>>>>>>> SGW/PGW from the user plane point of view. And the SGW/PGW you >>>>>>>>>> can allocate close to you eNodeB based on its topological >>>>>>>>>> location. How > you >>>>>> can >>>>>>>>>> make that more flat? SGW relocation changes the situation a >>>>>>>>>> bit >>>>>> but >>>>>>>> still.. >>>>>>>>>=20 >>>>>>>>> Putting an SGW/PGW (or an LGW) inside in eNB would indeed be >>>>>>>>> a >>>>>>>> maximally >>>>>>>>=20 >>>>>>>> Putting SGW/PGW into eNodeB is not too realistic for a wider are >>>>>>>> deployment. LGWs we already got out there but the mobility in >>>>>>>> that case ain't too great as far as I remember. >>>>>>>>=20 >>>>>>>>> flat architecture. However, we would then need to deal with a >>>>>>>>> change of anchor point during the life of a session, which is >>>>>>>>> something >>>>>> that >>>>>>>> wasn't >>>>>>>>> contemplated by 3GPP. That is exactly the area that DMM should >>>>>>>>> focus on, IMHO. >>>>>>>>=20 >>>>>>>> With a cost of additional signaling and new tunnel state? >>>>>>>>=20 >>>>>>>>>>> PS3: Low scalability of centralized route and mobility >>>>>>>>>>> context maintenance Setting up such special routes and >>>>>>>>>>> maintaining the mobility context for each MN is more >>>>>>>>>>> difficult to scale in a centralized design with a large > number of MNs. >>>>>>>>>>=20 >>>>>>>>>> Can I assume the mobility context involves a possible per MN >>>>>>>>>> tunnel state? >>>>>>>>>=20 >>>>>>>>> Yes, I think the per-MN tunnel state is part of the mobility >>>>>>>>> context being talked about here. >>>>>>>>=20 >>>>>>>> - Jouni >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> -Pete >>>>>>>>>=20 >>>>>>>>>>> Distributing the route maintenance function and the mobility >>>>>>>>>>> context maintenance function among different networks can be >>>>>>>>>>> more scalable. PS4: Single point of failure and attack >>>>>>>>>>> Centralized > anchoring >>>>>> may >>>>>>>> be >>>>>>>>>>> more vulnerable to single point of failure and attack than >>>>>>>>>>> a distributed system. >>>>>>>>>>>=20 >>>>>>>>>>> (The above is drafted with contributions, inputs and >>>>>>>>>>> discussions from various people. Additional contributions and >>>>>>>>>>> comments are most welcome.) >>>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>> - Jouni >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>>> H Anthony Chan