From internet-drafts@ietf.org Thu Sep 6 15:30:25 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 AF5E221F867C; Thu, 6 Sep 2012 15:30:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.404 X-Spam-Level: X-Spam-Status: No, score=-102.404 tagged_above=-999 required=5 tests=[AWL=0.195, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uTd4m9RCD-mg; Thu, 6 Sep 2012 15:30:25 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F77221F86A2; Thu, 6 Sep 2012 15:30:25 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.34 Message-ID: <20120906223025.4376.69767.idtracker@ietfa.amsl.com> Date: Thu, 06 Sep 2012 15:30:25 -0700 Cc: dmm@ietf.org Subject: [DMM] I-D Action: draft-ietf-dmm-requirements-02.txt 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, 06 Sep 2012 22:30:25 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Distributed Mobility Management Working G= roup of the IETF. Title : Requirements for Distributed Mobility Management Author(s) : H Anthony Chan Filename : draft-ietf-dmm-requirements-02.txt Pages : 17 Date : 2012-09-06 Abstract: This document defines the requirements for Distributed Mobility Management (DMM) in IPv6 deployments. The traditionally hierarchical structure of cellular networks has led to deployment models which are in practice centralized. Mobility management with logically centralized mobility anchoring in current mobile networks is prone to suboptimal routing and raises scalability issues. Such centralized functions can lead to single points of failure and inevitably introduce longer delays and higher signaling loads for network operations related to mobility management. The objective is to enhance mobility management in order to meet the primary goals in network evolution, i.e., improve scalability, avoid single points of failure, enable transparent mobility support to upper layers only when needed, and so on. Distributed mobility management must be secure and compatible with existing network deployments and end hosts. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dmm-requirements There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-dmm-requirements-02 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-dmm-requirements-02 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From h.anthony.chan@huawei.com Thu Sep 6 16:04: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 307D021F8697 for ; Thu, 6 Sep 2012 16:04:47 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id saasOKkEUMO3 for ; Thu, 6 Sep 2012 16:04:46 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 698C421F8694 for ; Thu, 6 Sep 2012 16:04:36 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id AJK66949; Thu, 06 Sep 2012 23:04:35 +0000 (GMT) Received: from LHREML403-HUB.china.huawei.com (10.201.5.217) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.1.323.3; Fri, 7 Sep 2012 00:02:48 +0100 Received: from SZXEML418-HUB.china.huawei.com (10.82.67.157) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.1.323.3; Fri, 7 Sep 2012 00:03:42 +0100 Received: from SZXEML505-MBS.china.huawei.com ([169.254.2.19]) by szxeml418-hub.china.huawei.com ([10.82.67.157]) with mapi id 14.01.0323.003; Fri, 7 Sep 2012 07:03:41 +0800 From: h chan To: "dmm@ietf.org" Thread-Topic: REQ1: dmm requirement -- Distributed deployment Thread-Index: AQHNjH9HmcVwIMXpP0OWfeq31+AZPZd96xjg Date: Thu, 6 Sep 2012 23:03:41 +0000 Message-ID: <6E31144C030982429702B11D6746B98C270DD1B1@SZXEML505-MBS.china.huawei.com> References: <20120906223025.4376.69767.idtracker@ietfa.amsl.com> In-Reply-To: <20120906223025.4376.69767.idtracker@ietfa.amsl.com> Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-cr-hashedpuzzle: AChR AcxT AzCu Az5O B5Le DRfr EADj ECzk EZmd EaXo E1ac E6xf FRsA GRPK IhnH JyZ3; 1; ZABtAG0AQABpAGUAdABmAC4AbwByAGcA; Sosha1_v1; 7; {196257A2-2A0F-4EE2-91FE-FF8C3E8C758E}; aAAuAGEAbgB0AGgAbwBuAHkALgBjAGgAYQBuAEAAaAB1AGEAdwBlAGkALgBjAG8AbQA=; Thu, 06 Sep 2012 23:03:42 GMT; UgBFAFEAMQA6ACAAZABtAG0AIAByAGUAcQB1AGkAcgBlAG0AZQBuAHQAIAAtAC0AIABEAGkAcwB0AHIAaQBiAHUAdABlAGQAIABkAGUAcABsAG8AeQBtAGUAbgB0AA== x-cr-puzzleid: {196257A2-2A0F-4EE2-91FE-FF8C3E8C758E} x-originating-ip: [10.47.130.210] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: [DMM] REQ1: dmm requirement -- 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, 06 Sep 2012 23:04:47 -0000 Please check the updated REQ1 in draft-ietf-dmm-requirements-02: REQ1: Distributed deployment IP mobility, network access and routing solutions provided by DMM MUST enable distributed deployment for mobility management of IP sessions so that traffic does not need to traverse centrally deployed mobility anchors and thus can be routed in an optimal manner. Motivation: This requirement is motivated by current trends in network evolution: (a) it is cost- and resource-effective to cache and distribute content by combining distributed mobility anchors with caching systems (e.g., CDN); (b) the significantly larger number of mobile nodes and flows call for improved scalability; (c) single points of failure are avoided in a distributed system; (d) threats against centrally deployed anchors, e.g., home agent and local mobility anchor, are mitigated in a distributed system. This requirement addresses problems PS1, PS2, PS3, and PS4 in the following. PS1: Non-optimal routes Routing via a centralized anchor often results in a longer route. The problem is especially manifested when accessing a local server or servers of a Content Delivery Network (CDN). PS2: Divergence from other evolutionary trends in network architecture Centralized mobility management can become non-optimal with a flat network architecture. PS3: Low scalability of centralized route and mobility context maintenance Setting up routes through a central anchor and maintaining mobility context for each MN therein requires more resources is more difficult to scale in a centralized design, thus reducing scalability. Distributing the route maintenance function and the mobility context maintenance function among different network entities can increase scalability. PS4: Single point of failure and attack Centralized anchoring may be more vulnerable to single points of failures and attacks than a distributed system. The impact of a successful attack on a system with centralized mobility management can be far greater as well. H Anthony Chan From h.anthony.chan@huawei.com Thu Sep 6 16:10: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 8650121E804A for ; Thu, 6 Sep 2012 16:10:39 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rhGRPKIVnudN for ; Thu, 6 Sep 2012 16:10:39 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 9E1D221E8042 for ; Thu, 6 Sep 2012 16:10:38 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id AJK67194; Thu, 06 Sep 2012 23:10:36 +0000 (GMT) Received: from LHREML406-HUB.china.huawei.com (10.201.5.243) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.1.323.3; Fri, 7 Sep 2012 00:07:16 +0100 Received: from SZXEML412-HUB.china.huawei.com (10.82.67.91) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.1.323.3; Fri, 7 Sep 2012 00:08:10 +0100 Received: from SZXEML505-MBS.china.huawei.com ([169.254.2.19]) by szxeml412-hub.china.huawei.com ([10.82.67.91]) with mapi id 14.01.0323.003; Fri, 7 Sep 2012 07:08:05 +0800 From: h chan To: "dmm@ietf.org" Thread-Topic: REQ2: dmm requirement -- Transparency when needed Thread-Index: AQHNjH9HmcVwIMXpP0OWfeq31+AZPZd96xjggAAD8ZA= Date: Thu, 6 Sep 2012 23:08:04 +0000 Message-ID: <6E31144C030982429702B11D6746B98C270DD1C8@SZXEML505-MBS.china.huawei.com> References: <20120906223025.4376.69767.idtracker@ietfa.amsl.com> Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-cr-hashedpuzzle: AGRy AtCV BbMU CyUk C2h1 DIf4 FYYL F6Ga GpuC G/2K HWNA HkFl IjPS Il7m Iuhq Izro; 1; ZABtAG0AQABpAGUAdABmAC4AbwByAGcA; Sosha1_v1; 7; {08A4C77B-8870-4769-BD67-1BFC0C91B040}; aAAuAGEAbgB0AGgAbwBuAHkALgBjAGgAYQBuAEAAaAB1AGEAdwBlAGkALgBjAG8AbQA=; Thu, 06 Sep 2012 23:08:06 GMT; UgBFAFEAMgA6ACAAZABtAG0AIAByAGUAcQB1AGkAcgBlAG0AZQBuAHQAIAAtAC0AIABUAHIAYQBuAHMAcABhAHIAZQBuAGMAeQAgAHcAaABlAG4AIABuAGUAZQBkAGUAZAA= x-cr-puzzleid: {08A4C77B-8870-4769-BD67-1BFC0C91B040} x-originating-ip: [10.47.130.210] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: [DMM] REQ2: dmm requirement -- Transparency when needed 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, 06 Sep 2012 23:10:39 -0000 Please check this updated REQ1 in draft-ietf-dmm-requirements-02: REQ2: Transparency to Upper Layers when needed DMM solutions MUST provide transparent mobility support above the IP layer when needed. Such transparency is needed, for example, when, upon change of point of attachment to the Internet, an application flow cannot cope with a change in the IP address. Otherwise, support for maintaining a stable home IP address or prefix during handovers may be declined. Motivation: The motivation of this requirement is to enable more efficient use of network resources and more efficient routing by not maintaining context at the mobility anchor when there is no such need. This requirement addresses the problems PS5 as well as the other related problem O-PS1. PS5: Wasting resources to provide mobility support to nodes that do not need such support IP mobility support is not always required, and not every parameter of mobility context is always used. For example, some applications do not need a stable IP address during a handover to maintain IP session continuity. Sometimes, the entire application session runs while the terminal does not change the point of attachment. O-PS1: Mobility signaling overhead with peer-to-peer communication Wasting resources when mobility signaling (e.g., maintenance of the tunnel, keep alive, etc.) is not turned off for peer- to-peer communication. Peer-to-peer communications have particular traffic patterns that often do not benefit from mobility support from the network. Thus, the associated mobility support signaling (e.g., maintenance of the tunnel, keep alives, etc.) wastes network resources for no application gain. In such a case, it is better to enable mobility support selectively. H Anthony Chan From h.anthony.chan@huawei.com Thu Sep 6 16:10: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 7187621E804B for ; Thu, 6 Sep 2012 16:10:45 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1zykHoDjyV9a for ; Thu, 6 Sep 2012 16:10:45 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 8189321E8049 for ; Thu, 6 Sep 2012 16:10:44 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id AJK67208; Thu, 06 Sep 2012 23:10:43 +0000 (GMT) Received: from LHREML401-HUB.china.huawei.com (10.201.5.240) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.1.323.3; Fri, 7 Sep 2012 00:09:11 +0100 Received: from SZXEML414-HUB.china.huawei.com (10.82.67.153) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.1.323.3; Fri, 7 Sep 2012 00:10:05 +0100 Received: from SZXEML505-MBS.china.huawei.com ([169.254.2.19]) by SZXEML414-HUB.china.huawei.com ([10.82.67.153]) with mapi id 14.01.0323.003; Fri, 7 Sep 2012 07:09:59 +0800 From: h chan To: "dmm@ietf.org" Thread-Topic: REQ3: dmm requirement -- IPv6 deployment Thread-Index: AQHNjH9HmcVwIMXpP0OWfeq31+AZPZd96xjggAAD8ZCAAAEtUA== Date: Thu, 6 Sep 2012 23:09:58 +0000 Message-ID: <6E31144C030982429702B11D6746B98C270DD1CD@SZXEML505-MBS.china.huawei.com> References: <20120906223025.4376.69767.idtracker@ietfa.amsl.com> Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.130.210] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: [DMM] REQ3: dmm requirement -- 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: Thu, 06 Sep 2012 23:10:45 -0000 Please check this updated REQ3 in draft-ietf-dmm-requirements-02: REQ3: IPv6 deployment DMM solutions SHOULD target IPv6 as the primary deployment environment and SHOULD NOT be tailored specifically to support IPv4, in particular in situations where private IPv4 addresses and/or NATs are used. Motivation: This requirement is to be inline with the general orientation of IETF work. DMM deployment is foreseen in mid- to long-term horizon, when IPv6 is expected to be far more common than today. It is also unnecessarily complex to solve this problem for IPv4, as we will not be able to use some of the IPv6-specific features/tools. H Anthony Chan From h.anthony.chan@huawei.com Thu Sep 6 16:11:19 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 C918221F8687 for ; Thu, 6 Sep 2012 16:11:19 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kVg3DIYS7HlB for ; Thu, 6 Sep 2012 16:11:19 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id D9ABA21E8050 for ; Thu, 6 Sep 2012 16:11:18 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id AKK74296; Thu, 06 Sep 2012 23:11:16 +0000 (GMT) Received: from LHREML403-HUB.china.huawei.com (10.201.5.217) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.1.323.3; Fri, 7 Sep 2012 00:10:25 +0100 Received: from SZXEML419-HUB.china.huawei.com (10.82.67.158) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.1.323.3; Fri, 7 Sep 2012 00:11:15 +0100 Received: from SZXEML505-MBS.china.huawei.com ([169.254.2.19]) by szxeml419-hub.china.huawei.com ([10.82.67.158]) with mapi id 14.01.0323.003; Fri, 7 Sep 2012 07:11:08 +0800 From: h chan To: "dmm@ietf.org" Thread-Topic: REQ4: dmm requirement -- Existing mobility protocols Thread-Index: AQHNjH9HmcVwIMXpP0OWfeq31+AZPZd96xjggAAD8ZCAAAEtUIAAAFow Date: Thu, 6 Sep 2012 23:11:08 +0000 Message-ID: <6E31144C030982429702B11D6746B98C270DD1D8@SZXEML505-MBS.china.huawei.com> References: <20120906223025.4376.69767.idtracker@ietfa.amsl.com> Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-cr-hashedpuzzle: ArzS BjgZ CLcJ COrj CdWe Cgbg EBf6 EGsf FALd FATB FvZs F6rQ GlqG IbXc IzRj JxPh; 1; ZABtAG0AQABpAGUAdABmAC4AbwByAGcA; Sosha1_v1; 7; {944E261A-6602-4CB6-84B2-0DC9C24AD686}; aAAuAGEAbgB0AGgAbwBuAHkALgBjAGgAYQBuAEAAaAB1AGEAdwBlAGkALgBjAG8AbQA=; Thu, 06 Sep 2012 23:11:09 GMT; UgBFAFEANAA6ACAAZABtAG0AIAByAGUAcQB1AGkAcgBlAG0AZQBuAHQAIAAtAC0AIABFAHgAaQBzAHQAaQBuAGcAIABtAG8AYgBpAGwAaQB0AHkAIABwAHIAbwB0AG8AYwBvAGwAcwA= x-cr-puzzleid: {944E261A-6602-4CB6-84B2-0DC9C24AD686} x-originating-ip: [10.47.130.210] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: [DMM] REQ4: dmm requirement -- Existing mobility protocols 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, 06 Sep 2012 23:11:19 -0000 Please check this updated REQ4 in draft-ietf-dmm-requirements-02: REQ4: Existing mobility protocols A DMM solution SHOULD first consider reusing and extending IETF-standardized protocols before specifying new protocols. Motivation: Using IETF protocols is easier to deploy and to update. H Anthony Chan From h.anthony.chan@huawei.com Thu Sep 6 16:11: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 053E121F8530 for ; Thu, 6 Sep 2012 16:11:56 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rxHXVxgPHsmA for ; Thu, 6 Sep 2012 16:11:55 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 2F4FC21F852C for ; Thu, 6 Sep 2012 16:11:55 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id AKK74326; Thu, 06 Sep 2012 23:11:54 +0000 (GMT) Received: from LHREML404-HUB.china.huawei.com (10.201.5.218) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.1.323.3; Fri, 7 Sep 2012 00:11:03 +0100 Received: from SZXEML421-HUB.china.huawei.com (10.82.67.160) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.1.323.3; Fri, 7 Sep 2012 07:11:53 +0800 Received: from SZXEML505-MBS.china.huawei.com ([169.254.2.19]) by szxeml421-hub.china.huawei.com ([10.82.67.160]) with mapi id 14.01.0323.003; Fri, 7 Sep 2012 07:11:49 +0800 From: h chan To: "dmm@ietf.org" Thread-Topic: REQ4: dmm requirement -- Existing mobility protocols Thread-Index: AQHNjH9HmcVwIMXpP0OWfeq31+AZPZd96xjggAAD8ZCAAAEtUIAAAFowgAAAXuA= Date: Thu, 6 Sep 2012 23:11:48 +0000 Message-ID: <6E31144C030982429702B11D6746B98C270DD1E9@SZXEML505-MBS.china.huawei.com> References: <20120906223025.4376.69767.idtracker@ietfa.amsl.com> Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.130.210] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: Re: [DMM] REQ4: dmm requirement -- Existing mobility protocols 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, 06 Sep 2012 23:11:56 -0000 Please check this updated REQ5 in draft-ietf-dmm-requirements-02: REQ4: Existing mobility protocols A DMM solution SHOULD first consider reusing and extending IETF-standardized protocols before specifying new protocols. Motivation: Using IETF protocols is easier to deploy and to update. H Anthony Chan From h.anthony.chan@huawei.com Thu Sep 6 16:14: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 9773B21E8042 for ; Thu, 6 Sep 2012 16:14:33 -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=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JMxC2PgcyreL for ; Thu, 6 Sep 2012 16:14:33 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id C132D21F85C7 for ; Thu, 6 Sep 2012 16:14:32 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id AJK67346; Thu, 06 Sep 2012 23:14:32 +0000 (GMT) Received: from LHREML402-HUB.china.huawei.com (10.201.5.241) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.1.323.3; Fri, 7 Sep 2012 00:12:23 +0100 Received: from SZXEML417-HUB.china.huawei.com (10.82.67.156) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.1.323.3; Fri, 7 Sep 2012 00:13:17 +0100 Received: from SZXEML505-MBS.china.huawei.com ([169.254.2.19]) by szxeml417-hub.china.huawei.com ([10.82.67.156]) with mapi id 14.01.0323.003; Fri, 7 Sep 2012 07:13:14 +0800 From: h chan To: "dmm@ietf.org" Thread-Topic: REQ5: dmm requirement -- Compatibility Thread-Index: AQHNjH9HmcVwIMXpP0OWfeq31+AZPZd96xjggAAD8ZCAAAEtUIAAAFowgAAAXuCAAAAeUA== Date: Thu, 6 Sep 2012 23:13:14 +0000 Message-ID: <6E31144C030982429702B11D6746B98C270DD20A@SZXEML505-MBS.china.huawei.com> References: <20120906223025.4376.69767.idtracker@ietfa.amsl.com> Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.130.210] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: [DMM] REQ5: dmm requirement -- 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, 06 Sep 2012 23:14:33 -0000 Please check this updated REQ5 in draft-ietf-dmm-requirements-02: REQ5: Compatibility The DMM solution MUST be able to co-exist with existing network deployments and end hosts. For example, depending on the environment in which DMM is deployed, DMM solutions may need to be compatible with other deployed mobility protocols or may need to interoperate with a network or mobile hosts/ routers that do not support DMM protocols. Furthermore, a DMM solution SHOULD work across different networks, possibly operated as separate administrative domains, when allowed by the trust relationship between them. Motivation: The motivations of this requirement are (1) to preserve backwards compatibility so that existing networks and hosts are not affected and continue to function as usual, and (2) enable inter-domain operation if desired. This requirement addresses the following related problem O-PS2. O-PS2: Complicated deployment with too many MIP variants and extensions Deployment is complicated with many variants and extensions of MIP. When introducing new functions which may add to the complexity, existing solutions are more vulnerable to break. H Anthony Chan From h.anthony.chan@huawei.com Thu Sep 6 16:14:48 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 B4C8921F852E for ; Thu, 6 Sep 2012 16:14:48 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yx2fc--7Zb5Z for ; Thu, 6 Sep 2012 16:14:48 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id C7E7721E8050 for ; Thu, 6 Sep 2012 16:14:47 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id AKK74445; Thu, 06 Sep 2012 23:14:46 +0000 (GMT) Received: from LHREML405-HUB.china.huawei.com (10.201.5.242) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.1.323.3; Fri, 7 Sep 2012 00:13:56 +0100 Received: from SZXEML415-HUB.china.huawei.com (10.82.67.154) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.1.323.3; Fri, 7 Sep 2012 00:14:45 +0100 Received: from SZXEML505-MBS.china.huawei.com ([169.254.2.19]) by szxeml415-hub.china.huawei.com ([10.82.67.154]) with mapi id 14.01.0323.003; Fri, 7 Sep 2012 07:14:41 +0800 From: h chan To: "dmm@ietf.org" Thread-Topic: REQ6: dmm requirement -- Security Thread-Index: AQHNjH9HmcVwIMXpP0OWfeq31+AZPZd96xjggAAD8ZCAAAEtUIAAAFowgAAAXuCAAAAeUIAAAGIw Date: Thu, 6 Sep 2012 23:14:41 +0000 Message-ID: <6E31144C030982429702B11D6746B98C270DD20F@SZXEML505-MBS.china.huawei.com> References: <20120906223025.4376.69767.idtracker@ietfa.amsl.com> Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.130.210] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: [DMM] REQ6: dmm requirement -- Security 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, 06 Sep 2012 23:14:48 -0000 Please check this updated REQ6 in draft-ietf-dmm-requirements-02: REQ6: Security considerations DMM protocol solutions MUST consider security aspects, including confidentiality and integrity. Examples of aspects to be considered are authentication and authorization mechanisms that allow a legitimate mobile host/router to use the mobility support provided by the DMM solution; signaling message protection in terms of authentication, encryption, etc.; data integrity and confidentiality; opt-in or opt-out data confidentiality to signaling messages depending on network environments or user requirements. Motivation: 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. Various attacks such as impersonation, denial of service, man- in-the-middle attacks, and so on, can be mounted against a DMM service and need to be protected against. Signaling messages can be subject to various attacks since they carry critical context information about a mobile node/ router. For instance, a malicious node can forge a number of signaling messages thus redirecting traffic from its legitimate path. Consequently, the specific node is under a denial of service attack, whereas other nodes do not receive their traffic. As signaling messages may travel over the Internet, end-to-end security could be required. H Anthony Chan From h.anthony.chan@huawei.com Thu Sep 6 16:18: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 2FECF21F865B for ; Thu, 6 Sep 2012 16:18:20 -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=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BjncAbG8qzKP for ; Thu, 6 Sep 2012 16:18:19 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 3BA4E21F8652 for ; Thu, 6 Sep 2012 16:18:19 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id AJK67485; Thu, 06 Sep 2012 23:18:18 +0000 (GMT) Received: from LHREML405-HUB.china.huawei.com (10.201.5.242) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.1.323.3; Fri, 7 Sep 2012 00:15:01 +0100 Received: from SZXEML416-HUB.china.huawei.com (10.82.67.155) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.1.323.3; Fri, 7 Sep 2012 00:15:55 +0100 Received: from SZXEML505-MBS.china.huawei.com ([169.254.2.19]) by szxeml416-hub.china.huawei.com ([10.82.67.155]) with mapi id 14.01.0323.003; Fri, 7 Sep 2012 07:15:50 +0800 From: h chan To: "dmm@ietf.org" Thread-Topic: [DMM] I-D Action: draft-ietf-dmm-requirements-02.txt Thread-Index: AQHNjH9HmcVwIMXpP0OWfeq31+AZPZd97S/w Date: Thu, 6 Sep 2012 23:15:50 +0000 Message-ID: <6E31144C030982429702B11D6746B98C270DD223@SZXEML505-MBS.china.huawei.com> References: <20120906223025.4376.69767.idtracker@ietfa.amsl.com> In-Reply-To: <20120906223025.4376.69767.idtracker@ietfa.amsl.com> Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.130.210] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: Re: [DMM] I-D Action: draft-ietf-dmm-requirements-02.txt 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, 06 Sep 2012 23:18:20 -0000 This draft has been updated to solve the issues raised and has included numerous suggested texts from Kostas.=20 The updated requirements are also being sent out one by one in separate ema= ils.=20 Please check them, and comments are welcome.=20 H Anthony Chan -----Original Message----- From: dmm-bounces@ietf.org [mailto:dmm-bounces@ietf.org] On Behalf Of inter= net-drafts@ietf.org Sent: Thursday, September 06, 2012 5:30 PM To: i-d-announce@ietf.org Cc: dmm@ietf.org Subject: [DMM] I-D Action: draft-ietf-dmm-requirements-02.txt A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Distributed Mobility Management Working G= roup of the IETF. Title : Requirements for Distributed Mobility Management Author(s) : H Anthony Chan Filename : draft-ietf-dmm-requirements-02.txt Pages : 17 Date : 2012-09-06 Abstract: This document defines the requirements for Distributed Mobility Management (DMM) in IPv6 deployments. The traditionally hierarchical structure of cellular networks has led to deployment models which are in practice centralized. Mobility management with logically centralized mobility anchoring in current mobile networks is prone to suboptimal routing and raises scalability issues. Such centralized functions can lead to single points of failure and inevitably introduce longer delays and higher signaling loads for network operations related to mobility management. The objective is to enhance mobility management in order to meet the primary goals in network evolution, i.e., improve scalability, avoid single points of failure, enable transparent mobility support to upper layers only when needed, and so on. Distributed mobility management must be secure and compatible with existing network deployments and end hosts. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dmm-requirements There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-dmm-requirements-02 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-dmm-requirements-02 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ dmm mailing list dmm@ietf.org https://www.ietf.org/mailman/listinfo/dmm From jouni.nospam@gmail.com Wed Sep 19 00:57: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 925F221F8459 for ; Wed, 19 Sep 2012 00:57:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.542 X-Spam-Level: X-Spam-Status: No, score=-3.542 tagged_above=-999 required=5 tests=[AWL=0.057, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ILhw7mybUyiQ for ; Wed, 19 Sep 2012 00:57:55 -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 2B1D721F8456 for ; Wed, 19 Sep 2012 00:57:54 -0700 (PDT) Received: by wgbdr13 with SMTP id dr13so399441wgb.13 for ; Wed, 19 Sep 2012 00:57:54 -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=batBcUaV9hhekvuIQQo3AZuLdI7vmM9WFrdJL8kl+FE=; b=ZMJ+3UooE+zqWgluW3MZrGTTFa8IKW8RodjzAbuNTP+sD/QBDrPvoJk7JHnArH8p1W tx6zK4+06KBnQQwY7ZBjA/x+78skXjrVd/ezVaLLb41Sc0jTclZTa5YsbpPgZYPthZ8b 11xwldp/ecNftAbNZKRASAc94e4RUuwMj5/bk8X7Km1kIRpehBDUgDQK7HYtJi9WZbyV e5GpzHf6X/mV1j1ROxoDXYgxD6rVc1Ut2IB2Gv0kV5eCAQqqxKGe8JL+dBUPwZrRM1Q1 ocIC+ZRDcrHo87jrgrBB2z5fuPhkKXvercao1RU09kv8YQloHBQOfAhdHkG/LZj7V/1L oFSQ== Received: by 10.180.8.40 with SMTP id o8mr5110889wia.9.1348041474148; Wed, 19 Sep 2012 00:57:54 -0700 (PDT) Received: from ?IPv6:2001:1bc8:101:f101:226:bbff:fe18:6e9c? ([2001:1bc8:101:f101:226:bbff:fe18:6e9c]) by mx.google.com with ESMTPS id hv8sm31260414wib.0.2012.09.19.00.57.45 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 19 Sep 2012 00:57:53 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=windows-1252 From: jouni korhonen In-Reply-To: Date: Wed, 19 Sep 2012 10:57:42 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: dmm@ietf.org, h chan , Juan Carlos Zuniga X-Mailer: Apple Mail (2.1084) Cc: dmm-chairs@tools.ietf.org Subject: Re: [DMM] Comments on DMM Gap Analysis. 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, 19 Sep 2012 07:57:56 -0000 Folks, It has been rather silent on the list recently. Regarding the = "explosion" of possible=20 technologies in the GAP analysis, we discussed (chairs) that it is = better to scope the area "a bit". The charter today has the assumption that we build on top = of existing _IP_ _Mobility_ protocols (and bunch of IETF defined examples follow). So, to = tighten the scope, the Gap Analysis should leave all routing, session (SIP, ..), = transport (MPTCP, SCTP, DCCP, ..), locator/identifier split (HIP, Lisp, ..), naming (DNS = tricks, ..) etc based solutions out. Coarse but should help us to make progress. We = could discuss whether=20 transport layer solution like SCTP fit in but I do not see them as = end-2-end solutions being deployable in Internet at the moment. Let us stick with technologies out there that have/had a place in sun: = few MIP variants, MOBIKE, stuff in 3GPP(2) (oops.. but I think this deserves to be = evaluated since they are somewhat popular), and what applications do (reconnecting..). This = analysis should be down to earth practical and realistic on what is already out there to = play with. - Jouni & Julien On Jul 27, 2012, at 3:53 PM, Jong-Hyouk Lee wrote: > Dear Anthony and Juan. >=20 > I enjoyed the both gap analysis documents = (draft-chan-dmm-framework-gap-analysis-02 and = draft-zuniga-dmm-gap-analysis-01). Here I give some comments that should = be used directly in the gap analysis documents if you guys like. >=20 > Kindly consider the followings during the gap analysis discussion = (since I will not be attending the IETF meeting this time).=20 >=20 > 1. Comment on address (resource) management in a DMM environment. > 2. Comment on a deployment of a client-based mobility solution (i.e., = MIPv6) in a DMM environment. > 3. Commnet on neighbor mobility anchors' information in a DMM = environment. > 4. Commnet on an establishment of security associations in a DMM = environment. >=20 > =3D=3D=3D 1. Comment on address (resource) management in a DMM = environment. =3D=3D=3D > When existing IP mobility support protocols (e.g., MIPv6 and PMIPv6) = are considered to be deployed in a DMM environment, a mobile node (MN) = is allowed to configure a new address while keeping its previous = address(es). It introduces the following differences with the address = (resource) management of the existing ones: >=20 > MN=92s address configured at the interface with a DMM environment: n =3D= (IP address at the current access network + previously configured IP = address(es) with ongoing sessions) > MN=92s address configured at the interface without a DMM environment: = 1 =3D (care-of address in MIPv6 or MN=92s home address in PMIPv6) >=20 > This leads a couple of considerations we didn=92t have with the = existing IP mobility support protocols. For instance, >=20 > 1) MN=92s address management: use of a newly configured address at the = current access network for new communication sessions while a proper = address selection for previously established ongoing communication = sessions. >=20 > 2) Additional treatment for ingress filtering: Ingress filtering is = widely used against source address spoofing. The source addresses = (especially, the network prefix part) of incoming packets are strictly = checked to make sure that those packets are actually from the network = that they claim to be from. As the MN are allowed to send data packets = with the previously configured address(es) at the new access network, = those data packets would be filtered at the ingress filtering place = because the source address of those data packets is not belonging to the = new access network. Accordingly, an additional treatment for ingress = filtering is required. >=20 > 3) MN=92s address increase at the MN=92s interface: Recall the number = of MN=92s address configured at an interface is n. Then, n is increased, = as the MN changes its point of attachment while keeping its ongoing = communication sessions. It brings the question: =93How many addresses = are currently possible to be configured at an interface?=94 >=20 > 4) Routing entry increase at the serving mobility anchor: Let the = serving mobility anchor is the mobility anchor serves the MN. Traffic = associated to the MN travels via the serving mobility anchor. The = increase of the addresses associated to the MN, n, is not only = concerning to the MN, but also concerning the serving mobility anchor as = it contributes the increase of routing entries for the MN. >=20 > =3D=3D=3D 2. Comment on a deployment of a client-based mobility = solution (i.e., MIPv6) in a DMM environment. =3D=3D=3D=20 > When a client-based mobility solution (i.e., MIPv6) is consiered to be = deployed in a DMM environment, an MN is involved in mobility signaling = such as Binding Update and Acknowledgement messages. This is the big = difference with the network-based mobility solution (i.e., PMIPv6). As = the MN send signaling to inform its movement to its mobility anchor, the = client-based mobility solution allows the MN to supply client-centric = decision for mobility management. >=20 > Suppose that the origin mobility anchor is the mobility anchor where = the MN has configured its IP address and established ongoing = communication sessions with the IP address. The number of origin = mobility anchors are n - 1. Recall that the serving mobility anchor is = the mobility anchor where the MN is being served by. Then, the MN=92s = involvement in mobility signaling brings us the questions: =93Should we = let the MN send mobilty signaling to its all mobility anchors?=94 or = =93Would it make sense that the MN only sends mobility signaling to its = serving mobility anchor?=94 Depending on the choice, we will have = different results: >=20 > 1) =93MN sends mobility signaling to its all mobility anchors=94 = causes:=20 > 1.1 increased mobility signaling load, e.g., signaling * (n - 1).=20 > 1.2 bidirectional tunnels are established between the MN and its = mobility anchors. > 1.3 tunneling overhead over the air is present. > 1.4 but the tunnels are terminated at the MN so that the MN has = control over the tunnels. >=20 > 2) =93MN sends mobility signaling only to its serving mobility anchor=94= causes: > 2.1 reduced mobility signaling load, e.g., signaling * 1. > 2.2 bidirectional tunnels are established between the serving mobility = anchors and origin mobility anchors. > 2.3 tunneling overhead over the air can be avoided. > 2.4 but the MN does not have control over the tunnels so it might = affect to NEtwork MObility (NEMO) as the MN (i.e., MR in NEMO) loses the = tunneling control. >=20 > =3D=3D=3D 3. Neighbor mobility anchors=92 information in a DMM = environment. =3D=3D=3D > In the client-based mobility solution such as MIPv6, the network = topology information does not required to be known to the mobility = anchor, i.e., home agent (HA), since the HA is informed the current = location of the MN. As the HA knows the current location of the MN, it = is able to tunnel packets associated to the MN. In the network-based = mobility solution such as PMIPv6, the similar things happen, i.e., the = tunnel between the local mobility anchor (LMA) and the mobile access = gateway (MAG) is established for a given MN. >=20 > However, as mobility anchors are distributed and bidirectional tunnels = (for a given MN) between the distributed mobility anchors are required, = the neighbor mobility anchors=92 information should be provided to the = MN or the mobility anchor for the establishment of the directional = tunnels or the update of the MN=92s current location.=20 >=20 > Decoupling the data plane and control plane while keeping a = centralized node maintaining the mobility context including neighbor = mobility anchors=92 information (e.g., identification, IP address, etc) = in a DMM environment is one of possible solutions. >=20 > =3D=3D=3D 4. Comment on an establishment of security associations in a = DMM environment. =3D=3D=3D > For each IP mobility support protocol, different security associations = (SAs) are required for providing secure mobility services to MNs as = follows: >=20 > 1) MIPv6 > 1.1 SA between MN and HA. > 1.2 SA between MN and serving access router (AR) providing wireless = link to the MN. >=20 > 2) Fast Handover MIPv6 (FMIPv6) > 2.1 SA between MN and HA. > 2.2 SA between MN and serving AR. > 2.3 SA between previous and new ARs. >=20 > 3) PMIPv6 > 3.1 SA between MN and serving MAG. > 3.2 SA between serving MAG and LMA. >=20 > 4) Fast Handover PMIPv6 (FPMIPv6) > 4.1 SA between MN and serving MAG. > 4.2 SA between serving MAG and LMA. > 4.3 SA between previous and new MAGs. >=20 > Note that the above ones do not consider the cases of SA with a = security-backend server (e.g., AAA server) and with a correspondent node = (CN). >=20 > However, depending on DMM solutions, SAs are configured that are = different from those of the existing IP mobility support protocols. For = instance, >=20 > 1) the case of =93MN sends mobility signaling to its all mobility = anchors=94 (client-based mobility solution) > 1.1 SA between MN and serving mobility anchor providing wireless link = to the MN. > 1.2 SA between MN and origin mobility anchors, i.e., (n - 1) SAs = required with MN and origin mobility anchors. >=20 > 2) the case of =93MN sends mobility signaling only to its serving = mobility anchor=94 (client-based mobility solution) > 2.1 SA between MN and serving mobility anchor. > 2.2 SA between serving mobility anchor and origin mobility anchors, = i.e., (n - 1) SAs required with serving mobility anchor and origin = mobility anchors. >=20 > 3) the case of =93serving mobility anchor sends signaling on behalf of = the MN to origin mobility anchors=94 (network-based mobility solution) > 3.1 SA between MN and serving mobility anchor. > 3.2 SA between serving mobility anchor and origin mobility anchors, = i.e., (n - 1) SAs required with serving mobility anchor and origin = mobility anchors. >=20 > Note that as like before SAs with a security-backend server (e.g., AAA = server) and with a CN are not presented. >=20 > As shown above, DMM solutions (that relies on bidirectional tunnelings = for packet forwarding between MN and mobility anchors or between just = mobility anchors) might bring the key management issues to establish = such SAs. >=20 > Since it's a holiday season, I cannot fully address all of them in my = mind, but kindly consider these ones. >=20 > Cheers. >=20 > --=20 > RSM Department, TELECOM Bretagne, France > Jong-Hyouk Lee, living somewhere between /dev/null and /dev/random >=20 > #email: jonghyouk (at) gmail (dot) com > #webpage: http://sites.google.com/site/hurryon/ >=20 > _______________________________________________ > dmm mailing list > dmm@ietf.org > https://www.ietf.org/mailman/listinfo/dmm From karagian@cs.utwente.nl Wed Sep 19 04:11: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 616CA21F8754 for ; Wed, 19 Sep 2012 04:11:08 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AC5fx3GSI6Yf for ; Wed, 19 Sep 2012 04:11:07 -0700 (PDT) Received: from EXEDGE01.ad.utwente.nl (exedge01.ad.utwente.nl [130.89.5.48]) by ietfa.amsl.com (Postfix) with ESMTP id 663B421F86FC for ; Wed, 19 Sep 2012 04:11:05 -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; Wed, 19 Sep 2012 13:11:10 +0200 Received: from EXMBX04.ad.utwente.nl ([169.254.4.4]) by EXHUB02.ad.utwente.nl ([130.89.4.229]) with mapi id 14.01.0339.001; Wed, 19 Sep 2012 13:11:04 +0200 From: To: , , , Thread-Topic: [DMM] Comments on DMM Gap Analysis. Thread-Index: AQHNa/boI0rituCWdkGdrm+e/9iWcJeRf28AgABUdWA= Date: Wed, 19 Sep 2012 11:11:03 +0000 Message-ID: References: In-Reply-To: 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-chairs@tools.ietf.org Subject: Re: [DMM] Comments on DMM Gap Analysis. 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, 19 Sep 2012 11:11:08 -0000 Hi Jouni, Hi all,=20 After discussing this issue with Carlos Jes=FAs Bernardos and Juan Carlos Z= uniga, we concluded that the following set of possible technologies could b= e included in the Gap analysis draft: =3D> Shim6: Level 3 Multihoming Shim Protocol for IPv6=20 http://www.rfc-editor.org/rfc/rfc5533.txt =3D> LISP Mobile Node http://www.ietf.org/id/draft-meyer-lisp-mn-07.txt Locator/ID Separation Protocol (LISP)=20 http://www.ietf.org/id/draft-ietf-lisp-23.txt =3D> Mobile IPv6 Fast Handovers http://tools.ietf.org/id/draft-ietf-mipshop-rfc5268bis-01.txt This is the draft that became then RFC5568, so no need to mention it. http://www.rfc-editor.org/rfc/rfc5568.txt =3D> Fast Handovers for Proxy Mobile IPv6=20 http://www.rfc-editor.org/rfc/rfc5949.txt =3D> Host Identity Protocol http://www.rfc-editor.org/rfc/rfc4423.txt http://www.rfc-editor.org/rfc/rfc5201.txt http://www.rfc-editor.org/rfc/rfc6253.txt http://www.rfc-editor.org/rfc/rfc5206.txt =3D> IKEv2 Mobility and Multihoming Protocol (MOBIKE)=20 http://www.rfc-editor.org/rfc/rfc4555.txt =3D> GTPv2-C: 3rd Generation Partnership Project; Technical Specification G= roup Core Network and Terminals; 3GPP Evolved Packet System (EPS); =20 Evolved General Packet Radio Service (GPRS) Tunnelling Protocol for Control= plane (GTPv2-C); Stage 3 (Release 11) http://www.3gpp.org/ftp/Specs/archive/29_series/29.274/29274-b30.zip Please inform us if this list makes sense to you? Best regards, Georgios > -----Original Message----- > From: dmm-bounces@ietf.org [mailto:dmm-bounces@ietf.org] On Behalf Of > jouni korhonen > Sent: woensdag 19 september 2012 9:58 > To: dmm@ietf.org; h chan; Juan Carlos Zuniga > Cc: dmm-chairs@tools.ietf.org > Subject: Re: [DMM] Comments on DMM Gap Analysis. >=20 >=20 > Folks, >=20 > It has been rather silent on the list recently. Regarding the "explosion"= of > possible technologies in the GAP analysis, we discussed (chairs) that it = is > better to scope the area "a bit". The charter today has the assumption th= at > we build on top of existing _IP_ _Mobility_ protocols (and bunch of IETF > defined examples follow). So, to tighten the scope, the Gap Analysis shou= ld > leave all routing, session (SIP, ..), transport (MPTCP, SCTP, DCCP, ..), > locator/identifier split (HIP, Lisp, ..), naming (DNS tricks, ..) etc bas= ed > solutions out. Coarse but should help us to make progress. We could discu= ss > whether transport layer solution like SCTP fit in but I do not see them a= s end- > 2-end solutions being deployable in Internet at the moment. >=20 > Let us stick with technologies out there that have/had a place in sun: f= ew > MIP variants, MOBIKE, stuff in 3GPP(2) (oops.. but I think this deserves = to be > evaluated since they are somewhat popular), and what applications do > (reconnecting..). This analysis should be down to earth practical and rea= listic > on what is already out there to play with. >=20 > - Jouni & Julien >=20 >=20 >=20 > On Jul 27, 2012, at 3:53 PM, Jong-Hyouk Lee wrote: >=20 > > Dear Anthony and Juan. > > > > I enjoyed the both gap analysis documents (draft-chan-dmm-framework- > gap-analysis-02 and draft-zuniga-dmm-gap-analysis-01). Here I give some > comments that should be used directly in the gap analysis documents if yo= u > guys like. > > > > Kindly consider the followings during the gap analysis discussion (sinc= e I will > not be attending the IETF meeting this time). > > > > 1. Comment on address (resource) management in a DMM environment. > > 2. Comment on a deployment of a client-based mobility solution (i.e., > MIPv6) in a DMM environment. > > 3. Commnet on neighbor mobility anchors' information in a DMM > environment. > > 4. Commnet on an establishment of security associations in a DMM > environment. > > > > =3D=3D=3D 1. Comment on address (resource) management in a DMM > environment. > > =3D=3D=3D When existing IP mobility support protocols (e.g., MIPv6 and = PMIPv6) > are considered to be deployed in a DMM environment, a mobile node (MN) > is allowed to configure a new address while keeping its previous address(= es). > It introduces the following differences with the address (resource) > management of the existing ones: > > > > MN's address configured at the interface with a DMM environment: n =3D > > (IP address at the current access network + previously configured IP > > address(es) with ongoing sessions) MN's address configured at the > > interface without a DMM environment: 1 =3D (care-of address in MIPv6 or > > MN's home address in PMIPv6) > > > > This leads a couple of considerations we didn't have with the existing > > IP mobility support protocols. For instance, > > > > 1) MN's address management: use of a newly configured address at the > current access network for new communication sessions while a proper > address selection for previously established ongoing communication > sessions. > > > > 2) Additional treatment for ingress filtering: Ingress filtering is wid= ely used > against source address spoofing. The source addresses (especially, the > network prefix part) of incoming packets are strictly checked to make sur= e > that those packets are actually from the network that they claim to be fr= om. > As the MN are allowed to send data packets with the previously configured > address(es) at the new access network, those data packets would be filter= ed > at the ingress filtering place because the source address of those data > packets is not belonging to the new access network. Accordingly, an > additional treatment for ingress filtering is required. > > > > 3) MN's address increase at the MN's interface: Recall the number of MN= 's > address configured at an interface is n. Then, n is increased, as the MN > changes its point of attachment while keeping its ongoing communication > sessions. It brings the question: "How many addresses are currently possi= ble > to be configured at an interface?" > > > > 4) Routing entry increase at the serving mobility anchor: Let the servi= ng > mobility anchor is the mobility anchor serves the MN. Traffic associated = to > the MN travels via the serving mobility anchor. The increase of the addre= sses > associated to the MN, n, is not only concerning to the MN, but also > concerning the serving mobility anchor as it contributes the increase of > routing entries for the MN. > > > > =3D=3D=3D 2. Comment on a deployment of a client-based mobility solutio= n > > (i.e., MIPv6) in a DMM environment. =3D=3D=3D When a client-based mobil= ity > solution (i.e., MIPv6) is consiered to be deployed in a DMM environment, = an > MN is involved in mobility signaling such as Binding Update and > Acknowledgement messages. This is the big difference with the network- > based mobility solution (i.e., PMIPv6). As the MN send signaling to infor= m its > movement to its mobility anchor, the client-based mobility solution allow= s > the MN to supply client-centric decision for mobility management. > > > > Suppose that the origin mobility anchor is the mobility anchor where th= e > MN has configured its IP address and established ongoing communication > sessions with the IP address. The number of origin mobility anchors are n= - 1. > Recall that the serving mobility anchor is the mobility anchor where the = MN is > being served by. Then, the MN's involvement in mobility signaling brings = us > the questions: "Should we let the MN send mobilty signaling to its all mo= bility > anchors?" or "Would it make sense that the MN only sends mobility signali= ng > to its serving mobility anchor?" Depending on the choice, we will have > different results: > > > > 1) "MN sends mobility signaling to its all mobility anchors" causes: > > 1.1 increased mobility signaling load, e.g., signaling * (n - 1). > > 1.2 bidirectional tunnels are established between the MN and its mobili= ty > anchors. > > 1.3 tunneling overhead over the air is present. > > 1.4 but the tunnels are terminated at the MN so that the MN has control > over the tunnels. > > > > 2) "MN sends mobility signaling only to its serving mobility anchor" ca= uses: > > 2.1 reduced mobility signaling load, e.g., signaling * 1. > > 2.2 bidirectional tunnels are established between the serving mobility > anchors and origin mobility anchors. > > 2.3 tunneling overhead over the air can be avoided. > > 2.4 but the MN does not have control over the tunnels so it might affec= t to > NEtwork MObility (NEMO) as the MN (i.e., MR in NEMO) loses the tunneling > control. > > > > =3D=3D=3D 3. Neighbor mobility anchors' information in a DMM environmen= t. > > =3D=3D=3D In the client-based mobility solution such as MIPv6, the netw= ork > topology information does not required to be known to the mobility anchor= , > i.e., home agent (HA), since the HA is informed the current location of t= he > MN. As the HA knows the current location of the MN, it is able to tunnel > packets associated to the MN. In the network-based mobility solution such > as PMIPv6, the similar things happen, i.e., the tunnel between the local > mobility anchor (LMA) and the mobile access gateway (MAG) is established > for a given MN. > > > > However, as mobility anchors are distributed and bidirectional tunnels = (for > a given MN) between the distributed mobility anchors are required, the > neighbor mobility anchors' information should be provided to the MN or th= e > mobility anchor for the establishment of the directional tunnels or the > update of the MN's current location. > > > > Decoupling the data plane and control plane while keeping a centralized > node maintaining the mobility context including neighbor mobility anchors= ' > information (e.g., identification, IP address, etc) in a DMM environment = is > one of possible solutions. > > > > =3D=3D=3D 4. Comment on an establishment of security associations in a = DMM > > environment. =3D=3D=3D For each IP mobility support protocol, different= security > associations (SAs) are required for providing secure mobility services to= MNs > as follows: > > > > 1) MIPv6 > > 1.1 SA between MN and HA. > > 1.2 SA between MN and serving access router (AR) providing wireless lin= k > to the MN. > > > > 2) Fast Handover MIPv6 (FMIPv6) > > 2.1 SA between MN and HA. > > 2.2 SA between MN and serving AR. > > 2.3 SA between previous and new ARs. > > > > 3) PMIPv6 > > 3.1 SA between MN and serving MAG. > > 3.2 SA between serving MAG and LMA. > > > > 4) Fast Handover PMIPv6 (FPMIPv6) > > 4.1 SA between MN and serving MAG. > > 4.2 SA between serving MAG and LMA. > > 4.3 SA between previous and new MAGs. > > > > Note that the above ones do not consider the cases of SA with a securit= y- > backend server (e.g., AAA server) and with a correspondent node (CN). > > > > However, depending on DMM solutions, SAs are configured that are > > different from those of the existing IP mobility support protocols. > > For instance, > > > > 1) the case of "MN sends mobility signaling to its all mobility > > anchors" (client-based mobility solution) > > 1.1 SA between MN and serving mobility anchor providing wireless link t= o > the MN. > > 1.2 SA between MN and origin mobility anchors, i.e., (n - 1) SAs requir= ed > with MN and origin mobility anchors. > > > > 2) the case of "MN sends mobility signaling only to its serving > > mobility anchor" (client-based mobility solution) > > 2.1 SA between MN and serving mobility anchor. > > 2.2 SA between serving mobility anchor and origin mobility anchors, i.e= ., (n > - 1) SAs required with serving mobility anchor and origin mobility anchor= s. > > > > 3) the case of "serving mobility anchor sends signaling on behalf of > > the MN to origin mobility anchors" (network-based mobility solution) > > 3.1 SA between MN and serving mobility anchor. > > 3.2 SA between serving mobility anchor and origin mobility anchors, i.e= ., (n > - 1) SAs required with serving mobility anchor and origin mobility anchor= s. > > > > Note that as like before SAs with a security-backend server (e.g., AAA > server) and with a CN are not presented. > > > > As shown above, DMM solutions (that relies on bidirectional tunnelings = for > packet forwarding between MN and mobility anchors or between just > mobility anchors) might bring the key management issues to establish such > SAs. > > > > Since it's a holiday season, I cannot fully address all of them in my m= ind, but > kindly consider these ones. > > > > Cheers. > > > > -- > > 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/ > > > > _______________________________________________ > > 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 pierrick.seite@orange.com Wed Sep 19 06:03:10 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 D900C21F861F for ; Wed, 19 Sep 2012 06:03:09 -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, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g2OlGG3A-E2K for ; Wed, 19 Sep 2012 06:03:08 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by ietfa.amsl.com (Postfix) with ESMTP id 884EA21F86FF for ; Wed, 19 Sep 2012 06:03:07 -0700 (PDT) Received: from omfedm05.si.francetelecom.fr (unknown [xx.xx.xx.1]) by omfedm10.si.francetelecom.fr (ESMTP service) with ESMTP id BF3712640C8; Wed, 19 Sep 2012 15:03:06 +0200 (CEST) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.183]) by omfedm05.si.francetelecom.fr (ESMTP service) with ESMTP id 9976A35C0DC; Wed, 19 Sep 2012 15:03:06 +0200 (CEST) Received: from PEXCVZYM12.corporate.adroot.infra.ftgroup ([fe80::81f:1640:4749:5d13]) by PEXCVZYH02.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.02.0298.004; Wed, 19 Sep 2012 15:03:06 +0200 From: To: "'karagian@cs.utwente.nl'" , "jouni.nospam@gmail.com" , "dmm@ietf.org" , "h.anthony.chan@huawei.com" , "JuanCarlos.Zuniga@interdigital.com" Thread-Topic: [DMM] Comments on DMM Gap Analysis. Thread-Index: AQHNa/bmXcpjTD/9QkmtNxNtqHDjdJeRf28AgAA2BYCAAEDBoA== Date: Wed, 19 Sep 2012 13:03:05 +0000 Message-ID: <13040_1348059786_5059C28A_13040_17047_1_81C77F07008CA24F9783A98CFD706F71038847@PEXCVZYM12.corporate.adroot.infra.ftgroup> References: In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.197.38.6] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2012.9.19.121519 Cc: "dmm-chairs@tools.ietf.org" Subject: Re: [DMM] Comments on DMM Gap Analysis. 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, 19 Sep 2012 13:03:10 -0000 Hi Jouni and Julien, Sorry for jumping into the discussion but I'm a little bit confused with re= cent discussions in DMM. So, let me ask for clarifications about the scope = of the gap analysis...=20 The WG is now tackling with the work item 'Practices and Gap Analysis' and,= in my understanding, we are expected to provide a gap analysis regarding t= he use of mobility protocols in a distributed mobility management environm= ent. However, it seems that the scope of discussions on gap analysis is dif= ferent.... and I'm confused :-)=20 Actually, in the charter, we agreed to firstly "document practices for the = deployment of existing mobility protocols in a distributed mobility managem= ent environment" and, then, to make the gap analysis. However, considering = current discussions on "gap analysis": the document on practices has been o= mitted and discussions are about vanilla mobility protocols and architectur= es with respect to DMM requirements. So, maybe, such considerations are int= eresting in the scope of the problem statement, but it seems to me that it = is not the goal of the gap analysis, as initially intended in the charter. = Am I missing something?=20 If I refer to previous DMM charter (because current DMM charter is empty...= BTW, is there a reason for an empty charter?), one Work item was: "Documen= t practices for the deployment of existing mobility protocols in a distribu= ted mobility management environment". Is this document still in DMM stuff?= If yes, shouldn't we document practices before going into the gap analysis? 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: mercredi 19 septembre 2012 13:11 > =C0=A0: jouni.nospam@gmail.com; dmm@ietf.org; h.anthony.chan@huawei.com; > JuanCarlos.Zuniga@interdigital.com > Cc=A0: dmm-chairs@tools.ietf.org > Objet=A0: Re: [DMM] Comments on DMM Gap Analysis. >=20 > Hi Jouni, Hi all, >=20 > After discussing this issue with Carlos Jes=FAs Bernardos and Juan Carlos > Zuniga, we concluded that the following set of possible technologies > could be included in the Gap analysis draft: >=20 > =3D> Shim6: Level 3 Multihoming Shim Protocol for IPv6 http://www.rfc- > editor.org/rfc/rfc5533.txt >=20 >=20 > =3D> LISP Mobile Node > http://www.ietf.org/id/draft-meyer-lisp-mn-07.txt > Locator/ID Separation Protocol (LISP) > http://www.ietf.org/id/draft-ietf-lisp-23.txt >=20 > =3D> Mobile IPv6 Fast Handovers > http://tools.ietf.org/id/draft-ietf-mipshop-rfc5268bis-01.txt > This is the draft that became then RFC5568, so no need to mention it. > http://www.rfc-editor.org/rfc/rfc5568.txt >=20 >=20 > =3D> Fast Handovers for Proxy Mobile IPv6 > http://www.rfc-editor.org/rfc/rfc5949.txt >=20 > =3D> Host Identity Protocol > http://www.rfc-editor.org/rfc/rfc4423.txt > http://www.rfc-editor.org/rfc/rfc5201.txt > http://www.rfc-editor.org/rfc/rfc6253.txt > http://www.rfc-editor.org/rfc/rfc5206.txt >=20 >=20 >=20 > =3D> IKEv2 Mobility and Multihoming Protocol (MOBIKE) > http://www.rfc-editor.org/rfc/rfc4555.txt >=20 >=20 > =3D> GTPv2-C: 3rd Generation Partnership Project; Technical Specification > Group Core Network and Terminals; 3GPP Evolved Packet System (EPS); > Evolved General Packet Radio Service (GPRS) Tunnelling Protocol for > Control plane (GTPv2-C); Stage 3 (Release 11) > http://www.3gpp.org/ftp/Specs/archive/29_series/29.274/29274-b30.zip >=20 > Please inform us if this list makes sense to you? >=20 > Best regards, > Georgios >=20 >=20 > > -----Original Message----- > > From: dmm-bounces@ietf.org [mailto:dmm-bounces@ietf.org] On Behalf Of > > jouni korhonen > > Sent: woensdag 19 september 2012 9:58 > > To: dmm@ietf.org; h chan; Juan Carlos Zuniga > > Cc: dmm-chairs@tools.ietf.org > > Subject: Re: [DMM] Comments on DMM Gap Analysis. > > > > > > Folks, > > > > It has been rather silent on the list recently. Regarding the > "explosion" of > > possible technologies in the GAP analysis, we discussed (chairs) that > it is > > better to scope the area "a bit". The charter today has the > assumption that > > we build on top of existing _IP_ _Mobility_ protocols (and bunch of > IETF > > defined examples follow). So, to tighten the scope, the Gap Analysis > should > > leave all routing, session (SIP, ..), transport (MPTCP, SCTP, DCCP, > ..), > > locator/identifier split (HIP, Lisp, ..), naming (DNS tricks, ..) etc > based > > solutions out. Coarse but should help us to make progress. We could > discuss > > whether transport layer solution like SCTP fit in but I do not see > them as end- > > 2-end solutions being deployable in Internet at the moment. > > > > Let us stick with technologies out there that have/had a place in > sun: few > > MIP variants, MOBIKE, stuff in 3GPP(2) (oops.. but I think this > deserves to be > > evaluated since they are somewhat popular), and what applications do > > (reconnecting..). This analysis should be down to earth practical and > realistic > > on what is already out there to play with. > > > > - Jouni & Julien > > > > > > > > On Jul 27, 2012, at 3:53 PM, Jong-Hyouk Lee wrote: > > > > > Dear Anthony and Juan. > > > > > > I enjoyed the both gap analysis documents (draft-chan-dmm- > framework- > > gap-analysis-02 and draft-zuniga-dmm-gap-analysis-01). Here I give > some > > comments that should be used directly in the gap analysis documents > if you > > guys like. > > > > > > Kindly consider the followings during the gap analysis discussion > (since I will > > not be attending the IETF meeting this time). > > > > > > 1. Comment on address (resource) management in a DMM environment. > > > 2. Comment on a deployment of a client-based mobility solution > (i.e., > > MIPv6) in a DMM environment. > > > 3. Commnet on neighbor mobility anchors' information in a DMM > > environment. > > > 4. Commnet on an establishment of security associations in a DMM > > environment. > > > > > > =3D=3D=3D 1. Comment on address (resource) management in a DMM > > environment. > > > =3D=3D=3D When existing IP mobility support protocols (e.g., MIPv6 and > PMIPv6) > > are considered to be deployed in a DMM environment, a mobile node > (MN) > > is allowed to configure a new address while keeping its previous > address(es). > > It introduces the following differences with the address (resource) > > management of the existing ones: > > > > > > MN's address configured at the interface with a DMM environment: n > =3D > > > (IP address at the current access network + previously configured > IP > > > address(es) with ongoing sessions) MN's address configured at the > > > interface without a DMM environment: 1 =3D (care-of address in MIPv6 > or > > > MN's home address in PMIPv6) > > > > > > This leads a couple of considerations we didn't have with the > existing > > > IP mobility support protocols. For instance, > > > > > > 1) MN's address management: use of a newly configured address at > the > > current access network for new communication sessions while a proper > > address selection for previously established ongoing communication > > sessions. > > > > > > 2) Additional treatment for ingress filtering: Ingress filtering is > widely used > > against source address spoofing. The source addresses (especially, > the > > network prefix part) of incoming packets are strictly checked to make > sure > > that those packets are actually from the network that they claim to > be from. > > As the MN are allowed to send data packets with the previously > configured > > address(es) at the new access network, those data packets would be > filtered > > at the ingress filtering place because the source address of those > data > > packets is not belonging to the new access network. Accordingly, an > > additional treatment for ingress filtering is required. > > > > > > 3) MN's address increase at the MN's interface: Recall the number > of MN's > > address configured at an interface is n. Then, n is increased, as the > MN > > changes its point of attachment while keeping its ongoing > communication > > sessions. It brings the question: "How many addresses are currently > possible > > to be configured at an interface?" > > > > > > 4) Routing entry increase at the serving mobility anchor: Let the > serving > > mobility anchor is the mobility anchor serves the MN. Traffic > associated to > > the MN travels via the serving mobility anchor. The increase of the > addresses > > associated to the MN, n, is not only concerning to the MN, but also > > concerning the serving mobility anchor as it contributes the increase > of > > routing entries for the MN. > > > > > > =3D=3D=3D 2. Comment on a deployment of a client-based mobility solut= ion > > > (i.e., MIPv6) in a DMM environment. =3D=3D=3D When a client-based > mobility > > solution (i.e., MIPv6) is consiered to be deployed in a DMM > environment, an > > MN is involved in mobility signaling such as Binding Update and > > Acknowledgement messages. This is the big difference with the > network- > > based mobility solution (i.e., PMIPv6). As the MN send signaling to > inform its > > movement to its mobility anchor, the client-based mobility solution > allows > > the MN to supply client-centric decision for mobility management. > > > > > > Suppose that the origin mobility anchor is the mobility anchor > where the > > MN has configured its IP address and established ongoing > communication > > sessions with the IP address. The number of origin mobility anchors > are n - 1. > > Recall that the serving mobility anchor is the mobility anchor where > the MN is > > being served by. Then, the MN's involvement in mobility signaling > brings us > > the questions: "Should we let the MN send mobilty signaling to its > all mobility > > anchors?" or "Would it make sense that the MN only sends mobility > signaling > > to its serving mobility anchor?" Depending on the choice, we will > have > > different results: > > > > > > 1) "MN sends mobility signaling to its all mobility anchors" > causes: > > > 1.1 increased mobility signaling load, e.g., signaling * (n - 1). > > > 1.2 bidirectional tunnels are established between the MN and its > mobility > > anchors. > > > 1.3 tunneling overhead over the air is present. > > > 1.4 but the tunnels are terminated at the MN so that the MN has > control > > over the tunnels. > > > > > > 2) "MN sends mobility signaling only to its serving mobility > anchor" causes: > > > 2.1 reduced mobility signaling load, e.g., signaling * 1. > > > 2.2 bidirectional tunnels are established between the serving > mobility > > anchors and origin mobility anchors. > > > 2.3 tunneling overhead over the air can be avoided. > > > 2.4 but the MN does not have control over the tunnels so it might > affect to > > NEtwork MObility (NEMO) as the MN (i.e., MR in NEMO) loses the > tunneling > > control. > > > > > > =3D=3D=3D 3. Neighbor mobility anchors' information in a DMM environm= ent. > > > =3D=3D=3D In the client-based mobility solution such as MIPv6, the > network > > topology information does not required to be known to the mobility > anchor, > > i.e., home agent (HA), since the HA is informed the current location > of the > > MN. As the HA knows the current location of the MN, it is able to > tunnel > > packets associated to the MN. In the network-based mobility solution > such > > as PMIPv6, the similar things happen, i.e., the tunnel between the > local > > mobility anchor (LMA) and the mobile access gateway (MAG) is > established > > for a given MN. > > > > > > However, as mobility anchors are distributed and bidirectional > tunnels (for > > a given MN) between the distributed mobility anchors are required, > the > > neighbor mobility anchors' information should be provided to the MN > or the > > mobility anchor for the establishment of the directional tunnels or > the > > update of the MN's current location. > > > > > > Decoupling the data plane and control plane while keeping a > centralized > > node maintaining the mobility context including neighbor mobility > anchors' > > information (e.g., identification, IP address, etc) in a DMM > environment is > > one of possible solutions. > > > > > > =3D=3D=3D 4. Comment on an establishment of security associations in a > DMM > > > environment. =3D=3D=3D For each IP mobility support protocol, differe= nt > security > > associations (SAs) are required for providing secure mobility > services to MNs > > as follows: > > > > > > 1) MIPv6 > > > 1.1 SA between MN and HA. > > > 1.2 SA between MN and serving access router (AR) providing wireless > link > > to the MN. > > > > > > 2) Fast Handover MIPv6 (FMIPv6) > > > 2.1 SA between MN and HA. > > > 2.2 SA between MN and serving AR. > > > 2.3 SA between previous and new ARs. > > > > > > 3) PMIPv6 > > > 3.1 SA between MN and serving MAG. > > > 3.2 SA between serving MAG and LMA. > > > > > > 4) Fast Handover PMIPv6 (FPMIPv6) > > > 4.1 SA between MN and serving MAG. > > > 4.2 SA between serving MAG and LMA. > > > 4.3 SA between previous and new MAGs. > > > > > > Note that the above ones do not consider the cases of SA with a > security- > > backend server (e.g., AAA server) and with a correspondent node (CN). > > > > > > However, depending on DMM solutions, SAs are configured that are > > > different from those of the existing IP mobility support protocols. > > > For instance, > > > > > > 1) the case of "MN sends mobility signaling to its all mobility > > > anchors" (client-based mobility solution) > > > 1.1 SA between MN and serving mobility anchor providing wireless > link to > > the MN. > > > 1.2 SA between MN and origin mobility anchors, i.e., (n - 1) SAs > required > > with MN and origin mobility anchors. > > > > > > 2) the case of "MN sends mobility signaling only to its serving > > > mobility anchor" (client-based mobility solution) > > > 2.1 SA between MN and serving mobility anchor. > > > 2.2 SA between serving mobility anchor and origin mobility anchors, > i.e., (n > > - 1) SAs required with serving mobility anchor and origin mobility > anchors. > > > > > > 3) the case of "serving mobility anchor sends signaling on behalf > of > > > the MN to origin mobility anchors" (network-based mobility > solution) > > > 3.1 SA between MN and serving mobility anchor. > > > 3.2 SA between serving mobility anchor and origin mobility anchors, > i.e., (n > > - 1) SAs required with serving mobility anchor and origin mobility > anchors. > > > > > > Note that as like before SAs with a security-backend server (e.g., > AAA > > server) and with a CN are not presented. > > > > > > As shown above, DMM solutions (that relies on bidirectional > tunnelings for > > packet forwarding between MN and mobility anchors or between just > > mobility anchors) might bring the key management issues to establish > such > > SAs. > > > > > > Since it's a holiday season, I cannot fully address all of them in > my mind, but > > kindly consider these ones. > > > > > > Cheers. > > > > > > -- > > > 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/ > > > > > > _______________________________________________ > > > 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 ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, France Telecom - Orange decline toute responsabilite si ce message a ete al= tere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, France Telecom - Orange is not liable for message= s that have been modified, changed or falsified. Thank you. From sarikaya2012@gmail.com Wed Sep 19 09:15: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 1587421F8711 for ; Wed, 19 Sep 2012 09:15:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.3 X-Spam-Level: X-Spam-Status: No, score=-3.3 tagged_above=-999 required=5 tests=[AWL=0.299, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MKd9QGUc86Gk for ; Wed, 19 Sep 2012 09:14:58 -0700 (PDT) Received: from mail-ie0-f172.google.com (mail-ie0-f172.google.com [209.85.223.172]) by ietfa.amsl.com (Postfix) with ESMTP id 823EF21F86E3 for ; Wed, 19 Sep 2012 09:14:58 -0700 (PDT) Received: by iec9 with SMTP id 9so2050980iec.31 for ; Wed, 19 Sep 2012 09:14:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:content-transfer-encoding; bh=vnSKtDm6kiIZudqLFsw8TpARpjJlidMDtrjtJd4z6MY=; b=HaZWAZ4AE4OHrZf5qUOwGKT2cUwafSudYi+dx+Rq/PSlX6Z4vU8HLBF4BhC9Z6PQts JbZYShonDUEuvRfp8ri0X4YTq+en26ThUaPjQ8m3TWyaeXiGOBs+SzkFuwECtylJ1VPp VU6fAE8ga5lK0fscv3mHIm5od21SzsG1SgVhpMKD7aTTEAlEr5MzosAJv6EIwI64idvP oqGQoD3l9W/Gp3aM88YpcSle0LvCbWHFvk3LZBmRb8R7LOCy4I4FHLSgIXskardaG3ny pyxSlmRrm3wxbv7ekeMiG5d9fkxxYXxKvlW+1dcYwHJeSl0ULfupBej2muGsZzL6F6kM gRJg== MIME-Version: 1.0 Received: by 10.50.187.194 with SMTP id fu2mr3284723igc.37.1348071297931; Wed, 19 Sep 2012 09:14:57 -0700 (PDT) Received: by 10.231.55.70 with HTTP; Wed, 19 Sep 2012 09:14:57 -0700 (PDT) In-Reply-To: References: Date: Wed, 19 Sep 2012 11:14:57 -0500 Message-ID: From: Behcet Sarikaya To: jouni korhonen Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Cc: dmm@ietf.org Subject: Re: [DMM] Comments on DMM Gap Analysis. X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: sarikaya@ieee.org List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Sep 2012 16:15:00 -0000 Hi Jouni, I agree. I also suggest that we do not take cloud networks lightly. Operator cloud networks are there already and it is spreading fast, and I can say that soon it is going to cover all operators worldwide soon. We should not ignore that fact that mobility entities will be in the cloud. Also many entities we thought they were far away, with cloud networks they will become neighbors in IPv6 sense. I suggest that gap analysis should take into account the cloud. Regards, Behcet On Wed, Sep 19, 2012 at 2:57 AM, jouni korhonen wr= ote: > > Folks, > > It has been rather silent on the list recently. Regarding the "explosion"= of possible > technologies in the GAP analysis, we discussed (chairs) that it is better= to scope the > area "a bit". The charter today has the assumption that we build on top o= f existing _IP_ > _Mobility_ protocols (and bunch of IETF defined examples follow). So, to = tighten the > scope, the Gap Analysis should leave all routing, session (SIP, ..), tra= nsport (MPTCP, > SCTP, DCCP, ..), locator/identifier split (HIP, Lisp, ..), naming (DNS tr= icks, ..) etc > based solutions out. Coarse but should help us to make progress. We could= discuss whether > transport layer solution like SCTP fit in but I do not see them as end-2-= end solutions > being deployable in Internet at the moment. > > Let us stick with technologies out there that have/had a place in sun: f= ew MIP variants, > MOBIKE, stuff in 3GPP(2) (oops.. but I think this deserves to be evaluate= d since they > are somewhat popular), and what applications do (reconnecting..). This an= alysis should > be down to earth practical and realistic on what is already out there to = play with. > > - Jouni & Julien > > > > On Jul 27, 2012, at 3:53 PM, Jong-Hyouk Lee wrote: > >> Dear Anthony and Juan. >> >> I enjoyed the both gap analysis documents (draft-chan-dmm-framework-gap-= analysis-02 and draft-zuniga-dmm-gap-analysis-01). Here I give some comment= s that should be used directly in the gap analysis documents if you guys li= ke. >> >> Kindly consider the followings during the gap analysis discussion (since= I will not be attending the IETF meeting this time). >> >> 1. Comment on address (resource) management in a DMM environment. >> 2. Comment on a deployment of a client-based mobility solution (i.e., MI= Pv6) in a DMM environment. >> 3. Commnet on neighbor mobility anchors' information in a DMM environmen= t. >> 4. Commnet on an establishment of security associations in a DMM environ= ment. >> >> =3D=3D=3D 1. Comment on address (resource) management in a DMM environme= nt. =3D=3D=3D >> When existing IP mobility support protocols (e.g., MIPv6 and PMIPv6) are= considered to be deployed in a DMM environment, a mobile node (MN) is allo= wed to configure a new address while keeping its previous address(es). It i= ntroduces the following differences with the address (resource) management = of the existing ones: >> >> MN=92s address configured at the interface with a DMM environment: n =3D= (IP address at the current access network + previously configured IP addre= ss(es) with ongoing sessions) >> MN=92s address configured at the interface without a DMM environment: 1 = =3D (care-of address in MIPv6 or MN=92s home address in PMIPv6) >> >> This leads a couple of considerations we didn=92t have with the existing= IP mobility support protocols. For instance, >> >> 1) MN=92s address management: use of a newly configured address at the c= urrent access network for new communication sessions while a proper address= selection for previously established ongoing communication sessions. >> >> 2) Additional treatment for ingress filtering: Ingress filtering is wide= ly used against source address spoofing. The source addresses (especially, = the network prefix part) of incoming packets are strictly checked to make s= ure that those packets are actually from the network that they claim to be = from. As the MN are allowed to send data packets with the previously config= ured address(es) at the new access network, those data packets would be fil= tered at the ingress filtering place because the source address of those da= ta packets is not belonging to the new access network. Accordingly, an addi= tional treatment for ingress filtering is required. >> >> 3) MN=92s address increase at the MN=92s interface: Recall the number of= MN=92s address configured at an interface is n. Then, n is increased, as t= he MN changes its point of attachment while keeping its ongoing communicati= on sessions. It brings the question: =93How many addresses are currently po= ssible to be configured at an interface?=94 >> >> 4) Routing entry increase at the serving mobility anchor: Let the servin= g mobility anchor is the mobility anchor serves the MN. Traffic associated = to the MN travels via the serving mobility anchor. The increase of the addr= esses associated to the MN, n, is not only concerning to the MN, but also c= oncerning the serving mobility anchor as it contributes the increase of rou= ting entries for the MN. >> >> =3D=3D=3D 2. Comment on a deployment of a client-based mobility solution= (i.e., MIPv6) in a DMM environment. =3D=3D=3D >> When a client-based mobility solution (i.e., MIPv6) is consiered to be d= eployed in a DMM environment, an MN is involved in mobility signaling such = as Binding Update and Acknowledgement messages. This is the big difference = with the network-based mobility solution (i.e., PMIPv6). As the MN send sig= naling to inform its movement to its mobility anchor, the client-based mobi= lity solution allows the MN to supply client-centric decision for mobility = management. >> >> Suppose that the origin mobility anchor is the mobility anchor where the= MN has configured its IP address and established ongoing communication ses= sions with the IP address. The number of origin mobility anchors are n - 1.= Recall that the serving mobility anchor is the mobility anchor where the M= N is being served by. Then, the MN=92s involvement in mobility signaling br= ings us the questions: =93Should we let the MN send mobilty signaling to it= s all mobility anchors?=94 or =93Would it make sense that the MN only sends= mobility signaling to its serving mobility anchor?=94 Depending on the cho= ice, we will have different results: >> >> 1) =93MN sends mobility signaling to its all mobility anchors=94 causes: >> 1.1 increased mobility signaling load, e.g., signaling * (n - 1). >> 1.2 bidirectional tunnels are established between the MN and its mobilit= y anchors. >> 1.3 tunneling overhead over the air is present. >> 1.4 but the tunnels are terminated at the MN so that the MN has control = over the tunnels. >> >> 2) =93MN sends mobility signaling only to its serving mobility anchor=94= causes: >> 2.1 reduced mobility signaling load, e.g., signaling * 1. >> 2.2 bidirectional tunnels are established between the serving mobility a= nchors and origin mobility anchors. >> 2.3 tunneling overhead over the air can be avoided. >> 2.4 but the MN does not have control over the tunnels so it might affect= to NEtwork MObility (NEMO) as the MN (i.e., MR in NEMO) loses the tunnelin= g control. >> >> =3D=3D=3D 3. Neighbor mobility anchors=92 information in a DMM environme= nt. =3D=3D=3D >> In the client-based mobility solution such as MIPv6, the network topolog= y information does not required to be known to the mobility anchor, i.e., h= ome agent (HA), since the HA is informed the current location of the MN. As= the HA knows the current location of the MN, it is able to tunnel packets = associated to the MN. In the network-based mobility solution such as PMIPv6= , the similar things happen, i.e., the tunnel between the local mobility an= chor (LMA) and the mobile access gateway (MAG) is established for a given M= N. >> >> However, as mobility anchors are distributed and bidirectional tunnels (= for a given MN) between the distributed mobility anchors are required, the = neighbor mobility anchors=92 information should be provided to the MN or th= e mobility anchor for the establishment of the directional tunnels or the u= pdate of the MN=92s current location. >> >> Decoupling the data plane and control plane while keeping a centralized = node maintaining the mobility context including neighbor mobility anchors= =92 information (e.g., identification, IP address, etc) in a DMM environmen= t is one of possible solutions. >> >> =3D=3D=3D 4. Comment on an establishment of security associations in a D= MM environment. =3D=3D=3D >> For each IP mobility support protocol, different security associations (= SAs) are required for providing secure mobility services to MNs as follows: >> >> 1) MIPv6 >> 1.1 SA between MN and HA. >> 1.2 SA between MN and serving access router (AR) providing wireless link= to the MN. >> >> 2) Fast Handover MIPv6 (FMIPv6) >> 2.1 SA between MN and HA. >> 2.2 SA between MN and serving AR. >> 2.3 SA between previous and new ARs. >> >> 3) PMIPv6 >> 3.1 SA between MN and serving MAG. >> 3.2 SA between serving MAG and LMA. >> >> 4) Fast Handover PMIPv6 (FPMIPv6) >> 4.1 SA between MN and serving MAG. >> 4.2 SA between serving MAG and LMA. >> 4.3 SA between previous and new MAGs. >> >> Note that the above ones do not consider the cases of SA with a security= -backend server (e.g., AAA server) and with a correspondent node (CN). >> >> However, depending on DMM solutions, SAs are configured that are differe= nt from those of the existing IP mobility support protocols. For instance, >> >> 1) the case of =93MN sends mobility signaling to its all mobility anchor= s=94 (client-based mobility solution) >> 1.1 SA between MN and serving mobility anchor providing wireless link to= the MN. >> 1.2 SA between MN and origin mobility anchors, i.e., (n - 1) SAs require= d with MN and origin mobility anchors. >> >> 2) the case of =93MN sends mobility signaling only to its serving mobili= ty anchor=94 (client-based mobility solution) >> 2.1 SA between MN and serving mobility anchor. >> 2.2 SA between serving mobility anchor and origin mobility anchors, i.e.= , (n - 1) SAs required with serving mobility anchor and origin mobility anc= hors. >> >> 3) the case of =93serving mobility anchor sends signaling on behalf of t= he MN to origin mobility anchors=94 (network-based mobility solution) >> 3.1 SA between MN and serving mobility anchor. >> 3.2 SA between serving mobility anchor and origin mobility anchors, i.e.= , (n - 1) SAs required with serving mobility anchor and origin mobility anc= hors. >> >> Note that as like before SAs with a security-backend server (e.g., AAA s= erver) and with a CN are not presented. >> >> As shown above, DMM solutions (that relies on bidirectional tunnelings f= or packet forwarding between MN and mobility anchors or between just mobili= ty anchors) might bring the key management issues to establish such SAs. >> >> Since it's a holiday season, I cannot fully address all of them in my mi= nd, but kindly consider these ones. >> >> Cheers. >> >> -- >> 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/ >> >> _______________________________________________ >> 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 JuanCarlos.Zuniga@InterDigital.com Wed Sep 19 12:08: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 B1B8821E803A for ; Wed, 19 Sep 2012 12:08:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FSEbqZB-HsoO for ; Wed, 19 Sep 2012 12:08:10 -0700 (PDT) Received: from idcout.InterDigital.com (smtp-out1.interdigital.com [64.208.228.135]) by ietfa.amsl.com (Postfix) with ESMTP id 3D89911E8097 for ; Wed, 19 Sep 2012 12:08:10 -0700 (PDT) Received: from SAM.InterDigital.com ([10.30.2.11]) by idcout.InterDigital.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 19 Sep 2012 15:08:08 -0400 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: Wed, 19 Sep 2012 15:08:07 -0400 Message-ID: In-Reply-To: <13040_1348059786_5059C28A_13040_17047_1_81C77F07008CA24F9783A98CFD706F71038847@PEXCVZYM12.corporate.adroot.infra.ftgroup> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [DMM] Comments on DMM Gap Analysis. Thread-Index: AQHNa/bmXcpjTD/9QkmtNxNtqHDjdJeRf28AgAA2BYCAAEDBoIAAZGOQ References: <13040_1348059786_5059C28A_13040_17047_1_81C77F07008CA24F9783A98CFD706F71038847@PEXCVZYM12.corporate.adroot.infra.ftgroup> From: "Zuniga, Juan Carlos" To: , , , , X-OriginalArrivalTime: 19 Sep 2012 19:08:08.0830 (UTC) FILETIME=[1B2741E0:01CD969A] Cc: dmm-chairs@tools.ietf.org Subject: Re: [DMM] Comments on DMM Gap Analysis. 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, 19 Sep 2012 19:08:12 -0000 Hi Pierrick, all, The document title is "DMM Practices and Gap Analysis", and the = intention is to address both. When we presented at the meeting it I made = it clear that we wanted to show our approach to the problem, which was = first to agree on what are the "current practices" that we want to = consider, and then provide a "gap analysis" wrt the DMM requirements = document.=20 We are currently working on a new version of the document taking into = account the feedback we got at the meeting and on the ML. We will = provide more details about the current practices and will take a stab at = the gap analysis for discussion.=20 Cheers, Juan Carlos=20 > -----Original Message----- > From: pierrick.seite@orange.com [mailto:pierrick.seite@orange.com] > Sent: Wednesday, September 19, 2012 9:03 AM > To: 'karagian@cs.utwente.nl'; jouni.nospam@gmail.com; dmm@ietf.org; > h.anthony.chan@huawei.com; Zuniga, Juan Carlos > Cc: dmm-chairs@tools.ietf.org > Subject: RE: [DMM] Comments on DMM Gap Analysis. >=20 > Hi Jouni and Julien, >=20 >=20 > Sorry for jumping into the discussion but I'm a little bit confused > with recent discussions in DMM. So, let me ask for clarifications = about > the scope of the gap analysis... >=20 > The WG is now tackling with the work item 'Practices and Gap Analysis' > and, in my understanding, we are expected to provide a gap analysis > regarding the use of mobility protocols in a distributed mobility > management environment. However, it seems that the scope of = discussions > on gap analysis is different.... and I'm confused :-) >=20 > Actually, in the charter, we agreed to firstly "document practices for > the deployment of existing mobility protocols in a distributed = mobility > management environment" and, then, to make the gap analysis. However, > considering current discussions on "gap analysis": the document on > practices has been omitted and discussions are about vanilla mobility > protocols and architectures with respect to DMM requirements. So, > maybe, such considerations are interesting in the scope of the problem > statement, but it seems to me that it is not the goal of the gap > analysis, as initially intended in the charter. Am I missing = something? >=20 > If I refer to previous DMM charter (because current DMM charter is > empty... BTW, is there a reason for an empty charter?), one Work item > was: "Document practices for the deployment of existing mobility > protocols in a distributed mobility management environment". Is this > document still in DMM stuff? If yes, shouldn't we document practices > before going into the gap analysis? >=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: mercredi 19 septembre 2012 13:11 > > =C0=A0: jouni.nospam@gmail.com; dmm@ietf.org; = h.anthony.chan@huawei.com; > > JuanCarlos.Zuniga@interdigital.com > > Cc=A0: dmm-chairs@tools.ietf.org > > Objet=A0: Re: [DMM] Comments on DMM Gap Analysis. > > > > Hi Jouni, Hi all, > > > > After discussing this issue with Carlos Jes=FAs Bernardos and Juan > Carlos > > Zuniga, we concluded that the following set of possible technologies > > could be included in the Gap analysis draft: > > > > =3D> Shim6: Level 3 Multihoming Shim Protocol for IPv6 = http://www.rfc- > > editor.org/rfc/rfc5533.txt > > > > > > =3D> LISP Mobile Node > > http://www.ietf.org/id/draft-meyer-lisp-mn-07.txt > > Locator/ID Separation Protocol (LISP) > > http://www.ietf.org/id/draft-ietf-lisp-23.txt > > > > =3D> Mobile IPv6 Fast Handovers > > http://tools.ietf.org/id/draft-ietf-mipshop-rfc5268bis-01.txt > > This is the draft that became then RFC5568, so no need to mention = it. > > http://www.rfc-editor.org/rfc/rfc5568.txt > > > > > > =3D> Fast Handovers for Proxy Mobile IPv6 > > http://www.rfc-editor.org/rfc/rfc5949.txt > > > > =3D> Host Identity Protocol > > http://www.rfc-editor.org/rfc/rfc4423.txt > > http://www.rfc-editor.org/rfc/rfc5201.txt > > http://www.rfc-editor.org/rfc/rfc6253.txt > > http://www.rfc-editor.org/rfc/rfc5206.txt > > > > > > > > =3D> IKEv2 Mobility and Multihoming Protocol (MOBIKE) > > http://www.rfc-editor.org/rfc/rfc4555.txt > > > > > > =3D> GTPv2-C: 3rd Generation Partnership Project; Technical > Specification > > Group Core Network and Terminals; 3GPP Evolved Packet System (EPS); > > Evolved General Packet Radio Service (GPRS) Tunnelling Protocol for > > Control plane (GTPv2-C); Stage 3 (Release 11) > > http://www.3gpp.org/ftp/Specs/archive/29_series/29.274/29274-b30.zip > > > > Please inform us if this list makes sense to you? > > > > Best regards, > > Georgios > > > > > > > -----Original Message----- > > > From: dmm-bounces@ietf.org [mailto:dmm-bounces@ietf.org] On Behalf > Of > > > jouni korhonen > > > Sent: woensdag 19 september 2012 9:58 > > > To: dmm@ietf.org; h chan; Juan Carlos Zuniga > > > Cc: dmm-chairs@tools.ietf.org > > > Subject: Re: [DMM] Comments on DMM Gap Analysis. > > > > > > > > > Folks, > > > > > > It has been rather silent on the list recently. Regarding the > > "explosion" of > > > possible technologies in the GAP analysis, we discussed (chairs) > that > > it is > > > better to scope the area "a bit". The charter today has the > > assumption that > > > we build on top of existing _IP_ _Mobility_ protocols (and bunch = of > > IETF > > > defined examples follow). So, to tighten the scope, the Gap > Analysis > > should > > > leave all routing, session (SIP, ..), transport (MPTCP, SCTP, > DCCP, > > ..), > > > locator/identifier split (HIP, Lisp, ..), naming (DNS tricks, ..) > etc > > based > > > solutions out. Coarse but should help us to make progress. We = could > > discuss > > > whether transport layer solution like SCTP fit in but I do not see > > them as end- > > > 2-end solutions being deployable in Internet at the moment. > > > > > > Let us stick with technologies out there that have/had a place in > > sun: few > > > MIP variants, MOBIKE, stuff in 3GPP(2) (oops.. but I think this > > deserves to be > > > evaluated since they are somewhat popular), and what applications > do > > > (reconnecting..). This analysis should be down to earth practical > and > > realistic > > > on what is already out there to play with. > > > > > > - Jouni & Julien > > > > > > > > > > > > On Jul 27, 2012, at 3:53 PM, Jong-Hyouk Lee wrote: > > > > > > > Dear Anthony and Juan. > > > > > > > > I enjoyed the both gap analysis documents (draft-chan-dmm- > > framework- > > > gap-analysis-02 and draft-zuniga-dmm-gap-analysis-01). Here I give > > some > > > comments that should be used directly in the gap analysis = documents > > if you > > > guys like. > > > > > > > > Kindly consider the followings during the gap analysis = discussion > > (since I will > > > not be attending the IETF meeting this time). > > > > > > > > 1. Comment on address (resource) management in a DMM = environment. > > > > 2. Comment on a deployment of a client-based mobility solution > > (i.e., > > > MIPv6) in a DMM environment. > > > > 3. Commnet on neighbor mobility anchors' information in a DMM > > > environment. > > > > 4. Commnet on an establishment of security associations in a DMM > > > environment. > > > > > > > > =3D=3D=3D 1. Comment on address (resource) management in a DMM > > > environment. > > > > =3D=3D=3D When existing IP mobility support protocols (e.g., = MIPv6 and > > PMIPv6) > > > are considered to be deployed in a DMM environment, a mobile node > > (MN) > > > is allowed to configure a new address while keeping its previous > > address(es). > > > It introduces the following differences with the address = (resource) > > > management of the existing ones: > > > > > > > > MN's address configured at the interface with a DMM environment: > n > > =3D > > > > (IP address at the current access network + previously = configured > > IP > > > > address(es) with ongoing sessions) MN's address configured at = the > > > > interface without a DMM environment: 1 =3D (care-of address in > MIPv6 > > or > > > > MN's home address in PMIPv6) > > > > > > > > This leads a couple of considerations we didn't have with the > > existing > > > > IP mobility support protocols. For instance, > > > > > > > > 1) MN's address management: use of a newly configured address at > > the > > > current access network for new communication sessions while a > proper > > > address selection for previously established ongoing communication > > > sessions. > > > > > > > > 2) Additional treatment for ingress filtering: Ingress filtering > is > > widely used > > > against source address spoofing. The source addresses (especially, > > the > > > network prefix part) of incoming packets are strictly checked to > make > > sure > > > that those packets are actually from the network that they claim = to > > be from. > > > As the MN are allowed to send data packets with the previously > > configured > > > address(es) at the new access network, those data packets would be > > filtered > > > at the ingress filtering place because the source address of those > > data > > > packets is not belonging to the new access network. Accordingly, = an > > > additional treatment for ingress filtering is required. > > > > > > > > 3) MN's address increase at the MN's interface: Recall the = number > > of MN's > > > address configured at an interface is n. Then, n is increased, as > the > > MN > > > changes its point of attachment while keeping its ongoing > > communication > > > sessions. It brings the question: "How many addresses are = currently > > possible > > > to be configured at an interface?" > > > > > > > > 4) Routing entry increase at the serving mobility anchor: Let = the > > serving > > > mobility anchor is the mobility anchor serves the MN. Traffic > > associated to > > > the MN travels via the serving mobility anchor. The increase of = the > > addresses > > > associated to the MN, n, is not only concerning to the MN, but = also > > > concerning the serving mobility anchor as it contributes the > increase > > of > > > routing entries for the MN. > > > > > > > > =3D=3D=3D 2. Comment on a deployment of a client-based mobility > solution > > > > (i.e., MIPv6) in a DMM environment. =3D=3D=3D When a = client-based > > mobility > > > solution (i.e., MIPv6) is consiered to be deployed in a DMM > > environment, an > > > MN is involved in mobility signaling such as Binding Update and > > > Acknowledgement messages. This is the big difference with the > > network- > > > based mobility solution (i.e., PMIPv6). As the MN send signaling = to > > inform its > > > movement to its mobility anchor, the client-based mobility = solution > > allows > > > the MN to supply client-centric decision for mobility management. > > > > > > > > Suppose that the origin mobility anchor is the mobility anchor > > where the > > > MN has configured its IP address and established ongoing > > communication > > > sessions with the IP address. The number of origin mobility = anchors > > are n - 1. > > > Recall that the serving mobility anchor is the mobility anchor > where > > the MN is > > > being served by. Then, the MN's involvement in mobility signaling > > brings us > > > the questions: "Should we let the MN send mobilty signaling to its > > all mobility > > > anchors?" or "Would it make sense that the MN only sends mobility > > signaling > > > to its serving mobility anchor?" Depending on the choice, we will > > have > > > different results: > > > > > > > > 1) "MN sends mobility signaling to its all mobility anchors" > > causes: > > > > 1.1 increased mobility signaling load, e.g., signaling * (n - = 1). > > > > 1.2 bidirectional tunnels are established between the MN and its > > mobility > > > anchors. > > > > 1.3 tunneling overhead over the air is present. > > > > 1.4 but the tunnels are terminated at the MN so that the MN has > > control > > > over the tunnels. > > > > > > > > 2) "MN sends mobility signaling only to its serving mobility > > anchor" causes: > > > > 2.1 reduced mobility signaling load, e.g., signaling * 1. > > > > 2.2 bidirectional tunnels are established between the serving > > mobility > > > anchors and origin mobility anchors. > > > > 2.3 tunneling overhead over the air can be avoided. > > > > 2.4 but the MN does not have control over the tunnels so it = might > > affect to > > > NEtwork MObility (NEMO) as the MN (i.e., MR in NEMO) loses the > > tunneling > > > control. > > > > > > > > =3D=3D=3D 3. Neighbor mobility anchors' information in a DMM > environment. > > > > =3D=3D=3D In the client-based mobility solution such as MIPv6, = the > > network > > > topology information does not required to be known to the mobility > > anchor, > > > i.e., home agent (HA), since the HA is informed the current > location > > of the > > > MN. As the HA knows the current location of the MN, it is able to > > tunnel > > > packets associated to the MN. In the network-based mobility > solution > > such > > > as PMIPv6, the similar things happen, i.e., the tunnel between the > > local > > > mobility anchor (LMA) and the mobile access gateway (MAG) is > > established > > > for a given MN. > > > > > > > > However, as mobility anchors are distributed and bidirectional > > tunnels (for > > > a given MN) between the distributed mobility anchors are required, > > the > > > neighbor mobility anchors' information should be provided to the = MN > > or the > > > mobility anchor for the establishment of the directional tunnels = or > > the > > > update of the MN's current location. > > > > > > > > Decoupling the data plane and control plane while keeping a > > centralized > > > node maintaining the mobility context including neighbor mobility > > anchors' > > > information (e.g., identification, IP address, etc) in a DMM > > environment is > > > one of possible solutions. > > > > > > > > =3D=3D=3D 4. Comment on an establishment of security = associations in a > > DMM > > > > environment. =3D=3D=3D For each IP mobility support protocol, = different > > security > > > associations (SAs) are required for providing secure mobility > > services to MNs > > > as follows: > > > > > > > > 1) MIPv6 > > > > 1.1 SA between MN and HA. > > > > 1.2 SA between MN and serving access router (AR) providing > wireless > > link > > > to the MN. > > > > > > > > 2) Fast Handover MIPv6 (FMIPv6) > > > > 2.1 SA between MN and HA. > > > > 2.2 SA between MN and serving AR. > > > > 2.3 SA between previous and new ARs. > > > > > > > > 3) PMIPv6 > > > > 3.1 SA between MN and serving MAG. > > > > 3.2 SA between serving MAG and LMA. > > > > > > > > 4) Fast Handover PMIPv6 (FPMIPv6) > > > > 4.1 SA between MN and serving MAG. > > > > 4.2 SA between serving MAG and LMA. > > > > 4.3 SA between previous and new MAGs. > > > > > > > > Note that the above ones do not consider the cases of SA with a > > security- > > > backend server (e.g., AAA server) and with a correspondent node > (CN). > > > > > > > > However, depending on DMM solutions, SAs are configured that are > > > > different from those of the existing IP mobility support > protocols. > > > > For instance, > > > > > > > > 1) the case of "MN sends mobility signaling to its all mobility > > > > anchors" (client-based mobility solution) > > > > 1.1 SA between MN and serving mobility anchor providing wireless > > link to > > > the MN. > > > > 1.2 SA between MN and origin mobility anchors, i.e., (n - 1) SAs > > required > > > with MN and origin mobility anchors. > > > > > > > > 2) the case of "MN sends mobility signaling only to its serving > > > > mobility anchor" (client-based mobility solution) > > > > 2.1 SA between MN and serving mobility anchor. > > > > 2.2 SA between serving mobility anchor and origin mobility > anchors, > > i.e., (n > > > - 1) SAs required with serving mobility anchor and origin mobility > > anchors. > > > > > > > > 3) the case of "serving mobility anchor sends signaling on = behalf > > of > > > > the MN to origin mobility anchors" (network-based mobility > > solution) > > > > 3.1 SA between MN and serving mobility anchor. > > > > 3.2 SA between serving mobility anchor and origin mobility > anchors, > > i.e., (n > > > - 1) SAs required with serving mobility anchor and origin mobility > > anchors. > > > > > > > > Note that as like before SAs with a security-backend server > (e.g., > > AAA > > > server) and with a CN are not presented. > > > > > > > > As shown above, DMM solutions (that relies on bidirectional > > tunnelings for > > > packet forwarding between MN and mobility anchors or between just > > > mobility anchors) might bring the key management issues to > establish > > such > > > SAs. > > > > > > > > Since it's a holiday season, I cannot fully address all of them > in > > my mind, but > > > kindly consider these ones. > > > > > > > > Cheers. > > > > > > > > -- > > > > 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/ > > > > > > > > _______________________________________________ > > > > 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 > = _______________________________________________________________________ > __________________________________________________ >=20 > Ce message et ses pieces jointes peuvent contenir des informations > confidentielles ou privilegiees et ne doivent donc > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez > recu ce message par erreur, veuillez le signaler > a l'expediteur et le detruire ainsi que les pieces jointes. Les > messages electroniques etant susceptibles d'alteration, > France Telecom - Orange decline toute responsabilite si ce message a > ete altere, deforme ou falsifie. Merci. >=20 > This message and its attachments may contain confidential or = privileged > information that may be protected by law; > they should not be distributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and > delete this message and its attachments. > As emails may be altered, France Telecom - Orange is not liable for > messages that have been modified, changed or falsified. > Thank you. From Peter.McCann@huawei.com Wed Sep 19 12:55: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 386E221E8064 for ; Wed, 19 Sep 2012 12:55:21 -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=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iXbYODXBUQ6z for ; Wed, 19 Sep 2012 12:55:19 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 2334821E8034 for ; Wed, 19 Sep 2012 12:55:17 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id AJV32223; Wed, 19 Sep 2012 19:55:17 +0000 (GMT) Received: from LHREML403-HUB.china.huawei.com (10.201.5.217) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 19 Sep 2012 20:53:54 +0100 Received: from DFWEML403-HUB.china.huawei.com (10.193.5.151) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 19 Sep 2012 20:54:24 +0100 Received: from dfweml512-mbx.china.huawei.com ([169.254.1.151]) by dfweml403-hub.china.huawei.com ([10.193.5.151]) with mapi id 14.01.0323.003; Wed, 19 Sep 2012 12:54:16 -0700 From: Peter McCann To: "Zuniga, Juan Carlos" , "pierrick.seite@orange.com" , "karagian@cs.utwente.nl" , "jouni.nospam@gmail.com" , "dmm@ietf.org" , h chan Thread-Topic: [DMM] Comments on DMM Gap Analysis. Thread-Index: AQHNa/bmXcpjTD/9QkmtNxNtqHDjdJeRf28AgAA2BYCAAEDBoIAAZGOQgAAOQCA= Date: Wed, 19 Sep 2012 19:54:16 +0000 Message-ID: <5963DDF1F751474D8DEEFDCDBEE43AE716E2C073@dfweml512-mbx.china.huawei.com> References: <13040_1348059786_5059C28A_13040_17047_1_81C77F07008CA24F9783A98CFD706F71038847@PEXCVZYM12.corporate.adroot.infra.ftgroup> 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.212.244.252] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "dmm-chairs@tools.ietf.org" Subject: Re: [DMM] Comments on DMM Gap Analysis. 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, 19 Sep 2012 19:55:21 -0000 Maybe the document should be entitled "Existing IP Mobility Practices and DMM Gap Analysis." I am not sure there are any "DMM Practices" currently. -Pete Zuniga, Juan Carlos wrote: > Hi Pierrick, all, >=20 > The document title is "DMM Practices and Gap Analysis", and the > intention is to address both. When we presented at the meeting it I > made it clear that we wanted to show our approach to the problem, > which was first to agree on what are the "current practices" that we > want to consider, and then provide a "gap analysis" wrt the DMM > requirements document. >=20 > We are currently working on a new version of the document taking into > account the feedback we got at the meeting and on the ML. We will > provide more details about the current practices and will take a stab > at the gap analysis for discussion. >=20 > Cheers, >=20 > Juan Carlos >=20 >> -----Original Message----- >> From: pierrick.seite@orange.com [mailto:pierrick.seite@orange.com] >> Sent: Wednesday, September 19, 2012 9:03 AM >> To: 'karagian@cs.utwente.nl'; jouni.nospam@gmail.com; dmm@ietf.org; >> h.anthony.chan@huawei.com; Zuniga, Juan Carlos >> Cc: dmm-chairs@tools.ietf.org >> Subject: RE: [DMM] Comments on DMM Gap Analysis. >>=20 >> Hi Jouni and Julien, >>=20 >>=20 >> Sorry for jumping into the discussion but I'm a little bit confused >> with recent discussions in DMM. So, let me ask for clarifications >> about the scope of the gap analysis... >>=20 >> The WG is now tackling with the work item 'Practices and Gap Analysis' >> and, in my understanding, we are expected to provide a gap analysis >> regarding the use of mobility protocols in a distributed mobility >> management environment. However, it seems that the scope of discussions >> on gap analysis is different.... and I'm confused :-) >>=20 >> Actually, in the charter, we agreed to firstly "document practices for >> the deployment of existing mobility protocols in a distributed mobility >> management environment" and, then, to make the gap analysis. However, >> considering current discussions on "gap analysis": the document on >> practices has been omitted and discussions are about vanilla mobility >> protocols and architectures with respect to DMM requirements. So, >> maybe, such considerations are interesting in the scope of the problem >> statement, but it seems to me that it is not the goal of the gap >> analysis, as initially intended in the charter. Am I missing something? >>=20 >> If I refer to previous DMM charter (because current DMM charter is >> empty... BTW, is there a reason for an empty charter?), one Work >> item >> was: "Document practices for the deployment of existing mobility >> protocols in a distributed mobility management environment". Is >> this document still in DMM stuff? If yes, shouldn't we document >> practices before going into the gap analysis? >>=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: mercredi 19 septembre 2012 13:11 =C0=A0: jouni.nospam@gmai= l.com; >>> dmm@ietf.org; h.anthony.chan@huawei.com; >>> JuanCarlos.Zuniga@interdigital.com Cc=A0: dmm-chairs@tools.ietf.org >>> Objet=A0: Re: [DMM] Comments on DMM Gap Analysis. >>>=20 >>> Hi Jouni, Hi all, >>>=20 >>> After discussing this issue with Carlos Jes=FAs Bernardos and Juan >>> Carlos Zuniga, we concluded that the following set of possible >>> technologies could be included in the Gap analysis draft: >>>=20 >>> =3D> Shim6: Level 3 Multihoming Shim Protocol for IPv6 http://www.rfc- >>> editor.org/rfc/rfc5533.txt >>>=20 >>>=20 >>> =3D> LISP Mobile Node >>> http://www.ietf.org/id/draft-meyer-lisp-mn-07.txt >>> Locator/ID Separation Protocol (LISP) >>> http://www.ietf.org/id/draft-ietf-lisp-23.txt >>>=20 >>> =3D> Mobile IPv6 Fast Handovers >>> http://tools.ietf.org/id/draft-ietf-mipshop-rfc5268bis-01.txt This is >>> the draft that became then RFC5568, so no need to mention it. >>> http://www.rfc-editor.org/rfc/rfc5568.txt >>>=20 >>>=20 >>> =3D> Fast Handovers for Proxy Mobile IPv6 >>> http://www.rfc-editor.org/rfc/rfc5949.txt >>>=20 >>> =3D> Host Identity Protocol >>> http://www.rfc-editor.org/rfc/rfc4423.txt >>> http://www.rfc-editor.org/rfc/rfc5201.txt >>> http://www.rfc-editor.org/rfc/rfc6253.txt >>> http://www.rfc-editor.org/rfc/rfc5206.txt >>>=20 >>>=20 >>>=20 >>> =3D> IKEv2 Mobility and Multihoming Protocol (MOBIKE) >>> http://www.rfc-editor.org/rfc/rfc4555.txt >>>=20 >>>=20 >>> =3D> GTPv2-C: 3rd Generation Partnership Project; Technical >>> Specification Group Core Network and Terminals; 3GPP Evolved Packet >>> System (EPS); Evolved General Packet Radio Service (GPRS) Tunnelling >>> Protocol for Control plane (GTPv2-C); Stage 3 (Release 11) >>> http://www.3gpp.org/ftp/Specs/archive/29_series/29.274/29274- b30.zip >>>=20 >>> Please inform us if this list makes sense to you? >>>=20 >>> Best regards, >>> Georgios >>>=20 >>>=20 >>>> -----Original Message----- >>>> From: dmm-bounces@ietf.org [mailto:dmm-bounces@ietf.org] On > Behalf >> Of >>>> jouni korhonen >>>> Sent: woensdag 19 september 2012 9:58 >>>> To: dmm@ietf.org; h chan; Juan Carlos Zuniga >>>> Cc: dmm-chairs@tools.ietf.org >>>> Subject: Re: [DMM] Comments on DMM Gap Analysis. >>>>=20 >>>>=20 >>>> Folks, >>>>=20 >>>> It has been rather silent on the list recently. Regarding the >>>> "explosion" of possible technologies in the GAP analysis, we >>>> discussed (chairs) >> that >>> it is >>>> better to scope the area "a bit". The charter today has the >>>> assumption that we build on top of existing _IP_ _Mobility_ protocols >>>> (and bunch of IETF defined examples follow). So, to tighten the >>>> scope, the Gap >> Analysis >>> should >>>> leave all routing, session (SIP, ..), transport (MPTCP, SCTP, >> DCCP, >>> ..), >>>> locator/identifier split (HIP, Lisp, ..), naming (DNS tricks, >>>> ..) >> etc >>> based >>>> solutions out. Coarse but should help us to make progress. We could >>>> discuss whether transport layer solution like SCTP fit in but I do not > see >>> them as end- >>>> 2-end solutions being deployable in Internet at the moment. >>>>=20 >>>> Let us stick with technologies out there that have/had a place > in >>> sun: few >>>> MIP variants, MOBIKE, stuff in 3GPP(2) (oops.. but I think this >>>> deserves to be evaluated since they are somewhat popular), and what >>>> applications do (reconnecting..). This analysis should be down to >>>> earth practical >> and >>> realistic >>>> on what is already out there to play with. >>>>=20 >>>> - Jouni & Julien >>>>=20 >>>>=20 >>>>=20 >>>> On Jul 27, 2012, at 3:53 PM, Jong-Hyouk Lee wrote: >>>>=20 >>>>> Dear Anthony and Juan. >>>>>=20 >>>>> I enjoyed the both gap analysis documents (draft-chan-dmm- >>> framework- >>>> gap-analysis-02 and draft-zuniga-dmm-gap-analysis-01). Here I > give >>> some >>>> comments that should be used directly in the gap analysis documents >>>> if you guys like. >>>>>=20 >>>>> Kindly consider the followings during the gap analysis >>>>> discussion >>> (since I will >>>> not be attending the IETF meeting this time). >>>>>=20 >>>>> 1. Comment on address (resource) management in a DMM environment. 2. >>>>> Comment on a deployment of a client-based mobility solution >>> (i.e., >>>> MIPv6) in a DMM environment. >>>>> 3. Commnet on neighbor mobility anchors' information in a DMM >>>>> environment. 4. Commnet on an establishment of security associations >>>>> in a > DMM >>>> environment. >>>>>=20 >>>>> =3D=3D=3D 1. Comment on address (resource) management in a DMM >>>>> environment. =3D=3D=3D When existing IP mobility support protocols (e= .g., >>>>> MIPv6 > and >>> PMIPv6) >>>> are considered to be deployed in a DMM environment, a mobile node >>>> (MN) is allowed to configure a new address while keeping its previous >>>> address(es). It introduces the following differences with the address >>>> (resource) management of the existing ones: >>>>>=20 >>>>> MN's address configured at the interface with a DMM > environment: >> n >>> =3D >>>>> (IP address at the current access network + previously configured IP >>>>> address(es) with ongoing sessions) MN's address configured at the >>>>> interface without a DMM environment: 1 =3D (care-of address > in >> MIPv6 >>> or >>>>> MN's home address in PMIPv6) >>>>>=20 >>>>> This leads a couple of considerations we didn't have with the >>>>> existing IP mobility support protocols. For instance, >>>>>=20 >>>>> 1) MN's address management: use of a newly configured address > at >>> the >>>> current access network for new communication sessions while a proper >>>> address selection for previously established ongoing communication >>>> sessions. >>>>>=20 >>>>> 2) Additional treatment for ingress filtering: Ingress > filtering >> is >>> widely used >>>> against source address spoofing. The source addresses > (especially, >>> the >>>> network prefix part) of incoming packets are strictly checked to >> make >>> sure >>>> that those packets are actually from the network that they claim to >>>> be from. As the MN are allowed to send data packets with the >>>> previously configured address(es) at the new access network, those >>>> data packets would > be >>> filtered >>>> at the ingress filtering place because the source address of > those >>> data >>>> packets is not belonging to the new access network. Accordingly, >>>> an additional treatment for ingress filtering is required. >>>>>=20 >>>>> 3) MN's address increase at the MN's interface: Recall the >>>>> number >>> of MN's >>>> address configured at an interface is n. Then, n is increased, >>>> as >> the >>> MN >>>> changes its point of attachment while keeping its ongoing >>>> communication sessions. It brings the question: "How many addresses >>>> are currently possible to be configured at an interface?" >>>>>=20 >>>>> 4) Routing entry increase at the serving mobility anchor: Let >>>>> the >>> serving >>>> mobility anchor is the mobility anchor serves the MN. Traffic >>>> associated to the MN travels via the serving mobility anchor. The >>>> increase of the addresses associated to the MN, n, is not only >>>> concerning to the MN, but also concerning the serving mobility anchor >>>> as it contributes the >> increase >>> of >>>> routing entries for the MN. >>>>>=20 >>>>> =3D=3D=3D 2. Comment on a deployment of a client-based mobility solut= ion >>>>> (i.e., MIPv6) in a DMM environment. =3D=3D=3D When a client-based >>> mobility >>>> solution (i.e., MIPv6) is consiered to be deployed in a DMM >>>> environment, an MN is involved in mobility signaling such as Binding >>>> Update and Acknowledgement messages. This is the big difference with >>>> the network- based mobility solution (i.e., PMIPv6). As the MN send >>>> signaling to inform its movement to its mobility anchor, the >>>> client-based mobility solution allows the MN to supply client-centric >>>> decision for mobility management. >>>>>=20 >>>>> Suppose that the origin mobility anchor is the mobility anchor >>> where the >>>> MN has configured its IP address and established ongoing >>>> communication sessions with the IP address. The number of origin >>>> mobility anchors are n - 1. Recall that the serving mobility anchor >>>> is the mobility anchor >> where >>> the MN is >>>> being served by. Then, the MN's involvement in mobility signaling >>>> brings us the questions: "Should we let the MN send mobilty signaling >>>> to > its >>> all mobility >>>> anchors?" or "Would it make sense that the MN only sends mobility >>>> signaling to its serving mobility anchor?" Depending on the choice, >>>> we will have different results: >>>>>=20 >>>>> 1) "MN sends mobility signaling to its all mobility anchors" causes: >>>>> 1.1 increased mobility signaling load, e.g., signaling * (n - 1). >>>>> 1.2 bidirectional tunnels are established between the MN and > its >>> mobility >>>> anchors. >>>>> 1.3 tunneling overhead over the air is present. >>>>> 1.4 but the tunnels are terminated at the MN so that the MN >>>>> has >>> control >>>> over the tunnels. >>>>>=20 >>>>> 2) "MN sends mobility signaling only to its serving mobility anchor" >>>>> causes: 2.1 reduced mobility signaling load, e.g., signaling * 1. >>>>> 2.2 bidirectional tunnels are established between the serving >>> mobility >>>> anchors and origin mobility anchors. >>>>> 2.3 tunneling overhead over the air can be avoided. >>>>> 2.4 but the MN does not have control over the tunnels so it >>>>> might >>> affect to >>>> NEtwork MObility (NEMO) as the MN (i.e., MR in NEMO) loses the >>>> tunneling control. >>>>>=20 >>>>> =3D=3D=3D 3. Neighbor mobility anchors' information in a DMM environm= ent. >>>>> =3D=3D=3D In the client-based mobility solution such as MIPv6, the >>> network >>>> topology information does not required to be known to the > mobility >>> anchor, >>>> i.e., home agent (HA), since the HA is informed the current >> location >>> of the >>>> MN. As the HA knows the current location of the MN, it is able to >>>> tunnel packets associated to the MN. In the network-based mobility >> solution >>> such >>>> as PMIPv6, the similar things happen, i.e., the tunnel between > the >>> local >>>> mobility anchor (LMA) and the mobile access gateway (MAG) is >>>> established for a given MN. >>>>>=20 >>>>> However, as mobility anchors are distributed and bidirectional >>> tunnels (for >>>> a given MN) between the distributed mobility anchors are > required, >>> the >>>> neighbor mobility anchors' information should be provided to the MN >>>> or the mobility anchor for the establishment of the directional >>>> tunnels or the update of the MN's current location. >>>>>=20 >>>>> Decoupling the data plane and control plane while keeping a >>> centralized >>>> node maintaining the mobility context including neighbor mobility >>>> anchors' information (e.g., identification, IP address, etc) in a DMM >>>> environment is one of possible solutions. >>>>>=20 >>>>> =3D=3D=3D 4. Comment on an establishment of security associations in > a >>> DMM >>>>> environment. =3D=3D=3D For each IP mobility support protocol, >>>>> different >>> security >>>> associations (SAs) are required for providing secure mobility >>>> services to MNs as follows: >>>>>=20 >>>>> 1) MIPv6 >>>>> 1.1 SA between MN and HA. >>>>> 1.2 SA between MN and serving access router (AR) providing >> wireless >>> link >>>> to the MN. >>>>>=20 >>>>> 2) Fast Handover MIPv6 (FMIPv6) >>>>> 2.1 SA between MN and HA. >>>>> 2.2 SA between MN and serving AR. >>>>> 2.3 SA between previous and new ARs. >>>>>=20 >>>>> 3) PMIPv6 >>>>> 3.1 SA between MN and serving MAG. >>>>> 3.2 SA between serving MAG and LMA. >>>>>=20 >>>>> 4) Fast Handover PMIPv6 (FPMIPv6) >>>>> 4.1 SA between MN and serving MAG. >>>>> 4.2 SA between serving MAG and LMA. >>>>> 4.3 SA between previous and new MAGs. >>>>>=20 >>>>> Note that the above ones do not consider the cases of SA with >>>>> a >>> security- >>>> backend server (e.g., AAA server) and with a correspondent node >> (CN). >>>>>=20 >>>>> However, depending on DMM solutions, SAs are configured that are >>>>> different from those of the existing IP mobility support protocols. >>>>> For instance, >>>>>=20 >>>>> 1) the case of "MN sends mobility signaling to its all >>>>> mobility anchors" (client-based mobility solution) >>>>> 1.1 SA between MN and serving mobility anchor providing > wireless >>> link to >>>> the MN. >>>>> 1.2 SA between MN and origin mobility anchors, i.e., (n - 1) > SAs >>> required >>>> with MN and origin mobility anchors. >>>>>=20 >>>>> 2) the case of "MN sends mobility signaling only to its >>>>> serving mobility anchor" (client-based mobility solution) >>>>> 2.1 SA between MN and serving mobility anchor. >>>>> 2.2 SA between serving mobility anchor and origin mobility >> anchors, >>> i.e., (n >>>> - 1) SAs required with serving mobility anchor and origin > mobility >>> anchors. >>>>>=20 >>>>> 3) the case of "serving mobility anchor sends signaling on behalf of >>>>> the MN to origin mobility anchors" (network-based mobility solution) >>>>> 3.1 SA between MN and serving mobility anchor. 3.2 SA between >>>>> serving mobility anchor and origin mobility >> anchors, >>> i.e., (n >>>> - 1) SAs required with serving mobility anchor and origin > mobility >>> anchors. >>>>>=20 >>>>> Note that as like before SAs with a security-backend server >> (e.g., >>> AAA >>>> server) and with a CN are not presented. >>>>>=20 >>>>> As shown above, DMM solutions (that relies on bidirectional >>> tunnelings for >>>> packet forwarding between MN and mobility anchors or between >>>> just mobility anchors) might bring the key management issues to >> establish >>> such >>>> SAs. >>>>>=20 >>>>> Since it's a holiday season, I cannot fully address all of >>>>> them >> in >>> my mind, but >>>> kindly consider these ones. >>>>>=20 >>>>> Cheers. >>>>>=20 >>>>> -- >>>>> RSM Department, TELECOM Bretagne, France Jong-Hyouk Lee, >>>>> living somewhere between /dev/null and /dev/random >>>>>=20 >>>>> #email: jonghyouk (at) gmail (dot) com >>>>> #webpage: http://sites.google.com/site/hurryon/ >>>>>=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 >>> _______________________________________________ >>> dmm mailing list >>> dmm@ietf.org >>> https://www.ietf.org/mailman/listinfo/dmm >>=20 >>=20 >> ______________________________________________________________________ >> _ __________________________________________________ >>=20 >> Ce message et ses pieces jointes peuvent contenir des informations >> confidentielles ou privilegiees et ne doivent donc pas etre >> diffuses, exploites ou copies sans autorisation. Si vous avez recu >> ce message par erreur, veuillez le signaler a l'expediteur et le >> detruire ainsi que les pieces jointes. Les messages electroniques >> etant susceptibles d'alteration, France Telecom - Orange decline >> toute responsabilite si ce message a ete altere, deforme ou falsifie. Me= rci. >>=20 >> This message and its attachments may contain confidential or privileged >> information that may be protected by law; they should not be >> distributed, used or copied without authorisation. If you have received >> this email in error, please notify the sender and delete this message >> and its attachments. As emails may be altered, France Telecom - Orange >> is not liable for messages that have been modified, changed or >> falsified. Thank you. >=20 > _______________________________________________ > dmm mailing list > dmm@ietf.org > https://www.ietf.org/mailman/listinfo/dmm From JuanCarlos.Zuniga@InterDigital.com Wed Sep 19 13:55:16 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 42CBB21E8045 for ; Wed, 19 Sep 2012 13:55:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I68eTjUy82Q4 for ; Wed, 19 Sep 2012 13:55:14 -0700 (PDT) Received: from idcout.InterDigital.com (smtp-out1.interdigital.com [64.208.228.135]) by ietfa.amsl.com (Postfix) with ESMTP id 3E42021E8034 for ; Wed, 19 Sep 2012 13:55:14 -0700 (PDT) Received: from SAM.InterDigital.com ([10.30.2.11]) by idcout.InterDigital.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 19 Sep 2012 16:55:13 -0400 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: Wed, 19 Sep 2012 16:55:11 -0400 Message-ID: In-Reply-To: <5963DDF1F751474D8DEEFDCDBEE43AE716E2C073@dfweml512-mbx.china.huawei.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [DMM] Comments on DMM Gap Analysis. Thread-Index: AQHNa/bmXcpjTD/9QkmtNxNtqHDjdJeRf28AgAA2BYCAAEDBoIAAZGOQgAAOQCCAABCEUA== References: <13040_1348059786_5059C28A_13040_17047_1_81C77F07008CA24F9783A98CFD706F71038847@PEXCVZYM12.corporate.adroot.infra.ftgroup> <5963DDF1F751474D8DEEFDCDBEE43AE716E2C073@dfweml512-mbx.china.huawei.com> From: "Zuniga, Juan Carlos" To: "Peter McCann" , , , , , "h chan" X-OriginalArrivalTime: 19 Sep 2012 20:55:13.0384 (UTC) FILETIME=[107C6680:01CD96A9] Cc: dmm-chairs@tools.ietf.org Subject: Re: [DMM] Comments on DMM Gap Analysis. 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, 19 Sep 2012 20:55:16 -0000 Good point Pete, although I'm not sure the title can fit... We'll look = for an alternative to reflect the actual content. Thanks, Juan Carlos > -----Original Message----- > From: Peter McCann [mailto:Peter.McCann@huawei.com] > Sent: Wednesday, September 19, 2012 3:54 PM > To: Zuniga, Juan Carlos; pierrick.seite@orange.com; > karagian@cs.utwente.nl; jouni.nospam@gmail.com; dmm@ietf.org; h chan > Cc: dmm-chairs@tools.ietf.org > Subject: RE: [DMM] Comments on DMM Gap Analysis. >=20 > Maybe the document should be entitled "Existing IP Mobility Practices > and DMM Gap Analysis." I am not sure there are any "DMM Practices" > currently. >=20 > -Pete >=20 > Zuniga, Juan Carlos wrote: > > Hi Pierrick, all, > > > > The document title is "DMM Practices and Gap Analysis", and the > > intention is to address both. When we presented at the meeting it I > > made it clear that we wanted to show our approach to the problem, > > which was first to agree on what are the "current practices" that we > > want to consider, and then provide a "gap analysis" wrt the DMM > > requirements document. > > > > We are currently working on a new version of the document taking = into > > account the feedback we got at the meeting and on the ML. We will > > provide more details about the current practices and will take a = stab > > at the gap analysis for discussion. > > > > Cheers, > > > > Juan Carlos > > > >> -----Original Message----- > >> From: pierrick.seite@orange.com [mailto:pierrick.seite@orange.com] > >> Sent: Wednesday, September 19, 2012 9:03 AM > >> To: 'karagian@cs.utwente.nl'; jouni.nospam@gmail.com; dmm@ietf.org; > >> h.anthony.chan@huawei.com; Zuniga, Juan Carlos > >> Cc: dmm-chairs@tools.ietf.org > >> Subject: RE: [DMM] Comments on DMM Gap Analysis. > >> > >> Hi Jouni and Julien, > >> > >> > >> Sorry for jumping into the discussion but I'm a little bit confused > >> with recent discussions in DMM. So, let me ask for clarifications > >> about the scope of the gap analysis... > >> > >> The WG is now tackling with the work item 'Practices and Gap > Analysis' > >> and, in my understanding, we are expected to provide a gap analysis > >> regarding the use of mobility protocols in a distributed mobility > >> management environment. However, it seems that the scope of > discussions > >> on gap analysis is different.... and I'm confused :-) > >> > >> Actually, in the charter, we agreed to firstly "document practices > for > >> the deployment of existing mobility protocols in a distributed > mobility > >> management environment" and, then, to make the gap analysis. > However, > >> considering current discussions on "gap analysis": the document on > >> practices has been omitted and discussions are about vanilla > mobility > >> protocols and architectures with respect to DMM requirements. So, > >> maybe, such considerations are interesting in the scope of the > problem > >> statement, but it seems to me that it is not the goal of the gap > >> analysis, as initially intended in the charter. Am I missing > something? > >> > >> If I refer to previous DMM charter (because current DMM charter is > >> empty... BTW, is there a reason for an empty charter?), one Work > >> item > >> was: "Document practices for the deployment of existing mobility > >> protocols in a distributed mobility management environment". Is > >> this document still in DMM stuff? If yes, shouldn't we document > >> practices before going into the gap analysis? > >> > >> 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: mercredi 19 septembre 2012 13:11 =C0=A0: > jouni.nospam@gmail.com; > >>> dmm@ietf.org; h.anthony.chan@huawei.com; > >>> JuanCarlos.Zuniga@interdigital.com Cc=A0: = dmm-chairs@tools.ietf.org > >>> Objet=A0: Re: [DMM] Comments on DMM Gap Analysis. > >>> > >>> Hi Jouni, Hi all, > >>> > >>> After discussing this issue with Carlos Jes=FAs Bernardos and Juan > >>> Carlos Zuniga, we concluded that the following set of possible > >>> technologies could be included in the Gap analysis draft: > >>> > >>> =3D> Shim6: Level 3 Multihoming Shim Protocol for IPv6 > http://www.rfc- > >>> editor.org/rfc/rfc5533.txt > >>> > >>> > >>> =3D> LISP Mobile Node > >>> http://www.ietf.org/id/draft-meyer-lisp-mn-07.txt > >>> Locator/ID Separation Protocol (LISP) > >>> http://www.ietf.org/id/draft-ietf-lisp-23.txt > >>> > >>> =3D> Mobile IPv6 Fast Handovers > >>> http://tools.ietf.org/id/draft-ietf-mipshop-rfc5268bis-01.txt This > is > >>> the draft that became then RFC5568, so no need to mention it. > >>> http://www.rfc-editor.org/rfc/rfc5568.txt > >>> > >>> > >>> =3D> Fast Handovers for Proxy Mobile IPv6 > >>> http://www.rfc-editor.org/rfc/rfc5949.txt > >>> > >>> =3D> Host Identity Protocol > >>> http://www.rfc-editor.org/rfc/rfc4423.txt > >>> http://www.rfc-editor.org/rfc/rfc5201.txt > >>> http://www.rfc-editor.org/rfc/rfc6253.txt > >>> http://www.rfc-editor.org/rfc/rfc5206.txt > >>> > >>> > >>> > >>> =3D> IKEv2 Mobility and Multihoming Protocol (MOBIKE) > >>> http://www.rfc-editor.org/rfc/rfc4555.txt > >>> > >>> > >>> =3D> GTPv2-C: 3rd Generation Partnership Project; Technical > >>> Specification Group Core Network and Terminals; 3GPP Evolved = Packet > >>> System (EPS); Evolved General Packet Radio Service (GPRS) > Tunnelling > >>> Protocol for Control plane (GTPv2-C); Stage 3 (Release 11) > >>> http://www.3gpp.org/ftp/Specs/archive/29_series/29.274/29274- > b30.zip > >>> > >>> Please inform us if this list makes sense to you? > >>> > >>> Best regards, > >>> Georgios > >>> > >>> > >>>> -----Original Message----- > >>>> From: dmm-bounces@ietf.org [mailto:dmm-bounces@ietf.org] On > > Behalf > >> Of > >>>> jouni korhonen > >>>> Sent: woensdag 19 september 2012 9:58 > >>>> To: dmm@ietf.org; h chan; Juan Carlos Zuniga > >>>> Cc: dmm-chairs@tools.ietf.org > >>>> Subject: Re: [DMM] Comments on DMM Gap Analysis. > >>>> > >>>> > >>>> Folks, > >>>> > >>>> It has been rather silent on the list recently. Regarding the > >>>> "explosion" of possible technologies in the GAP analysis, we > >>>> discussed (chairs) > >> that > >>> it is > >>>> better to scope the area "a bit". The charter today has the > >>>> assumption that we build on top of existing _IP_ _Mobility_ > protocols > >>>> (and bunch of IETF defined examples follow). So, to tighten the > >>>> scope, the Gap > >> Analysis > >>> should > >>>> leave all routing, session (SIP, ..), transport (MPTCP, SCTP, > >> DCCP, > >>> ..), > >>>> locator/identifier split (HIP, Lisp, ..), naming (DNS tricks, > >>>> ..) > >> etc > >>> based > >>>> solutions out. Coarse but should help us to make progress. We > could > >>>> discuss whether transport layer solution like SCTP fit in but I = do > not > > see > >>> them as end- > >>>> 2-end solutions being deployable in Internet at the moment. > >>>> > >>>> Let us stick with technologies out there that have/had a place > > in > >>> sun: few > >>>> MIP variants, MOBIKE, stuff in 3GPP(2) (oops.. but I think this > >>>> deserves to be evaluated since they are somewhat popular), and > what > >>>> applications do (reconnecting..). This analysis should be down to > >>>> earth practical > >> and > >>> realistic > >>>> on what is already out there to play with. > >>>> > >>>> - Jouni & Julien > >>>> > >>>> > >>>> > >>>> On Jul 27, 2012, at 3:53 PM, Jong-Hyouk Lee wrote: > >>>> > >>>>> Dear Anthony and Juan. > >>>>> > >>>>> I enjoyed the both gap analysis documents (draft-chan-dmm- > >>> framework- > >>>> gap-analysis-02 and draft-zuniga-dmm-gap-analysis-01). Here I > > give > >>> some > >>>> comments that should be used directly in the gap analysis > documents > >>>> if you guys like. > >>>>> > >>>>> Kindly consider the followings during the gap analysis > >>>>> discussion > >>> (since I will > >>>> not be attending the IETF meeting this time). > >>>>> > >>>>> 1. Comment on address (resource) management in a DMM = environment. > 2. > >>>>> Comment on a deployment of a client-based mobility solution > >>> (i.e., > >>>> MIPv6) in a DMM environment. > >>>>> 3. Commnet on neighbor mobility anchors' information in a DMM > >>>>> environment. 4. Commnet on an establishment of security > associations > >>>>> in a > > DMM > >>>> environment. > >>>>> > >>>>> =3D=3D=3D 1. Comment on address (resource) management in a DMM > >>>>> environment. =3D=3D=3D When existing IP mobility support = protocols > (e.g., > >>>>> MIPv6 > > and > >>> PMIPv6) > >>>> are considered to be deployed in a DMM environment, a mobile node > >>>> (MN) is allowed to configure a new address while keeping its > previous > >>>> address(es). It introduces the following differences with the > address > >>>> (resource) management of the existing ones: > >>>>> > >>>>> MN's address configured at the interface with a DMM > > environment: > >> n > >>> =3D > >>>>> (IP address at the current access network + previously = configured > IP > >>>>> address(es) with ongoing sessions) MN's address configured at = the > >>>>> interface without a DMM environment: 1 =3D (care-of address > > in > >> MIPv6 > >>> or > >>>>> MN's home address in PMIPv6) > >>>>> > >>>>> This leads a couple of considerations we didn't have with the > >>>>> existing IP mobility support protocols. For instance, > >>>>> > >>>>> 1) MN's address management: use of a newly configured address > > at > >>> the > >>>> current access network for new communication sessions while a > proper > >>>> address selection for previously established ongoing = communication > >>>> sessions. > >>>>> > >>>>> 2) Additional treatment for ingress filtering: Ingress > > filtering > >> is > >>> widely used > >>>> against source address spoofing. The source addresses > > (especially, > >>> the > >>>> network prefix part) of incoming packets are strictly checked to > >> make > >>> sure > >>>> that those packets are actually from the network that they claim > to > >>>> be from. As the MN are allowed to send data packets with the > >>>> previously configured address(es) at the new access network, = those > >>>> data packets would > > be > >>> filtered > >>>> at the ingress filtering place because the source address of > > those > >>> data > >>>> packets is not belonging to the new access network. Accordingly, > >>>> an additional treatment for ingress filtering is required. > >>>>> > >>>>> 3) MN's address increase at the MN's interface: Recall the > >>>>> number > >>> of MN's > >>>> address configured at an interface is n. Then, n is increased, > >>>> as > >> the > >>> MN > >>>> changes its point of attachment while keeping its ongoing > >>>> communication sessions. It brings the question: "How many > addresses > >>>> are currently possible to be configured at an interface?" > >>>>> > >>>>> 4) Routing entry increase at the serving mobility anchor: Let > >>>>> the > >>> serving > >>>> mobility anchor is the mobility anchor serves the MN. Traffic > >>>> associated to the MN travels via the serving mobility anchor. The > >>>> increase of the addresses associated to the MN, n, is not only > >>>> concerning to the MN, but also concerning the serving mobility > anchor > >>>> as it contributes the > >> increase > >>> of > >>>> routing entries for the MN. > >>>>> > >>>>> =3D=3D=3D 2. Comment on a deployment of a client-based mobility > solution > >>>>> (i.e., MIPv6) in a DMM environment. =3D=3D=3D When a = client-based > >>> mobility > >>>> solution (i.e., MIPv6) is consiered to be deployed in a DMM > >>>> environment, an MN is involved in mobility signaling such as > Binding > >>>> Update and Acknowledgement messages. This is the big difference > with > >>>> the network- based mobility solution (i.e., PMIPv6). As the MN > send > >>>> signaling to inform its movement to its mobility anchor, the > >>>> client-based mobility solution allows the MN to supply client- > centric > >>>> decision for mobility management. > >>>>> > >>>>> Suppose that the origin mobility anchor is the mobility anchor > >>> where the > >>>> MN has configured its IP address and established ongoing > >>>> communication sessions with the IP address. The number of origin > >>>> mobility anchors are n - 1. Recall that the serving mobility > anchor > >>>> is the mobility anchor > >> where > >>> the MN is > >>>> being served by. Then, the MN's involvement in mobility signaling > >>>> brings us the questions: "Should we let the MN send mobilty > signaling > >>>> to > > its > >>> all mobility > >>>> anchors?" or "Would it make sense that the MN only sends mobility > >>>> signaling to its serving mobility anchor?" Depending on the > choice, > >>>> we will have different results: > >>>>> > >>>>> 1) "MN sends mobility signaling to its all mobility anchors" > causes: > >>>>> 1.1 increased mobility signaling load, e.g., signaling * (n - = 1). > >>>>> 1.2 bidirectional tunnels are established between the MN and > > its > >>> mobility > >>>> anchors. > >>>>> 1.3 tunneling overhead over the air is present. > >>>>> 1.4 but the tunnels are terminated at the MN so that the MN > >>>>> has > >>> control > >>>> over the tunnels. > >>>>> > >>>>> 2) "MN sends mobility signaling only to its serving mobility > anchor" > >>>>> causes: 2.1 reduced mobility signaling load, e.g., signaling * = 1. > >>>>> 2.2 bidirectional tunnels are established between the serving > >>> mobility > >>>> anchors and origin mobility anchors. > >>>>> 2.3 tunneling overhead over the air can be avoided. > >>>>> 2.4 but the MN does not have control over the tunnels so it > >>>>> might > >>> affect to > >>>> NEtwork MObility (NEMO) as the MN (i.e., MR in NEMO) loses the > >>>> tunneling control. > >>>>> > >>>>> =3D=3D=3D 3. Neighbor mobility anchors' information in a DMM > environment. > >>>>> =3D=3D=3D In the client-based mobility solution such as MIPv6, = the > >>> network > >>>> topology information does not required to be known to the > > mobility > >>> anchor, > >>>> i.e., home agent (HA), since the HA is informed the current > >> location > >>> of the > >>>> MN. As the HA knows the current location of the MN, it is able to > >>>> tunnel packets associated to the MN. In the network-based = mobility > >> solution > >>> such > >>>> as PMIPv6, the similar things happen, i.e., the tunnel between > > the > >>> local > >>>> mobility anchor (LMA) and the mobile access gateway (MAG) is > >>>> established for a given MN. > >>>>> > >>>>> However, as mobility anchors are distributed and bidirectional > >>> tunnels (for > >>>> a given MN) between the distributed mobility anchors are > > required, > >>> the > >>>> neighbor mobility anchors' information should be provided to the > MN > >>>> or the mobility anchor for the establishment of the directional > >>>> tunnels or the update of the MN's current location. > >>>>> > >>>>> Decoupling the data plane and control plane while keeping a > >>> centralized > >>>> node maintaining the mobility context including neighbor mobility > >>>> anchors' information (e.g., identification, IP address, etc) in a > DMM > >>>> environment is one of possible solutions. > >>>>> > >>>>> =3D=3D=3D 4. Comment on an establishment of security = associations in > > a > >>> DMM > >>>>> environment. =3D=3D=3D For each IP mobility support protocol, > >>>>> different > >>> security > >>>> associations (SAs) are required for providing secure mobility > >>>> services to MNs as follows: > >>>>> > >>>>> 1) MIPv6 > >>>>> 1.1 SA between MN and HA. > >>>>> 1.2 SA between MN and serving access router (AR) providing > >> wireless > >>> link > >>>> to the MN. > >>>>> > >>>>> 2) Fast Handover MIPv6 (FMIPv6) > >>>>> 2.1 SA between MN and HA. > >>>>> 2.2 SA between MN and serving AR. > >>>>> 2.3 SA between previous and new ARs. > >>>>> > >>>>> 3) PMIPv6 > >>>>> 3.1 SA between MN and serving MAG. > >>>>> 3.2 SA between serving MAG and LMA. > >>>>> > >>>>> 4) Fast Handover PMIPv6 (FPMIPv6) > >>>>> 4.1 SA between MN and serving MAG. > >>>>> 4.2 SA between serving MAG and LMA. > >>>>> 4.3 SA between previous and new MAGs. > >>>>> > >>>>> Note that the above ones do not consider the cases of SA with > >>>>> a > >>> security- > >>>> backend server (e.g., AAA server) and with a correspondent node > >> (CN). > >>>>> > >>>>> However, depending on DMM solutions, SAs are configured that are > >>>>> different from those of the existing IP mobility support > protocols. > >>>>> For instance, > >>>>> > >>>>> 1) the case of "MN sends mobility signaling to its all > >>>>> mobility anchors" (client-based mobility solution) > >>>>> 1.1 SA between MN and serving mobility anchor providing > > wireless > >>> link to > >>>> the MN. > >>>>> 1.2 SA between MN and origin mobility anchors, i.e., (n - 1) > > SAs > >>> required > >>>> with MN and origin mobility anchors. > >>>>> > >>>>> 2) the case of "MN sends mobility signaling only to its > >>>>> serving mobility anchor" (client-based mobility solution) > >>>>> 2.1 SA between MN and serving mobility anchor. > >>>>> 2.2 SA between serving mobility anchor and origin mobility > >> anchors, > >>> i.e., (n > >>>> - 1) SAs required with serving mobility anchor and origin > > mobility > >>> anchors. > >>>>> > >>>>> 3) the case of "serving mobility anchor sends signaling on = behalf > of > >>>>> the MN to origin mobility anchors" (network-based mobility > solution) > >>>>> 3.1 SA between MN and serving mobility anchor. 3.2 SA between > >>>>> serving mobility anchor and origin mobility > >> anchors, > >>> i.e., (n > >>>> - 1) SAs required with serving mobility anchor and origin > > mobility > >>> anchors. > >>>>> > >>>>> Note that as like before SAs with a security-backend server > >> (e.g., > >>> AAA > >>>> server) and with a CN are not presented. > >>>>> > >>>>> As shown above, DMM solutions (that relies on bidirectional > >>> tunnelings for > >>>> packet forwarding between MN and mobility anchors or between > >>>> just mobility anchors) might bring the key management issues to > >> establish > >>> such > >>>> SAs. > >>>>> > >>>>> Since it's a holiday season, I cannot fully address all of > >>>>> them > >> in > >>> my mind, but > >>>> kindly consider these ones. > >>>>> > >>>>> Cheers. > >>>>> > >>>>> -- > >>>>> 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/ > >>>>> > >>>>> _______________________________________________ > >>>>> 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 > >> > >> > >> > ______________________________________________________________________ > >> _ __________________________________________________ > >> > >> Ce message et ses pieces jointes peuvent contenir des informations > >> confidentielles ou privilegiees et ne doivent donc pas etre > >> diffuses, exploites ou copies sans autorisation. Si vous avez recu > >> ce message par erreur, veuillez le signaler a l'expediteur et le > >> detruire ainsi que les pieces jointes. Les messages electroniques > >> etant susceptibles d'alteration, France Telecom - Orange decline > >> toute responsabilite si ce message a ete altere, deforme ou > falsifie. Merci. > >> > >> This message and its attachments may contain confidential or > privileged > >> information that may be protected by law; they should not be > >> distributed, used or copied without authorisation. If you have > received > >> this email in error, please notify the sender and delete this > message > >> and its attachments. As emails may be altered, France Telecom - > Orange > >> is not liable for messages that have been modified, changed or > >> falsified. Thank you. > > > > _______________________________________________ > > dmm mailing list > > dmm@ietf.org > > https://www.ietf.org/mailman/listinfo/dmm >=20 >=20 From maxpassion@gmail.com Wed Sep 19 20:47:31 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 B7B4421E8037 for ; Wed, 19 Sep 2012 20:47:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Me42NHbz0xKg for ; Wed, 19 Sep 2012 20:47:29 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id A54A911E80A6 for ; Wed, 19 Sep 2012 20:47:29 -0700 (PDT) Received: by obbwc20 with SMTP id wc20so1891343obb.31 for ; Wed, 19 Sep 2012 20:47:29 -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:content-transfer-encoding; bh=Vv/8trVlpq0J5/LFtT7/XUukPk6X9pXVjDDSrE58MoI=; b=t3ep+PiJiD3O+obVC9lAXRr+cBKVUAb35BtN574kHzPeQ0Rgbyk3W271R9/20o6pjI Pkwve0CKSSsMx2H0GJ1sqYXTvzub6vCG4GMjL2KAM6dnKN3eaSD4Cm2FNHmeFZQoujhI ZuqfasB/wCH7vDPoKRSK3R7zZvDQ1acYha2KbReMm2Q9kLs4BOBkFonqIT+9oZQM4uqS hY7AjrVBzZI0DSkfn3HKlxmN/aCWjTWyDa/Uc8KOwlryXMGOlGxU88nuaqX5Fa/owjFL d8F9ZeYhs+fwdDFOyBX9SyhlCi5beupuInGZR75rdad2QkfSIbR4Yt3MnWoTtMXBbp8g JyvA== MIME-Version: 1.0 Received: by 10.60.1.135 with SMTP id 7mr346443oem.40.1348112849125; Wed, 19 Sep 2012 20:47:29 -0700 (PDT) Received: by 10.76.162.41 with HTTP; Wed, 19 Sep 2012 20:47:28 -0700 (PDT) In-Reply-To: <13040_1348059786_5059C28A_13040_17047_1_81C77F07008CA24F9783A98CFD706F71038847@PEXCVZYM12.corporate.adroot.infra.ftgroup> References: <13040_1348059786_5059C28A_13040_17047_1_81C77F07008CA24F9783A98CFD706F71038847@PEXCVZYM12.corporate.adroot.infra.ftgroup> Date: Thu, 20 Sep 2012 11:47:28 +0800 Message-ID: From: liu dapeng To: pierrick.seite@orange.com, "jouni.nospam" , Julien Laganier Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "dmm@ietf.org" , "dmm-chairs@tools.ietf.org" Subject: Re: [DMM] Comments on DMM Gap Analysis. 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, 20 Sep 2012 03:47:31 -0000 Hello All, I also have the similar thinking that we should first document and agree on the "practices for the deployment of existing mobility protocols in a distributed mobility management environment". After that, if we find that there indeed some "gap" existing, we can then move to "gap analysis". Best Regards, Dapeng 2012/9/19, pierrick.seite@orange.com : > Hi Jouni and Julien, > > > Sorry for jumping into the discussion but I'm a little bit confused with > recent discussions in DMM. So, let me ask for clarifications about the sc= ope > of the gap analysis... > > The WG is now tackling with the work item 'Practices and Gap Analysis' an= d, > in my understanding, we are expected to provide a gap analysis regarding = the > use of mobility protocols in a distributed mobility management environme= nt. > However, it seems that the scope of discussions on gap analysis is > different.... and I'm confused :-) > > Actually, in the charter, we agreed to firstly "document practices for th= e > deployment of existing mobility protocols in a distributed mobility > management environment" and, then, to make the gap analysis. However, > considering current discussions on "gap analysis": the document on practi= ces > has been omitted and discussions are about vanilla mobility protocols and > architectures with respect to DMM requirements. So, maybe, such > considerations are interesting in the scope of the problem statement, but= it > seems to me that it is not the goal of the gap analysis, as initially > intended in the charter. Am I missing something? > > If I refer to previous DMM charter (because current DMM charter is empty.= .. > BTW, is there a reason for an empty charter?), one Work item was: "Docume= nt > practices for the deployment of existing mobility protocols in a distribu= ted > mobility management environment". Is this document still in DMM stuff? I= f > yes, shouldn't we document practices before going into the gap analysis? > > 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 : mercredi 19 septembre 2012 13:11 >> =C0 : jouni.nospam@gmail.com; dmm@ietf.org; h.anthony.chan@huawei.com; >> JuanCarlos.Zuniga@interdigital.com >> Cc : dmm-chairs@tools.ietf.org >> Objet : Re: [DMM] Comments on DMM Gap Analysis. >> >> Hi Jouni, Hi all, >> >> After discussing this issue with Carlos Jes=FAs Bernardos and Juan Carlo= s >> Zuniga, we concluded that the following set of possible technologies >> could be included in the Gap analysis draft: >> >> =3D> Shim6: Level 3 Multihoming Shim Protocol for IPv6 http://www.rfc- >> editor.org/rfc/rfc5533.txt >> >> >> =3D> LISP Mobile Node >> http://www.ietf.org/id/draft-meyer-lisp-mn-07.txt >> Locator/ID Separation Protocol (LISP) >> http://www.ietf.org/id/draft-ietf-lisp-23.txt >> >> =3D> Mobile IPv6 Fast Handovers >> http://tools.ietf.org/id/draft-ietf-mipshop-rfc5268bis-01.txt >> This is the draft that became then RFC5568, so no need to mention it. >> http://www.rfc-editor.org/rfc/rfc5568.txt >> >> >> =3D> Fast Handovers for Proxy Mobile IPv6 >> http://www.rfc-editor.org/rfc/rfc5949.txt >> >> =3D> Host Identity Protocol >> http://www.rfc-editor.org/rfc/rfc4423.txt >> http://www.rfc-editor.org/rfc/rfc5201.txt >> http://www.rfc-editor.org/rfc/rfc6253.txt >> http://www.rfc-editor.org/rfc/rfc5206.txt >> >> >> >> =3D> IKEv2 Mobility and Multihoming Protocol (MOBIKE) >> http://www.rfc-editor.org/rfc/rfc4555.txt >> >> >> =3D> GTPv2-C: 3rd Generation Partnership Project; Technical Specificatio= n >> Group Core Network and Terminals; 3GPP Evolved Packet System (EPS); >> Evolved General Packet Radio Service (GPRS) Tunnelling Protocol for >> Control plane (GTPv2-C); Stage 3 (Release 11) >> http://www.3gpp.org/ftp/Specs/archive/29_series/29.274/29274-b30.zip >> >> Please inform us if this list makes sense to you? >> >> Best regards, >> Georgios >> >> >> > -----Original Message----- >> > From: dmm-bounces@ietf.org [mailto:dmm-bounces@ietf.org] On Behalf Of >> > jouni korhonen >> > Sent: woensdag 19 september 2012 9:58 >> > To: dmm@ietf.org; h chan; Juan Carlos Zuniga >> > Cc: dmm-chairs@tools.ietf.org >> > Subject: Re: [DMM] Comments on DMM Gap Analysis. >> > >> > >> > Folks, >> > >> > It has been rather silent on the list recently. Regarding the >> "explosion" of >> > possible technologies in the GAP analysis, we discussed (chairs) that >> it is >> > better to scope the area "a bit". The charter today has the >> assumption that >> > we build on top of existing _IP_ _Mobility_ protocols (and bunch of >> IETF >> > defined examples follow). So, to tighten the scope, the Gap Analysis >> should >> > leave all routing, session (SIP, ..), transport (MPTCP, SCTP, DCCP, >> ..), >> > locator/identifier split (HIP, Lisp, ..), naming (DNS tricks, ..) etc >> based >> > solutions out. Coarse but should help us to make progress. We could >> discuss >> > whether transport layer solution like SCTP fit in but I do not see >> them as end- >> > 2-end solutions being deployable in Internet at the moment. >> > >> > Let us stick with technologies out there that have/had a place in >> sun: few >> > MIP variants, MOBIKE, stuff in 3GPP(2) (oops.. but I think this >> deserves to be >> > evaluated since they are somewhat popular), and what applications do >> > (reconnecting..). This analysis should be down to earth practical and >> realistic >> > on what is already out there to play with. >> > >> > - Jouni & Julien >> > >> > >> > >> > On Jul 27, 2012, at 3:53 PM, Jong-Hyouk Lee wrote: >> > >> > > Dear Anthony and Juan. >> > > >> > > I enjoyed the both gap analysis documents (draft-chan-dmm- >> framework- >> > gap-analysis-02 and draft-zuniga-dmm-gap-analysis-01). Here I give >> some >> > comments that should be used directly in the gap analysis documents >> if you >> > guys like. >> > > >> > > Kindly consider the followings during the gap analysis discussion >> (since I will >> > not be attending the IETF meeting this time). >> > > >> > > 1. Comment on address (resource) management in a DMM environment. >> > > 2. Comment on a deployment of a client-based mobility solution >> (i.e., >> > MIPv6) in a DMM environment. >> > > 3. Commnet on neighbor mobility anchors' information in a DMM >> > environment. >> > > 4. Commnet on an establishment of security associations in a DMM >> > environment. >> > > >> > > =3D=3D=3D 1. Comment on address (resource) management in a DMM >> > environment. >> > > =3D=3D=3D When existing IP mobility support protocols (e.g., MIPv6 a= nd >> PMIPv6) >> > are considered to be deployed in a DMM environment, a mobile node >> (MN) >> > is allowed to configure a new address while keeping its previous >> address(es). >> > It introduces the following differences with the address (resource) >> > management of the existing ones: >> > > >> > > MN's address configured at the interface with a DMM environment: n >> =3D >> > > (IP address at the current access network + previously configured >> IP >> > > address(es) with ongoing sessions) MN's address configured at the >> > > interface without a DMM environment: 1 =3D (care-of address in MIPv6 >> or >> > > MN's home address in PMIPv6) >> > > >> > > This leads a couple of considerations we didn't have with the >> existing >> > > IP mobility support protocols. For instance, >> > > >> > > 1) MN's address management: use of a newly configured address at >> the >> > current access network for new communication sessions while a proper >> > address selection for previously established ongoing communication >> > sessions. >> > > >> > > 2) Additional treatment for ingress filtering: Ingress filtering is >> widely used >> > against source address spoofing. The source addresses (especially, >> the >> > network prefix part) of incoming packets are strictly checked to make >> sure >> > that those packets are actually from the network that they claim to >> be from. >> > As the MN are allowed to send data packets with the previously >> configured >> > address(es) at the new access network, those data packets would be >> filtered >> > at the ingress filtering place because the source address of those >> data >> > packets is not belonging to the new access network. Accordingly, an >> > additional treatment for ingress filtering is required. >> > > >> > > 3) MN's address increase at the MN's interface: Recall the number >> of MN's >> > address configured at an interface is n. Then, n is increased, as the >> MN >> > changes its point of attachment while keeping its ongoing >> communication >> > sessions. It brings the question: "How many addresses are currently >> possible >> > to be configured at an interface?" >> > > >> > > 4) Routing entry increase at the serving mobility anchor: Let the >> serving >> > mobility anchor is the mobility anchor serves the MN. Traffic >> associated to >> > the MN travels via the serving mobility anchor. The increase of the >> addresses >> > associated to the MN, n, is not only concerning to the MN, but also >> > concerning the serving mobility anchor as it contributes the increase >> of >> > routing entries for the MN. >> > > >> > > =3D=3D=3D 2. Comment on a deployment of a client-based mobility solu= tion >> > > (i.e., MIPv6) in a DMM environment. =3D=3D=3D When a client-based >> mobility >> > solution (i.e., MIPv6) is consiered to be deployed in a DMM >> environment, an >> > MN is involved in mobility signaling such as Binding Update and >> > Acknowledgement messages. This is the big difference with the >> network- >> > based mobility solution (i.e., PMIPv6). As the MN send signaling to >> inform its >> > movement to its mobility anchor, the client-based mobility solution >> allows >> > the MN to supply client-centric decision for mobility management. >> > > >> > > Suppose that the origin mobility anchor is the mobility anchor >> where the >> > MN has configured its IP address and established ongoing >> communication >> > sessions with the IP address. The number of origin mobility anchors >> are n - 1. >> > Recall that the serving mobility anchor is the mobility anchor where >> the MN is >> > being served by. Then, the MN's involvement in mobility signaling >> brings us >> > the questions: "Should we let the MN send mobilty signaling to its >> all mobility >> > anchors?" or "Would it make sense that the MN only sends mobility >> signaling >> > to its serving mobility anchor?" Depending on the choice, we will >> have >> > different results: >> > > >> > > 1) "MN sends mobility signaling to its all mobility anchors" >> causes: >> > > 1.1 increased mobility signaling load, e.g., signaling * (n - 1). >> > > 1.2 bidirectional tunnels are established between the MN and its >> mobility >> > anchors. >> > > 1.3 tunneling overhead over the air is present. >> > > 1.4 but the tunnels are terminated at the MN so that the MN has >> control >> > over the tunnels. >> > > >> > > 2) "MN sends mobility signaling only to its serving mobility >> anchor" causes: >> > > 2.1 reduced mobility signaling load, e.g., signaling * 1. >> > > 2.2 bidirectional tunnels are established between the serving >> mobility >> > anchors and origin mobility anchors. >> > > 2.3 tunneling overhead over the air can be avoided. >> > > 2.4 but the MN does not have control over the tunnels so it might >> affect to >> > NEtwork MObility (NEMO) as the MN (i.e., MR in NEMO) loses the >> tunneling >> > control. >> > > >> > > =3D=3D=3D 3. Neighbor mobility anchors' information in a DMM environ= ment. >> > > =3D=3D=3D In the client-based mobility solution such as MIPv6, the >> network >> > topology information does not required to be known to the mobility >> anchor, >> > i.e., home agent (HA), since the HA is informed the current location >> of the >> > MN. As the HA knows the current location of the MN, it is able to >> tunnel >> > packets associated to the MN. In the network-based mobility solution >> such >> > as PMIPv6, the similar things happen, i.e., the tunnel between the >> local >> > mobility anchor (LMA) and the mobile access gateway (MAG) is >> established >> > for a given MN. >> > > >> > > However, as mobility anchors are distributed and bidirectional >> tunnels (for >> > a given MN) between the distributed mobility anchors are required, >> the >> > neighbor mobility anchors' information should be provided to the MN >> or the >> > mobility anchor for the establishment of the directional tunnels or >> the >> > update of the MN's current location. >> > > >> > > Decoupling the data plane and control plane while keeping a >> centralized >> > node maintaining the mobility context including neighbor mobility >> anchors' >> > information (e.g., identification, IP address, etc) in a DMM >> environment is >> > one of possible solutions. >> > > >> > > =3D=3D=3D 4. Comment on an establishment of security associations in= a >> DMM >> > > environment. =3D=3D=3D For each IP mobility support protocol, differ= ent >> security >> > associations (SAs) are required for providing secure mobility >> services to MNs >> > as follows: >> > > >> > > 1) MIPv6 >> > > 1.1 SA between MN and HA. >> > > 1.2 SA between MN and serving access router (AR) providing wireless >> link >> > to the MN. >> > > >> > > 2) Fast Handover MIPv6 (FMIPv6) >> > > 2.1 SA between MN and HA. >> > > 2.2 SA between MN and serving AR. >> > > 2.3 SA between previous and new ARs. >> > > >> > > 3) PMIPv6 >> > > 3.1 SA between MN and serving MAG. >> > > 3.2 SA between serving MAG and LMA. >> > > >> > > 4) Fast Handover PMIPv6 (FPMIPv6) >> > > 4.1 SA between MN and serving MAG. >> > > 4.2 SA between serving MAG and LMA. >> > > 4.3 SA between previous and new MAGs. >> > > >> > > Note that the above ones do not consider the cases of SA with a >> security- >> > backend server (e.g., AAA server) and with a correspondent node (CN). >> > > >> > > However, depending on DMM solutions, SAs are configured that are >> > > different from those of the existing IP mobility support protocols. >> > > For instance, >> > > >> > > 1) the case of "MN sends mobility signaling to its all mobility >> > > anchors" (client-based mobility solution) >> > > 1.1 SA between MN and serving mobility anchor providing wireless >> link to >> > the MN. >> > > 1.2 SA between MN and origin mobility anchors, i.e., (n - 1) SAs >> required >> > with MN and origin mobility anchors. >> > > >> > > 2) the case of "MN sends mobility signaling only to its serving >> > > mobility anchor" (client-based mobility solution) >> > > 2.1 SA between MN and serving mobility anchor. >> > > 2.2 SA between serving mobility anchor and origin mobility anchors, >> i.e., (n >> > - 1) SAs required with serving mobility anchor and origin mobility >> anchors. >> > > >> > > 3) the case of "serving mobility anchor sends signaling on behalf >> of >> > > the MN to origin mobility anchors" (network-based mobility >> solution) >> > > 3.1 SA between MN and serving mobility anchor. >> > > 3.2 SA between serving mobility anchor and origin mobility anchors, >> i.e., (n >> > - 1) SAs required with serving mobility anchor and origin mobility >> anchors. >> > > >> > > Note that as like before SAs with a security-backend server (e.g., >> AAA >> > server) and with a CN are not presented. >> > > >> > > As shown above, DMM solutions (that relies on bidirectional >> tunnelings for >> > packet forwarding between MN and mobility anchors or between just >> > mobility anchors) might bring the key management issues to establish >> such >> > SAs. >> > > >> > > Since it's a holiday season, I cannot fully address all of them in >> my mind, but >> > kindly consider these ones. >> > > >> > > Cheers. >> > > >> > > -- >> > > 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/ >> > > >> > > _______________________________________________ >> > > 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 > > _________________________________________________________________________= ________________________________________________ > > Ce message et ses pieces jointes peuvent contenir des informations > confidentielles ou privilegiees et ne doivent donc > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez re= cu > ce message par erreur, veuillez le signaler > a l'expediteur et le detruire ainsi que les pieces jointes. Les messages > electroniques etant susceptibles d'alteration, > France Telecom - Orange decline toute responsabilite si ce message a ete > altere, deforme ou falsifie. Merci. > > This message and its attachments may contain confidential or privileged > information that may be protected by law; > they should not be distributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and > delete this message and its attachments. > As emails may be altered, France Telecom - Orange is not liable for messa= ges > that have been modified, changed or falsified. > Thank you. > > _______________________________________________ > dmm mailing list > dmm@ietf.org > https://www.ietf.org/mailman/listinfo/dmm > --=20 ------ Best Regards, Dapeng Liu From pierrick.seite@orange.com Thu Sep 20 00:15: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 BFA9521F8667 for ; Thu, 20 Sep 2012 00:15:01 -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, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8annK125-kGG for ; Thu, 20 Sep 2012 00:15:00 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by ietfa.amsl.com (Postfix) with ESMTP id 3A09921F864D for ; Thu, 20 Sep 2012 00:14:59 -0700 (PDT) Received: from omfedm07.si.francetelecom.fr (unknown [xx.xx.xx.3]) by omfedm14.si.francetelecom.fr (ESMTP service) with ESMTP id CB0A022C6EA; Thu, 20 Sep 2012 09:14:57 +0200 (CEST) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.186]) by omfedm07.si.francetelecom.fr (ESMTP service) with ESMTP id 9DB2A4C08C; Thu, 20 Sep 2012 09:14:57 +0200 (CEST) Received: from PEXCVZYM12.corporate.adroot.infra.ftgroup ([fe80::81f:1640:4749:5d13]) by PEXCVZYH01.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.02.0298.004; Thu, 20 Sep 2012 09:14:57 +0200 From: To: 'Peter McCann' , "Zuniga, Juan Carlos" , "karagian@cs.utwente.nl" , "jouni.nospam@gmail.com" , "dmm@ietf.org" , h chan Thread-Topic: [DMM] Comments on DMM Gap Analysis. Thread-Index: AQHNa/bmXcpjTD/9QkmtNxNtqHDjdJeRf28AgAA2BYCAAEDBoIAAZGOQgAAOQCCAAL2Z4A== Date: Thu, 20 Sep 2012 07:14:56 +0000 Message-ID: <15743_1348125297_505AC271_15743_23_5_81C77F07008CA24F9783A98CFD706F71038C0E@PEXCVZYM12.corporate.adroot.infra.ftgroup> References: <13040_1348059786_5059C28A_13040_17047_1_81C77F07008CA24F9783A98CFD706F71038847@PEXCVZYM12.corporate.adroot.infra.ftgroup> <5963DDF1F751474D8DEEFDCDBEE43AE716E2C073@dfweml512-mbx.china.huawei.com> In-Reply-To: <5963DDF1F751474D8DEEFDCDBEE43AE716E2C073@dfweml512-mbx.china.huawei.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.197.38.4] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2012.6.19.115414 Cc: "dmm-chairs@tools.ietf.org" Subject: Re: [DMM] Comments on DMM Gap Analysis. 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, 20 Sep 2012 07:15:02 -0000 I agree. So, we have different "DMM practices" on the table and first step = is probably to get consensus on what could be the practices. Pierrick > -----Message d'origine----- > De=A0: Peter McCann [mailto:Peter.McCann@huawei.com] > Envoy=E9=A0: mercredi 19 septembre 2012 21:54 > =C0=A0: Zuniga, Juan Carlos; SEITE Pierrick RD-RESA; > karagian@cs.utwente.nl; jouni.nospam@gmail.com; dmm@ietf.org; h chan > Cc=A0: dmm-chairs@tools.ietf.org > Objet=A0: RE: [DMM] Comments on DMM Gap Analysis. >=20 > Maybe the document should be entitled "Existing IP Mobility Practices > and DMM Gap Analysis." I am not sure there are any "DMM Practices" > currently. >=20 > -Pete >=20 > Zuniga, Juan Carlos wrote: > > Hi Pierrick, all, > > > > The document title is "DMM Practices and Gap Analysis", and the > > intention is to address both. When we presented at the meeting it I > > made it clear that we wanted to show our approach to the problem, > > which was first to agree on what are the "current practices" that we > > want to consider, and then provide a "gap analysis" wrt the DMM > > requirements document. > > > > We are currently working on a new version of the document taking into > > account the feedback we got at the meeting and on the ML. We will > > provide more details about the current practices and will take a stab > > at the gap analysis for discussion. > > > > Cheers, > > > > Juan Carlos > > > >> -----Original Message----- > >> From: pierrick.seite@orange.com [mailto:pierrick.seite@orange.com] > >> Sent: Wednesday, September 19, 2012 9:03 AM > >> To: 'karagian@cs.utwente.nl'; jouni.nospam@gmail.com; dmm@ietf.org; > >> h.anthony.chan@huawei.com; Zuniga, Juan Carlos > >> Cc: dmm-chairs@tools.ietf.org > >> Subject: RE: [DMM] Comments on DMM Gap Analysis. > >> > >> Hi Jouni and Julien, > >> > >> > >> Sorry for jumping into the discussion but I'm a little bit confused > >> with recent discussions in DMM. So, let me ask for clarifications > >> about the scope of the gap analysis... > >> > >> The WG is now tackling with the work item 'Practices and Gap > Analysis' > >> and, in my understanding, we are expected to provide a gap analysis > >> regarding the use of mobility protocols in a distributed mobility > >> management environment. However, it seems that the scope of > >> discussions on gap analysis is different.... and I'm confused :-) > >> > >> Actually, in the charter, we agreed to firstly "document practices > >> for the deployment of existing mobility protocols in a distributed > >> mobility management environment" and, then, to make the gap > analysis. > >> However, considering current discussions on "gap analysis": the > >> document on practices has been omitted and discussions are about > >> vanilla mobility protocols and architectures with respect to DMM > >> requirements. So, maybe, such considerations are interesting in the > >> scope of the problem statement, but it seems to me that it is not > the > >> goal of the gap analysis, as initially intended in the charter. Am I > missing something? > >> > >> If I refer to previous DMM charter (because current DMM charter is > >> empty... BTW, is there a reason for an empty charter?), one Work > item > >> was: "Document practices for the deployment of existing mobility > >> protocols in a distributed mobility management environment". Is > this > >> document still in DMM stuff? If yes, shouldn't we document practices > >> before going into the gap analysis? > >> > >> 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: mercredi 19 septembre 2012 13:11 =C0=A0: > >>> jouni.nospam@gmail.com; dmm@ietf.org; h.anthony.chan@huawei.com; > >>> JuanCarlos.Zuniga@interdigital.com Cc=A0: dmm-chairs@tools.ietf.org > >>> Objet=A0: Re: [DMM] Comments on DMM Gap Analysis. > >>> > >>> Hi Jouni, Hi all, > >>> > >>> After discussing this issue with Carlos Jes=FAs Bernardos and Juan > >>> Carlos Zuniga, we concluded that the following set of possible > >>> technologies could be included in the Gap analysis draft: > >>> > >>> =3D> Shim6: Level 3 Multihoming Shim Protocol for IPv6 > http://www.rfc- > >>> editor.org/rfc/rfc5533.txt > >>> > >>> > >>> =3D> LISP Mobile Node > >>> http://www.ietf.org/id/draft-meyer-lisp-mn-07.txt > >>> Locator/ID Separation Protocol (LISP) > >>> http://www.ietf.org/id/draft-ietf-lisp-23.txt > >>> > >>> =3D> Mobile IPv6 Fast Handovers > >>> http://tools.ietf.org/id/draft-ietf-mipshop-rfc5268bis-01.txt This > >>> is the draft that became then RFC5568, so no need to mention it. > >>> http://www.rfc-editor.org/rfc/rfc5568.txt > >>> > >>> > >>> =3D> Fast Handovers for Proxy Mobile IPv6 > >>> http://www.rfc-editor.org/rfc/rfc5949.txt > >>> > >>> =3D> Host Identity Protocol > >>> http://www.rfc-editor.org/rfc/rfc4423.txt > >>> http://www.rfc-editor.org/rfc/rfc5201.txt > >>> http://www.rfc-editor.org/rfc/rfc6253.txt > >>> http://www.rfc-editor.org/rfc/rfc5206.txt > >>> > >>> > >>> > >>> =3D> IKEv2 Mobility and Multihoming Protocol (MOBIKE) > >>> http://www.rfc-editor.org/rfc/rfc4555.txt > >>> > >>> > >>> =3D> GTPv2-C: 3rd Generation Partnership Project; Technical > >>> Specification Group Core Network and Terminals; 3GPP Evolved Packet > >>> System (EPS); Evolved General Packet Radio Service (GPRS) > Tunnelling > >>> Protocol for Control plane (GTPv2-C); Stage 3 (Release 11) > >>> http://www.3gpp.org/ftp/Specs/archive/29_series/29.274/29274- > >>> b30.zip > >>> > >>> Please inform us if this list makes sense to you? > >>> > >>> Best regards, > >>> Georgios > >>> > >>> > >>>> -----Original Message----- > >>>> From: dmm-bounces@ietf.org [mailto:dmm-bounces@ietf.org] On > > Behalf > >> Of > >>>> jouni korhonen > >>>> Sent: woensdag 19 september 2012 9:58 > >>>> To: dmm@ietf.org; h chan; Juan Carlos Zuniga > >>>> Cc: dmm-chairs@tools.ietf.org > >>>> Subject: Re: [DMM] Comments on DMM Gap Analysis. > >>>> > >>>> > >>>> Folks, > >>>> > >>>> It has been rather silent on the list recently. Regarding the > >>>> "explosion" of possible technologies in the GAP analysis, we > >>>> discussed (chairs) > >> that > >>> it is > >>>> better to scope the area "a bit". The charter today has the > >>>> assumption that we build on top of existing _IP_ _Mobility_ > >>>> protocols (and bunch of IETF defined examples follow). So, to > >>>> tighten the scope, the Gap > >> Analysis > >>> should > >>>> leave all routing, session (SIP, ..), transport (MPTCP, SCTP, > >> DCCP, > >>> ..), > >>>> locator/identifier split (HIP, Lisp, ..), naming (DNS tricks, > >>>> ..) > >> etc > >>> based > >>>> solutions out. Coarse but should help us to make progress. We > could > >>>> discuss whether transport layer solution like SCTP fit in but I do > >>>> not > > see > >>> them as end- > >>>> 2-end solutions being deployable in Internet at the moment. > >>>> > >>>> Let us stick with technologies out there that have/had a place > > in > >>> sun: few > >>>> MIP variants, MOBIKE, stuff in 3GPP(2) (oops.. but I think this > >>>> deserves to be evaluated since they are somewhat popular), and > what > >>>> applications do (reconnecting..). This analysis should be down to > >>>> earth practical > >> and > >>> realistic > >>>> on what is already out there to play with. > >>>> > >>>> - Jouni & Julien > >>>> > >>>> > >>>> > >>>> On Jul 27, 2012, at 3:53 PM, Jong-Hyouk Lee wrote: > >>>> > >>>>> Dear Anthony and Juan. > >>>>> > >>>>> I enjoyed the both gap analysis documents (draft-chan-dmm- > >>> framework- > >>>> gap-analysis-02 and draft-zuniga-dmm-gap-analysis-01). Here I > > give > >>> some > >>>> comments that should be used directly in the gap analysis > documents > >>>> if you guys like. > >>>>> > >>>>> Kindly consider the followings during the gap analysis discussion > >>> (since I will > >>>> not be attending the IETF meeting this time). > >>>>> > >>>>> 1. Comment on address (resource) management in a DMM environment. > 2. > >>>>> Comment on a deployment of a client-based mobility solution > >>> (i.e., > >>>> MIPv6) in a DMM environment. > >>>>> 3. Commnet on neighbor mobility anchors' information in a DMM > >>>>> environment. 4. Commnet on an establishment of security > >>>>> associations in a > > DMM > >>>> environment. > >>>>> > >>>>> =3D=3D=3D 1. Comment on address (resource) management in a DMM > >>>>> environment. =3D=3D=3D When existing IP mobility support protocols > >>>>> (e.g., > >>>>> MIPv6 > > and > >>> PMIPv6) > >>>> are considered to be deployed in a DMM environment, a mobile node > >>>> (MN) is allowed to configure a new address while keeping its > >>>> previous address(es). It introduces the following differences with > >>>> the address > >>>> (resource) management of the existing ones: > >>>>> > >>>>> MN's address configured at the interface with a DMM > > environment: > >> n > >>> =3D > >>>>> (IP address at the current access network + previously configured > >>>>> IP > >>>>> address(es) with ongoing sessions) MN's address configured at the > >>>>> interface without a DMM environment: 1 =3D (care-of address > > in > >> MIPv6 > >>> or > >>>>> MN's home address in PMIPv6) > >>>>> > >>>>> This leads a couple of considerations we didn't have with the > >>>>> existing IP mobility support protocols. For instance, > >>>>> > >>>>> 1) MN's address management: use of a newly configured address > > at > >>> the > >>>> current access network for new communication sessions while a > >>>> proper address selection for previously established ongoing > >>>> communication sessions. > >>>>> > >>>>> 2) Additional treatment for ingress filtering: Ingress > > filtering > >> is > >>> widely used > >>>> against source address spoofing. The source addresses > > (especially, > >>> the > >>>> network prefix part) of incoming packets are strictly checked to > >> make > >>> sure > >>>> that those packets are actually from the network that they claim > to > >>>> be from. As the MN are allowed to send data packets with the > >>>> previously configured address(es) at the new access network, those > >>>> data packets would > > be > >>> filtered > >>>> at the ingress filtering place because the source address of > > those > >>> data > >>>> packets is not belonging to the new access network. Accordingly, > an > >>>> additional treatment for ingress filtering is required. > >>>>> > >>>>> 3) MN's address increase at the MN's interface: Recall the number > >>> of MN's > >>>> address configured at an interface is n. Then, n is increased, as > >> the > >>> MN > >>>> changes its point of attachment while keeping its ongoing > >>>> communication sessions. It brings the question: "How many > addresses > >>>> are currently possible to be configured at an interface?" > >>>>> > >>>>> 4) Routing entry increase at the serving mobility anchor: Let the > >>> serving > >>>> mobility anchor is the mobility anchor serves the MN. Traffic > >>>> associated to the MN travels via the serving mobility anchor. The > >>>> increase of the addresses associated to the MN, n, is not only > >>>> concerning to the MN, but also concerning the serving mobility > >>>> anchor as it contributes the > >> increase > >>> of > >>>> routing entries for the MN. > >>>>> > >>>>> =3D=3D=3D 2. Comment on a deployment of a client-based mobility > solution > >>>>> (i.e., MIPv6) in a DMM environment. =3D=3D=3D When a client-based > >>> mobility > >>>> solution (i.e., MIPv6) is consiered to be deployed in a DMM > >>>> environment, an MN is involved in mobility signaling such as > >>>> Binding Update and Acknowledgement messages. This is the big > >>>> difference with the network- based mobility solution (i.e., > >>>> PMIPv6). As the MN send signaling to inform its movement to its > >>>> mobility anchor, the client-based mobility solution allows the MN > >>>> to supply client-centric decision for mobility management. > >>>>> > >>>>> Suppose that the origin mobility anchor is the mobility anchor > >>> where the > >>>> MN has configured its IP address and established ongoing > >>>> communication sessions with the IP address. The number of origin > >>>> mobility anchors are n - 1. Recall that the serving mobility > anchor > >>>> is the mobility anchor > >> where > >>> the MN is > >>>> being served by. Then, the MN's involvement in mobility signaling > >>>> brings us the questions: "Should we let the MN send mobilty > >>>> signaling to > > its > >>> all mobility > >>>> anchors?" or "Would it make sense that the MN only sends mobility > >>>> signaling to its serving mobility anchor?" Depending on the > choice, > >>>> we will have different results: > >>>>> > >>>>> 1) "MN sends mobility signaling to its all mobility anchors" > causes: > >>>>> 1.1 increased mobility signaling load, e.g., signaling * (n - 1). > >>>>> 1.2 bidirectional tunnels are established between the MN and > > its > >>> mobility > >>>> anchors. > >>>>> 1.3 tunneling overhead over the air is present. > >>>>> 1.4 but the tunnels are terminated at the MN so that the MN has > >>> control > >>>> over the tunnels. > >>>>> > >>>>> 2) "MN sends mobility signaling only to its serving mobility > anchor" > >>>>> causes: 2.1 reduced mobility signaling load, e.g., signaling * 1. > >>>>> 2.2 bidirectional tunnels are established between the serving > >>> mobility > >>>> anchors and origin mobility anchors. > >>>>> 2.3 tunneling overhead over the air can be avoided. > >>>>> 2.4 but the MN does not have control over the tunnels so it might > >>> affect to > >>>> NEtwork MObility (NEMO) as the MN (i.e., MR in NEMO) loses the > >>>> tunneling control. > >>>>> > >>>>> =3D=3D=3D 3. Neighbor mobility anchors' information in a DMM > environment. > >>>>> =3D=3D=3D In the client-based mobility solution such as MIPv6, the > >>> network > >>>> topology information does not required to be known to the > > mobility > >>> anchor, > >>>> i.e., home agent (HA), since the HA is informed the current > >> location > >>> of the > >>>> MN. As the HA knows the current location of the MN, it is able to > >>>> tunnel packets associated to the MN. In the network-based mobility > >> solution > >>> such > >>>> as PMIPv6, the similar things happen, i.e., the tunnel between > > the > >>> local > >>>> mobility anchor (LMA) and the mobile access gateway (MAG) is > >>>> established for a given MN. > >>>>> > >>>>> However, as mobility anchors are distributed and bidirectional > >>> tunnels (for > >>>> a given MN) between the distributed mobility anchors are > > required, > >>> the > >>>> neighbor mobility anchors' information should be provided to the > MN > >>>> or the mobility anchor for the establishment of the directional > >>>> tunnels or the update of the MN's current location. > >>>>> > >>>>> Decoupling the data plane and control plane while keeping a > >>> centralized > >>>> node maintaining the mobility context including neighbor mobility > >>>> anchors' information (e.g., identification, IP address, etc) in a > >>>> DMM environment is one of possible solutions. > >>>>> > >>>>> =3D=3D=3D 4. Comment on an establishment of security associations in > > a > >>> DMM > >>>>> environment. =3D=3D=3D For each IP mobility support protocol, diffe= rent > >>> security > >>>> associations (SAs) are required for providing secure mobility > >>>> services to MNs as follows: > >>>>> > >>>>> 1) MIPv6 > >>>>> 1.1 SA between MN and HA. > >>>>> 1.2 SA between MN and serving access router (AR) providing > >> wireless > >>> link > >>>> to the MN. > >>>>> > >>>>> 2) Fast Handover MIPv6 (FMIPv6) > >>>>> 2.1 SA between MN and HA. > >>>>> 2.2 SA between MN and serving AR. > >>>>> 2.3 SA between previous and new ARs. > >>>>> > >>>>> 3) PMIPv6 > >>>>> 3.1 SA between MN and serving MAG. > >>>>> 3.2 SA between serving MAG and LMA. > >>>>> > >>>>> 4) Fast Handover PMIPv6 (FPMIPv6) > >>>>> 4.1 SA between MN and serving MAG. > >>>>> 4.2 SA between serving MAG and LMA. > >>>>> 4.3 SA between previous and new MAGs. > >>>>> > >>>>> Note that the above ones do not consider the cases of SA with a > >>> security- > >>>> backend server (e.g., AAA server) and with a correspondent node > >> (CN). > >>>>> > >>>>> However, depending on DMM solutions, SAs are configured that are > >>>>> different from those of the existing IP mobility support > protocols. > >>>>> For instance, > >>>>> > >>>>> 1) the case of "MN sends mobility signaling to its all mobility > >>>>> anchors" (client-based mobility solution) > >>>>> 1.1 SA between MN and serving mobility anchor providing > > wireless > >>> link to > >>>> the MN. > >>>>> 1.2 SA between MN and origin mobility anchors, i.e., (n - 1) > > SAs > >>> required > >>>> with MN and origin mobility anchors. > >>>>> > >>>>> 2) the case of "MN sends mobility signaling only to its serving > >>>>> mobility anchor" (client-based mobility solution) > >>>>> 2.1 SA between MN and serving mobility anchor. > >>>>> 2.2 SA between serving mobility anchor and origin mobility > >> anchors, > >>> i.e., (n > >>>> - 1) SAs required with serving mobility anchor and origin > > mobility > >>> anchors. > >>>>> > >>>>> 3) the case of "serving mobility anchor sends signaling on behalf > >>>>> of the MN to origin mobility anchors" (network-based mobility > >>>>> solution) > >>>>> 3.1 SA between MN and serving mobility anchor. 3.2 SA between > >>>>> serving mobility anchor and origin mobility > >> anchors, > >>> i.e., (n > >>>> - 1) SAs required with serving mobility anchor and origin > > mobility > >>> anchors. > >>>>> > >>>>> Note that as like before SAs with a security-backend server > >> (e.g., > >>> AAA > >>>> server) and with a CN are not presented. > >>>>> > >>>>> As shown above, DMM solutions (that relies on bidirectional > >>> tunnelings for > >>>> packet forwarding between MN and mobility anchors or between just > >>>> mobility anchors) might bring the key management issues to > >> establish > >>> such > >>>> SAs. > >>>>> > >>>>> Since it's a holiday season, I cannot fully address all of them > >> in > >>> my mind, but > >>>> kindly consider these ones. > >>>>> > >>>>> Cheers. > >>>>> > >>>>> -- > >>>>> 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/ > >>>>> > >>>>> _______________________________________________ > >>>>> 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 > >> > >> > >> > _____________________________________________________________________ > >> _ _ __________________________________________________ > >> > >> Ce message et ses pieces jointes peuvent contenir des informations > >> confidentielles ou privilegiees et ne doivent donc pas etre > diffuses, > >> exploites ou copies sans autorisation. Si vous avez recu ce message > >> par erreur, veuillez le signaler a l'expediteur et le detruire ainsi > >> que les pieces jointes. Les messages electroniques etant > susceptibles > >> d'alteration, France Telecom - Orange decline toute responsabilite > si > >> ce message a ete altere, deforme ou falsifie. Merci. > >> > >> This message and its attachments may contain confidential or > >> privileged information that may be protected by law; they should not > >> be distributed, used or copied without authorisation. If you have > >> received this email in error, please notify the sender and delete > >> this message and its attachments. As emails may be altered, France > >> Telecom - Orange is not liable for messages that have been modified, > >> changed or falsified. Thank you. > > > > _______________________________________________ > > dmm mailing list > > dmm@ietf.org > > https://www.ietf.org/mailman/listinfo/dmm >=20 >=20 ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, France Telecom - Orange decline toute responsabilite si ce message a ete al= tere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, France Telecom - Orange is not liable for message= s that have been modified, changed or falsified. Thank you. From jouni.korhonen@nsn.com Thu Sep 20 01:35: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 BABC721F86EB for ; Thu, 20 Sep 2012 01:35:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.281 X-Spam-Level: X-Spam-Status: No, score=-105.281 tagged_above=-999 required=5 tests=[AWL=-1.318, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4, SARE_LWSHORTT=1.24, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HK7hht-9UHe8 for ; Thu, 20 Sep 2012 01:35:03 -0700 (PDT) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by ietfa.amsl.com (Postfix) with ESMTP id 4A2C821F86B1 for ; Thu, 20 Sep 2012 01:35:02 -0700 (PDT) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id q8K8Ygp4019116 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 20 Sep 2012 10:34:43 +0200 Received: from demuexc023.nsn-intra.net (demuexc023.nsn-intra.net [10.150.128.36]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id q8K8YdRG001752; Thu, 20 Sep 2012 10:34:40 +0200 Received: from FIESEXC035.nsn-intra.net ([10.159.0.25]) by demuexc023.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Thu, 20 Sep 2012 10:34:39 +0200 Received: from 10.144.254.38 ([10.144.254.38]) by FIESEXC035.nsn-intra.net ([10.159.0.182]) via Exchange Front-End Server demuexc023.nsn-intra.net ([10.150.128.36]) with Microsoft Exchange Server HTTP-DAV ; Thu, 20 Sep 2012 08:34:38 +0000 User-Agent: Microsoft-Entourage/12.33.0.120411 Date: Thu, 20 Sep 2012 11:34:33 +0300 From: Jouni Korhonen To: "ext pierrick.seite@orange.com" , "'karagian@cs.utwente.nl'" , "jouni.nospam@gmail.com" , "dmm@ietf.org" , "h.anthony.chan@huawei.com" , "JuanCarlos.Zuniga@interdigital.com" Message-ID: Thread-Topic: [DMM] Comments on DMM Gap Analysis. Thread-Index: AQHNa/bmXcpjTD/9QkmtNxNtqHDjdJeRf28AgAA2BYCAAEDBoIABR2E7 In-Reply-To: <13040_1348059786_5059C28A_13040_17047_1_81C77F07008CA24F9783A98CFD706F71038847@PEXCVZYM12.corporate.adroot.infra.ftgroup> Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable X-OriginalArrivalTime: 20 Sep 2012 08:34:39.0901 (UTC) FILETIME=[C67AB4D0:01CD970A] X-purgate-type: clean X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de X-purgate: clean X-purgate: This mail is considered clean (visit http://www.eleven.de for further information) X-purgate-size: 19469 X-purgate-ID: 151667::1348130083-00006F5F-9F590574/0-0/0-0 Cc: "dmm-chairs@tools.ietf.org" Subject: Re: [DMM] Comments on DMM Gap Analysis. 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, 20 Sep 2012 08:35:04 -0000 Pierrick, On 9/19/12 4:03 PM, "ext pierrick.seite@orange.com" wrote: > Hi Jouni and Julien, >=20 >=20 > Sorry for jumping into the discussion but I'm a little bit confused with > recent discussions in DMM. So, let me ask for clarifications about the sc= ope > of the gap analysis... >=20 > The WG is now tackling with the work item 'Practices and Gap Analysis' an= d, in > my understanding, we are expected to provide a gap analysis regarding the= use > of mobility protocols in a distributed mobility management environment. > However, it seems that the scope of discussions on gap analysis is > different.... and I'm confused :-) The "distributed" environment would be what we have now.. Like if you operate a network that has more than one anchor node, you can consider that as a system which could enable distribution. And if e.g. anchor distributio= n is possible/done today that would be documented (example: LMA selection during the attach time based on geographical location). o Practices: Document practices for the deployment of existing mobility protocols in a distributed mobility management environment. Gap analysis is then based on that.. and =20 > Actually, in the charter, we agreed to firstly "document practices for th= e > deployment of existing mobility protocols in a distributed mobility manag= ement ..during the meeting I asked the question whether we deal current practices and gap analysis in the same document, since there are conflicting milestones. There was no clear answer from the room as far as I remember (and minutes indicate). I am (still) on the opinion that these two can and probably should be the one same document. There are not too many current practices given the rathe= r low number of _really_deployed_ IP mobility technologies that we can write meaningful current practices about. Then you would do the gap analysis against those. > environment" and, then, to make the gap analysis. However, considering cu= rrent > discussions on "gap analysis": the document on practices has been omitted= and > discussions are about vanilla mobility protocols and architectures with > respect to DMM requirements. So, maybe, such considerations are interesti= ng in > the scope of the problem statement, but it seems to me that it is not the= goal > of the gap analysis, as initially intended in the charter. Am I missing > something?=20 I should have been clearer that I would like to see these two combined. o Submit I-D 'Practices and Gap Analysis' as a working group document. That also kind of forces strict scoping of mobility technologies I mentione= d about in my earlier mail. I don't want to see a current practices or gap analysis of solutions that has no relation to an existing and rather short term planned deployment reality.. > If I refer to previous DMM charter (because current DMM charter is empty.= .. > BTW, is there a reason for an empty charter?), one Work item was: "Docume= nt There are issues between datatracker and tools coordination or something. Tools guys are on this. You can find older(?) version of the charter on the tools page and yesterday the charter re-appeared again to datatracker. > practices for the deployment of existing mobility protocols in a distribu= ted > mobility management environment". Is this document still in DMM stuff? I= f > yes, shouldn't we document practices before going into the gap analysis? Mmm yes. But if you combine both you should be fine too. If folks think and insist that there shall be a current practices as a separate document, so b= e it.=20 - Jouni >=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: mercredi 19 septembre 2012 13:11 >> =C0=A0: jouni.nospam@gmail.com; dmm@ietf.org; h.anthony.chan@huawei.com; >> JuanCarlos.Zuniga@interdigital.com >> Cc=A0: dmm-chairs@tools.ietf.org >> Objet=A0: Re: [DMM] Comments on DMM Gap Analysis. >>=20 >> Hi Jouni, Hi all, >>=20 >> After discussing this issue with Carlos Jes=FAs Bernardos and Juan Carlos >> Zuniga, we concluded that the following set of possible technologies >> could be included in the Gap analysis draft: >>=20 >> =3D> Shim6: Level 3 Multihoming Shim Protocol for IPv6 http://www.rfc- >> editor.org/rfc/rfc5533.txt >>=20 >>=20 >> =3D> LISP Mobile Node >> http://www.ietf.org/id/draft-meyer-lisp-mn-07.txt >> Locator/ID Separation Protocol (LISP) >> http://www.ietf.org/id/draft-ietf-lisp-23.txt >>=20 >> =3D> Mobile IPv6 Fast Handovers >> http://tools.ietf.org/id/draft-ietf-mipshop-rfc5268bis-01.txt >> This is the draft that became then RFC5568, so no need to mention it. >> http://www.rfc-editor.org/rfc/rfc5568.txt >>=20 >>=20 >> =3D> Fast Handovers for Proxy Mobile IPv6 >> http://www.rfc-editor.org/rfc/rfc5949.txt >>=20 >> =3D> Host Identity Protocol >> http://www.rfc-editor.org/rfc/rfc4423.txt >> http://www.rfc-editor.org/rfc/rfc5201.txt >> http://www.rfc-editor.org/rfc/rfc6253.txt >> http://www.rfc-editor.org/rfc/rfc5206.txt >>=20 >>=20 >>=20 >> =3D> IKEv2 Mobility and Multihoming Protocol (MOBIKE) >> http://www.rfc-editor.org/rfc/rfc4555.txt >>=20 >>=20 >> =3D> GTPv2-C: 3rd Generation Partnership Project; Technical Specification >> Group Core Network and Terminals; 3GPP Evolved Packet System (EPS); >> Evolved General Packet Radio Service (GPRS) Tunnelling Protocol for >> Control plane (GTPv2-C); Stage 3 (Release 11) >> http://www.3gpp.org/ftp/Specs/archive/29_series/29.274/29274-b30.zip >>=20 >> Please inform us if this list makes sense to you? >>=20 >> Best regards, >> Georgios >>=20 >>=20 >>> -----Original Message----- >>> From: dmm-bounces@ietf.org [mailto:dmm-bounces@ietf.org] On Behalf Of >>> jouni korhonen >>> Sent: woensdag 19 september 2012 9:58 >>> To: dmm@ietf.org; h chan; Juan Carlos Zuniga >>> Cc: dmm-chairs@tools.ietf.org >>> Subject: Re: [DMM] Comments on DMM Gap Analysis. >>>=20 >>>=20 >>> Folks, >>>=20 >>> It has been rather silent on the list recently. Regarding the >> "explosion" of >>> possible technologies in the GAP analysis, we discussed (chairs) that >> it is >>> better to scope the area "a bit". The charter today has the >> assumption that >>> we build on top of existing _IP_ _Mobility_ protocols (and bunch of >> IETF >>> defined examples follow). So, to tighten the scope, the Gap Analysis >> should >>> leave all routing, session (SIP, ..), transport (MPTCP, SCTP, DCCP, >> ..), >>> locator/identifier split (HIP, Lisp, ..), naming (DNS tricks, ..) etc >> based >>> solutions out. Coarse but should help us to make progress. We could >> discuss >>> whether transport layer solution like SCTP fit in but I do not see >> them as end- >>> 2-end solutions being deployable in Internet at the moment. >>>=20 >>> Let us stick with technologies out there that have/had a place in >> sun: few >>> MIP variants, MOBIKE, stuff in 3GPP(2) (oops.. but I think this >> deserves to be >>> evaluated since they are somewhat popular), and what applications do >>> (reconnecting..). This analysis should be down to earth practical and >> realistic >>> on what is already out there to play with. >>>=20 >>> - Jouni & Julien >>>=20 >>>=20 >>>=20 >>> On Jul 27, 2012, at 3:53 PM, Jong-Hyouk Lee wrote: >>>=20 >>>> Dear Anthony and Juan. >>>>=20 >>>> I enjoyed the both gap analysis documents (draft-chan-dmm- >> framework- >>> gap-analysis-02 and draft-zuniga-dmm-gap-analysis-01). Here I give >> some >>> comments that should be used directly in the gap analysis documents >> if you >>> guys like. >>>>=20 >>>> Kindly consider the followings during the gap analysis discussion >> (since I will >>> not be attending the IETF meeting this time). >>>>=20 >>>> 1. Comment on address (resource) management in a DMM environment. >>>> 2. Comment on a deployment of a client-based mobility solution >> (i.e., >>> MIPv6) in a DMM environment. >>>> 3. Commnet on neighbor mobility anchors' information in a DMM >>> environment. >>>> 4. Commnet on an establishment of security associations in a DMM >>> environment. >>>>=20 >>>> =3D=3D=3D 1. Comment on address (resource) management in a DMM >>> environment. >>>> =3D=3D=3D When existing IP mobility support protocols (e.g., MIPv6 and >> PMIPv6) >>> are considered to be deployed in a DMM environment, a mobile node >> (MN) >>> is allowed to configure a new address while keeping its previous >> address(es). >>> It introduces the following differences with the address (resource) >>> management of the existing ones: >>>>=20 >>>> MN's address configured at the interface with a DMM environment: n >> =3D >>>> (IP address at the current access network + previously configured >> IP >>>> address(es) with ongoing sessions) MN's address configured at the >>>> interface without a DMM environment: 1 =3D (care-of address in MIPv6 >> or >>>> MN's home address in PMIPv6) >>>>=20 >>>> This leads a couple of considerations we didn't have with the >> existing >>>> IP mobility support protocols. For instance, >>>>=20 >>>> 1) MN's address management: use of a newly configured address at >> the >>> current access network for new communication sessions while a proper >>> address selection for previously established ongoing communication >>> sessions. >>>>=20 >>>> 2) Additional treatment for ingress filtering: Ingress filtering is >> widely used >>> against source address spoofing. The source addresses (especially, >> the >>> network prefix part) of incoming packets are strictly checked to make >> sure >>> that those packets are actually from the network that they claim to >> be from. >>> As the MN are allowed to send data packets with the previously >> configured >>> address(es) at the new access network, those data packets would be >> filtered >>> at the ingress filtering place because the source address of those >> data >>> packets is not belonging to the new access network. Accordingly, an >>> additional treatment for ingress filtering is required. >>>>=20 >>>> 3) MN's address increase at the MN's interface: Recall the number >> of MN's >>> address configured at an interface is n. Then, n is increased, as the >> MN >>> changes its point of attachment while keeping its ongoing >> communication >>> sessions. It brings the question: "How many addresses are currently >> possible >>> to be configured at an interface?" >>>>=20 >>>> 4) Routing entry increase at the serving mobility anchor: Let the >> serving >>> mobility anchor is the mobility anchor serves the MN. Traffic >> associated to >>> the MN travels via the serving mobility anchor. The increase of the >> addresses >>> associated to the MN, n, is not only concerning to the MN, but also >>> concerning the serving mobility anchor as it contributes the increase >> of >>> routing entries for the MN. >>>>=20 >>>> =3D=3D=3D 2. Comment on a deployment of a client-based mobility solution >>>> (i.e., MIPv6) in a DMM environment. =3D=3D=3D When a client-based >> mobility >>> solution (i.e., MIPv6) is consiered to be deployed in a DMM >> environment, an >>> MN is involved in mobility signaling such as Binding Update and >>> Acknowledgement messages. This is the big difference with the >> network- >>> based mobility solution (i.e., PMIPv6). As the MN send signaling to >> inform its >>> movement to its mobility anchor, the client-based mobility solution >> allows >>> the MN to supply client-centric decision for mobility management. >>>>=20 >>>> Suppose that the origin mobility anchor is the mobility anchor >> where the >>> MN has configured its IP address and established ongoing >> communication >>> sessions with the IP address. The number of origin mobility anchors >> are n - 1. >>> Recall that the serving mobility anchor is the mobility anchor where >> the MN is >>> being served by. Then, the MN's involvement in mobility signaling >> brings us >>> the questions: "Should we let the MN send mobilty signaling to its >> all mobility >>> anchors?" or "Would it make sense that the MN only sends mobility >> signaling >>> to its serving mobility anchor?" Depending on the choice, we will >> have >>> different results: >>>>=20 >>>> 1) "MN sends mobility signaling to its all mobility anchors" >> causes: >>>> 1.1 increased mobility signaling load, e.g., signaling * (n - 1). >>>> 1.2 bidirectional tunnels are established between the MN and its >> mobility >>> anchors. >>>> 1.3 tunneling overhead over the air is present. >>>> 1.4 but the tunnels are terminated at the MN so that the MN has >> control >>> over the tunnels. >>>>=20 >>>> 2) "MN sends mobility signaling only to its serving mobility >> anchor" causes: >>>> 2.1 reduced mobility signaling load, e.g., signaling * 1. >>>> 2.2 bidirectional tunnels are established between the serving >> mobility >>> anchors and origin mobility anchors. >>>> 2.3 tunneling overhead over the air can be avoided. >>>> 2.4 but the MN does not have control over the tunnels so it might >> affect to >>> NEtwork MObility (NEMO) as the MN (i.e., MR in NEMO) loses the >> tunneling >>> control. >>>>=20 >>>> =3D=3D=3D 3. Neighbor mobility anchors' information in a DMM environment. >>>> =3D=3D=3D In the client-based mobility solution such as MIPv6, the >> network >>> topology information does not required to be known to the mobility >> anchor, >>> i.e., home agent (HA), since the HA is informed the current location >> of the >>> MN. As the HA knows the current location of the MN, it is able to >> tunnel >>> packets associated to the MN. In the network-based mobility solution >> such >>> as PMIPv6, the similar things happen, i.e., the tunnel between the >> local >>> mobility anchor (LMA) and the mobile access gateway (MAG) is >> established >>> for a given MN. >>>>=20 >>>> However, as mobility anchors are distributed and bidirectional >> tunnels (for >>> a given MN) between the distributed mobility anchors are required, >> the >>> neighbor mobility anchors' information should be provided to the MN >> or the >>> mobility anchor for the establishment of the directional tunnels or >> the >>> update of the MN's current location. >>>>=20 >>>> Decoupling the data plane and control plane while keeping a >> centralized >>> node maintaining the mobility context including neighbor mobility >> anchors' >>> information (e.g., identification, IP address, etc) in a DMM >> environment is >>> one of possible solutions. >>>>=20 >>>> =3D=3D=3D 4. Comment on an establishment of security associations in a >> DMM >>>> environment. =3D=3D=3D For each IP mobility support protocol, different >> security >>> associations (SAs) are required for providing secure mobility >> services to MNs >>> as follows: >>>>=20 >>>> 1) MIPv6 >>>> 1.1 SA between MN and HA. >>>> 1.2 SA between MN and serving access router (AR) providing wireless >> link >>> to the MN. >>>>=20 >>>> 2) Fast Handover MIPv6 (FMIPv6) >>>> 2.1 SA between MN and HA. >>>> 2.2 SA between MN and serving AR. >>>> 2.3 SA between previous and new ARs. >>>>=20 >>>> 3) PMIPv6 >>>> 3.1 SA between MN and serving MAG. >>>> 3.2 SA between serving MAG and LMA. >>>>=20 >>>> 4) Fast Handover PMIPv6 (FPMIPv6) >>>> 4.1 SA between MN and serving MAG. >>>> 4.2 SA between serving MAG and LMA. >>>> 4.3 SA between previous and new MAGs. >>>>=20 >>>> Note that the above ones do not consider the cases of SA with a >> security- >>> backend server (e.g., AAA server) and with a correspondent node (CN). >>>>=20 >>>> However, depending on DMM solutions, SAs are configured that are >>>> different from those of the existing IP mobility support protocols. >>>> For instance, >>>>=20 >>>> 1) the case of "MN sends mobility signaling to its all mobility >>>> anchors" (client-based mobility solution) >>>> 1.1 SA between MN and serving mobility anchor providing wireless >> link to >>> the MN. >>>> 1.2 SA between MN and origin mobility anchors, i.e., (n - 1) SAs >> required >>> with MN and origin mobility anchors. >>>>=20 >>>> 2) the case of "MN sends mobility signaling only to its serving >>>> mobility anchor" (client-based mobility solution) >>>> 2.1 SA between MN and serving mobility anchor. >>>> 2.2 SA between serving mobility anchor and origin mobility anchors, >> i.e., (n >>> - 1) SAs required with serving mobility anchor and origin mobility >> anchors. >>>>=20 >>>> 3) the case of "serving mobility anchor sends signaling on behalf >> of >>>> the MN to origin mobility anchors" (network-based mobility >> solution) >>>> 3.1 SA between MN and serving mobility anchor. >>>> 3.2 SA between serving mobility anchor and origin mobility anchors, >> i.e., (n >>> - 1) SAs required with serving mobility anchor and origin mobility >> anchors. >>>>=20 >>>> Note that as like before SAs with a security-backend server (e.g., >> AAA >>> server) and with a CN are not presented. >>>>=20 >>>> As shown above, DMM solutions (that relies on bidirectional >> tunnelings for >>> packet forwarding between MN and mobility anchors or between just >>> mobility anchors) might bring the key management issues to establish >> such >>> SAs. >>>>=20 >>>> Since it's a holiday season, I cannot fully address all of them in >> my mind, but >>> kindly consider these ones. >>>>=20 >>>> Cheers. >>>>=20 >>>> -- >>>> RSM Department, TELECOM Bretagne, France Jong-Hyouk Lee, living >>>> somewhere between /dev/null and /dev/random >>>>=20 >>>> #email: jonghyouk (at) gmail (dot) com >>>> #webpage: http://sites.google.com/site/hurryon/ >>>>=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 >> _______________________________________________ >> dmm mailing list >> dmm@ietf.org >> https://www.ietf.org/mailman/listinfo/dmm >=20 > _________________________________________________________________________= _____ > ___________________________________________ >=20 > Ce message et ses pieces jointes peuvent contenir des informations > confidentielles ou privilegiees et ne doivent donc > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez re= cu ce > message par erreur, veuillez le signaler > a l'expediteur et le detruire ainsi que les pieces jointes. Les messages > electroniques etant susceptibles d'alteration, > France Telecom - Orange decline toute responsabilite si ce message a ete > altere, deforme ou falsifie. Merci. >=20 > This message and its attachments may contain confidential or privileged > information that may be protected by law; > they should not be distributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and de= lete > this message and its attachments. > As emails may be altered, France Telecom - Orange is not liable for messa= ges > that have been modified, changed or falsified. > Thank you. >=20 From pierrick.seite@orange.com Thu Sep 20 04:51:22 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 EAE2421F87DF for ; Thu, 20 Sep 2012 04:51:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[AWL=-0.620, BAYES_00=-2.599, SARE_LWSHORTT=1.24, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1-2oWdgTKY+h for ; Thu, 20 Sep 2012 04:51:21 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by ietfa.amsl.com (Postfix) with ESMTP id C789321F87D8 for ; Thu, 20 Sep 2012 04:51:20 -0700 (PDT) Received: from omfedm06.si.francetelecom.fr (unknown [xx.xx.xx.2]) by omfedm10.si.francetelecom.fr (ESMTP service) with ESMTP id E1AF8264247; Thu, 20 Sep 2012 13:51:19 +0200 (CEST) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.183]) by omfedm06.si.francetelecom.fr (ESMTP service) with ESMTP id BF9FB27C109; Thu, 20 Sep 2012 13:51:19 +0200 (CEST) Received: from PEXCVZYM12.corporate.adroot.infra.ftgroup ([fe80::81f:1640:4749:5d13]) by PEXCVZYH02.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.02.0298.004; Thu, 20 Sep 2012 13:51:18 +0200 From: To: 'Jouni Korhonen' , "'karagian@cs.utwente.nl'" , "jouni.nospam@gmail.com" , "dmm@ietf.org" , "h.anthony.chan@huawei.com" , "JuanCarlos.Zuniga@interdigital.com" Thread-Topic: [DMM] Comments on DMM Gap Analysis. Thread-Index: AQHNa/bmXcpjTD/9QkmtNxNtqHDjdJeRf28AgAA2BYCAAEDBoIABR2E7gAA29qA= Date: Thu, 20 Sep 2012 11:51:19 +0000 Message-ID: <19629_1348141879_505B0337_19629_713_1_81C77F07008CA24F9783A98CFD706F71038D41@PEXCVZYM12.corporate.adroot.infra.ftgroup> References: <13040_1348059786_5059C28A_13040_17047_1_81C77F07008CA24F9783A98CFD706F71038847@PEXCVZYM12.corporate.adroot.infra.ftgroup> In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.197.38.4] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2012.6.19.115414 Cc: "dmm-chairs@tools.ietf.org" Subject: Re: [DMM] Comments on DMM Gap Analysis. 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, 20 Sep 2012 11:51:23 -0000 Jouni, Thanks for clarifications. I agree, we have a good idea on what could be a = DMM environment. However, the application of IP mobility protocols in such = environments is worth to be described; we need to clearly figure out applic= ation and issues. Now, you're probably right when saying there is no room f= or dedicated document. Actually, I think it is a good idea to have the desc= ription of practices together with gap analysis in a single document :-) Bu= t, the problem is that, today, we have couple of documents on practices and= others on gap analysis, without real consensus on practices. So, IMHO, we = need to firstly agree on practices the WG will recommend. And, to do that, = we probably need to consider current contributions and limit the scope to s= ome protocols (as you reminded in a previous email). That's my point but I = do not push for separate document :-) BTW, since mobility management is not deployed in distributed architecture,= it would be better to talk about "recommendations" than "practices" :) Pierrick > -----Message d'origine----- > De=A0: Jouni Korhonen [mailto:jouni.korhonen@nsn.com] > Envoy=E9=A0: jeudi 20 septembre 2012 10:35 > =C0=A0: SEITE Pierrick RD-RESA; 'karagian@cs.utwente.nl'; > jouni.nospam@gmail.com; dmm@ietf.org; h.anthony.chan@huawei.com; > JuanCarlos.Zuniga@interdigital.com > Cc=A0: dmm-chairs@tools.ietf.org > Objet=A0: Re: [DMM] Comments on DMM Gap Analysis. >=20 > Pierrick, >=20 > On 9/19/12 4:03 PM, "ext pierrick.seite@orange.com" > wrote: >=20 > > Hi Jouni and Julien, > > > > > > Sorry for jumping into the discussion but I'm a little bit confused > > with recent discussions in DMM. So, let me ask for clarifications > > about the scope of the gap analysis... > > > > The WG is now tackling with the work item 'Practices and Gap > Analysis' > > and, in my understanding, we are expected to provide a gap analysis > > regarding the use of mobility protocols in a distributed mobility > management environment. > > However, it seems that the scope of discussions on gap analysis is > > different.... and I'm confused :-) >=20 > The "distributed" environment would be what we have now.. Like if you > operate a network that has more than one anchor node, you can consider > that as a system which could enable distribution. And if e.g. anchor > distribution is possible/done today that would be documented (example: > LMA selection during the attach time based on geographical location). >=20 > o Practices: Document practices for the deployment of existing > mobility protocols in a distributed mobility management > environment. >=20 > Gap analysis is then based on that.. and >=20 > > Actually, in the charter, we agreed to firstly "document practices > for > > the deployment of existing mobility protocols in a distributed > > mobility management >=20 > ..during the meeting I asked the question whether we deal current > practices and gap analysis in the same document, since there are > conflicting milestones. There was no clear answer from the room as far > as I remember (and minutes indicate). >=20 > I am (still) on the opinion that these two can and probably should be > the one same document. There are not too many current practices given > the rather low number of _really_deployed_ IP mobility technologies > that we can write meaningful current practices about. Then you would do > the gap analysis against those. >=20 > > environment" and, then, to make the gap analysis. However, > considering > > current discussions on "gap analysis": the document on practices has > > been omitted and discussions are about vanilla mobility protocols and > > architectures with respect to DMM requirements. So, maybe, such > > considerations are interesting in the scope of the problem statement, > > but it seems to me that it is not the goal of the gap analysis, as > > initially intended in the charter. Am I missing something? >=20 > I should have been clearer that I would like to see these two combined. > o Submit I-D 'Practices and Gap Analysis' as a working group document. >=20 > That also kind of forces strict scoping of mobility technologies I > mentioned about in my earlier mail. >=20 > I don't want to see a current practices or gap analysis of solutions > that has no relation to an existing and rather short term planned > deployment reality.. >=20 > > If I refer to previous DMM charter (because current DMM charter is > empty... > > BTW, is there a reason for an empty charter?), one Work item was: > > "Document >=20 > There are issues between datatracker and tools coordination or > something. > Tools guys are on this. You can find older(?) version of the charter on > the tools page and yesterday the charter re-appeared again to > datatracker. >=20 > > practices for the deployment of existing mobility protocols in a > > distributed mobility management environment". Is this document still > > in DMM stuff? If yes, shouldn't we document practices before going > into the gap analysis? >=20 > Mmm yes. But if you combine both you should be fine too. If folks think > and insist that there shall be a current practices as a separate > document, so be it. >=20 > - Jouni >=20 >=20 >=20 > > > > 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: mercredi 19 septembre 2012 13:11 = =C0=A0: > >> jouni.nospam@gmail.com; dmm@ietf.org; h.anthony.chan@huawei.com; > >> JuanCarlos.Zuniga@interdigital.com > >> Cc=A0: dmm-chairs@tools.ietf.org > >> Objet=A0: Re: [DMM] Comments on DMM Gap Analysis. > >> > >> Hi Jouni, Hi all, > >> > >> After discussing this issue with Carlos Jes=FAs Bernardos and Juan > >> Carlos Zuniga, we concluded that the following set of possible > >> technologies could be included in the Gap analysis draft: > >> > >> =3D> Shim6: Level 3 Multihoming Shim Protocol for IPv6 http://www.rfc- > >> editor.org/rfc/rfc5533.txt > >> > >> > >> =3D> LISP Mobile Node > >> http://www.ietf.org/id/draft-meyer-lisp-mn-07.txt > >> Locator/ID Separation Protocol (LISP) > >> http://www.ietf.org/id/draft-ietf-lisp-23.txt > >> > >> =3D> Mobile IPv6 Fast Handovers > >> http://tools.ietf.org/id/draft-ietf-mipshop-rfc5268bis-01.txt > >> This is the draft that became then RFC5568, so no need to mention > it. > >> http://www.rfc-editor.org/rfc/rfc5568.txt > >> > >> > >> =3D> Fast Handovers for Proxy Mobile IPv6 > >> http://www.rfc-editor.org/rfc/rfc5949.txt > >> > >> =3D> Host Identity Protocol > >> http://www.rfc-editor.org/rfc/rfc4423.txt > >> http://www.rfc-editor.org/rfc/rfc5201.txt > >> http://www.rfc-editor.org/rfc/rfc6253.txt > >> http://www.rfc-editor.org/rfc/rfc5206.txt > >> > >> > >> > >> =3D> IKEv2 Mobility and Multihoming Protocol (MOBIKE) > >> http://www.rfc-editor.org/rfc/rfc4555.txt > >> > >> > >> =3D> GTPv2-C: 3rd Generation Partnership Project; Technical > >> Specification Group Core Network and Terminals; 3GPP Evolved Packet > >> System (EPS); Evolved General Packet Radio Service (GPRS) Tunnelling > >> Protocol for Control plane (GTPv2-C); Stage 3 (Release 11) > >> http://www.3gpp.org/ftp/Specs/archive/29_series/29.274/29274-b30.zip > >> > >> Please inform us if this list makes sense to you? > >> > >> Best regards, > >> Georgios > >> > >> > >>> -----Original Message----- > >>> From: dmm-bounces@ietf.org [mailto:dmm-bounces@ietf.org] On Behalf > >>> Of jouni korhonen > >>> Sent: woensdag 19 september 2012 9:58 > >>> To: dmm@ietf.org; h chan; Juan Carlos Zuniga > >>> Cc: dmm-chairs@tools.ietf.org > >>> Subject: Re: [DMM] Comments on DMM Gap Analysis. > >>> > >>> > >>> Folks, > >>> > >>> It has been rather silent on the list recently. Regarding the > >> "explosion" of > >>> possible technologies in the GAP analysis, we discussed (chairs) > >>> that > >> it is > >>> better to scope the area "a bit". The charter today has the > >> assumption that > >>> we build on top of existing _IP_ _Mobility_ protocols (and bunch of > >> IETF > >>> defined examples follow). So, to tighten the scope, the Gap > Analysis > >> should > >>> leave all routing, session (SIP, ..), transport (MPTCP, SCTP, > DCCP, > >> ..), > >>> locator/identifier split (HIP, Lisp, ..), naming (DNS tricks, ..) > >>> etc > >> based > >>> solutions out. Coarse but should help us to make progress. We could > >> discuss > >>> whether transport layer solution like SCTP fit in but I do not see > >> them as end- > >>> 2-end solutions being deployable in Internet at the moment. > >>> > >>> Let us stick with technologies out there that have/had a place in > >> sun: few > >>> MIP variants, MOBIKE, stuff in 3GPP(2) (oops.. but I think this > >> deserves to be > >>> evaluated since they are somewhat popular), and what applications > do > >>> (reconnecting..). This analysis should be down to earth practical > >>> and > >> realistic > >>> on what is already out there to play with. > >>> > >>> - Jouni & Julien > >>> > >>> > >>> > >>> On Jul 27, 2012, at 3:53 PM, Jong-Hyouk Lee wrote: > >>> > >>>> Dear Anthony and Juan. > >>>> > >>>> I enjoyed the both gap analysis documents (draft-chan-dmm- > >> framework- > >>> gap-analysis-02 and draft-zuniga-dmm-gap-analysis-01). Here I give > >> some > >>> comments that should be used directly in the gap analysis documents > >> if you > >>> guys like. > >>>> > >>>> Kindly consider the followings during the gap analysis discussion > >> (since I will > >>> not be attending the IETF meeting this time). > >>>> > >>>> 1. Comment on address (resource) management in a DMM environment. > >>>> 2. Comment on a deployment of a client-based mobility solution > >> (i.e., > >>> MIPv6) in a DMM environment. > >>>> 3. Commnet on neighbor mobility anchors' information in a DMM > >>> environment. > >>>> 4. Commnet on an establishment of security associations in a DMM > >>> environment. > >>>> > >>>> =3D=3D=3D 1. Comment on address (resource) management in a DMM > >>> environment. > >>>> =3D=3D=3D When existing IP mobility support protocols (e.g., MIPv6 a= nd > >> PMIPv6) > >>> are considered to be deployed in a DMM environment, a mobile node > >> (MN) > >>> is allowed to configure a new address while keeping its previous > >> address(es). > >>> It introduces the following differences with the address (resource) > >>> management of the existing ones: > >>>> > >>>> MN's address configured at the interface with a DMM environment: n > >> =3D > >>>> (IP address at the current access network + previously configured > >> IP > >>>> address(es) with ongoing sessions) MN's address configured at the > >>>> interface without a DMM environment: 1 =3D (care-of address in MIPv6 > >> or > >>>> MN's home address in PMIPv6) > >>>> > >>>> This leads a couple of considerations we didn't have with the > >> existing > >>>> IP mobility support protocols. For instance, > >>>> > >>>> 1) MN's address management: use of a newly configured address at > >> the > >>> current access network for new communication sessions while a > proper > >>> address selection for previously established ongoing communication > >>> sessions. > >>>> > >>>> 2) Additional treatment for ingress filtering: Ingress filtering > is > >> widely used > >>> against source address spoofing. The source addresses (especially, > >> the > >>> network prefix part) of incoming packets are strictly checked to > >>> make > >> sure > >>> that those packets are actually from the network that they claim to > >> be from. > >>> As the MN are allowed to send data packets with the previously > >> configured > >>> address(es) at the new access network, those data packets would be > >> filtered > >>> at the ingress filtering place because the source address of those > >> data > >>> packets is not belonging to the new access network. Accordingly, an > >>> additional treatment for ingress filtering is required. > >>>> > >>>> 3) MN's address increase at the MN's interface: Recall the number > >> of MN's > >>> address configured at an interface is n. Then, n is increased, as > >>> the > >> MN > >>> changes its point of attachment while keeping its ongoing > >> communication > >>> sessions. It brings the question: "How many addresses are currently > >> possible > >>> to be configured at an interface?" > >>>> > >>>> 4) Routing entry increase at the serving mobility anchor: Let the > >> serving > >>> mobility anchor is the mobility anchor serves the MN. Traffic > >> associated to > >>> the MN travels via the serving mobility anchor. The increase of the > >> addresses > >>> associated to the MN, n, is not only concerning to the MN, but also > >>> concerning the serving mobility anchor as it contributes the > >>> increase > >> of > >>> routing entries for the MN. > >>>> > >>>> =3D=3D=3D 2. Comment on a deployment of a client-based mobility solu= tion > >>>> (i.e., MIPv6) in a DMM environment. =3D=3D=3D When a client-based > >> mobility > >>> solution (i.e., MIPv6) is consiered to be deployed in a DMM > >> environment, an > >>> MN is involved in mobility signaling such as Binding Update and > >>> Acknowledgement messages. This is the big difference with the > >> network- > >>> based mobility solution (i.e., PMIPv6). As the MN send signaling to > >> inform its > >>> movement to its mobility anchor, the client-based mobility solution > >> allows > >>> the MN to supply client-centric decision for mobility management. > >>>> > >>>> Suppose that the origin mobility anchor is the mobility anchor > >> where the > >>> MN has configured its IP address and established ongoing > >> communication > >>> sessions with the IP address. The number of origin mobility anchors > >> are n - 1. > >>> Recall that the serving mobility anchor is the mobility anchor > where > >> the MN is > >>> being served by. Then, the MN's involvement in mobility signaling > >> brings us > >>> the questions: "Should we let the MN send mobilty signaling to its > >> all mobility > >>> anchors?" or "Would it make sense that the MN only sends mobility > >> signaling > >>> to its serving mobility anchor?" Depending on the choice, we will > >> have > >>> different results: > >>>> > >>>> 1) "MN sends mobility signaling to its all mobility anchors" > >> causes: > >>>> 1.1 increased mobility signaling load, e.g., signaling * (n - 1). > >>>> 1.2 bidirectional tunnels are established between the MN and its > >> mobility > >>> anchors. > >>>> 1.3 tunneling overhead over the air is present. > >>>> 1.4 but the tunnels are terminated at the MN so that the MN has > >> control > >>> over the tunnels. > >>>> > >>>> 2) "MN sends mobility signaling only to its serving mobility > >> anchor" causes: > >>>> 2.1 reduced mobility signaling load, e.g., signaling * 1. > >>>> 2.2 bidirectional tunnels are established between the serving > >> mobility > >>> anchors and origin mobility anchors. > >>>> 2.3 tunneling overhead over the air can be avoided. > >>>> 2.4 but the MN does not have control over the tunnels so it might > >> affect to > >>> NEtwork MObility (NEMO) as the MN (i.e., MR in NEMO) loses the > >> tunneling > >>> control. > >>>> > >>>> =3D=3D=3D 3. Neighbor mobility anchors' information in a DMM > environment. > >>>> =3D=3D=3D In the client-based mobility solution such as MIPv6, the > >> network > >>> topology information does not required to be known to the mobility > >> anchor, > >>> i.e., home agent (HA), since the HA is informed the current > location > >> of the > >>> MN. As the HA knows the current location of the MN, it is able to > >> tunnel > >>> packets associated to the MN. In the network-based mobility > solution > >> such > >>> as PMIPv6, the similar things happen, i.e., the tunnel between the > >> local > >>> mobility anchor (LMA) and the mobile access gateway (MAG) is > >> established > >>> for a given MN. > >>>> > >>>> However, as mobility anchors are distributed and bidirectional > >> tunnels (for > >>> a given MN) between the distributed mobility anchors are required, > >> the > >>> neighbor mobility anchors' information should be provided to the MN > >> or the > >>> mobility anchor for the establishment of the directional tunnels or > >> the > >>> update of the MN's current location. > >>>> > >>>> Decoupling the data plane and control plane while keeping a > >> centralized > >>> node maintaining the mobility context including neighbor mobility > >> anchors' > >>> information (e.g., identification, IP address, etc) in a DMM > >> environment is > >>> one of possible solutions. > >>>> > >>>> =3D=3D=3D 4. Comment on an establishment of security associations in= a > >> DMM > >>>> environment. =3D=3D=3D For each IP mobility support protocol, differ= ent > >> security > >>> associations (SAs) are required for providing secure mobility > >> services to MNs > >>> as follows: > >>>> > >>>> 1) MIPv6 > >>>> 1.1 SA between MN and HA. > >>>> 1.2 SA between MN and serving access router (AR) providing > wireless > >> link > >>> to the MN. > >>>> > >>>> 2) Fast Handover MIPv6 (FMIPv6) > >>>> 2.1 SA between MN and HA. > >>>> 2.2 SA between MN and serving AR. > >>>> 2.3 SA between previous and new ARs. > >>>> > >>>> 3) PMIPv6 > >>>> 3.1 SA between MN and serving MAG. > >>>> 3.2 SA between serving MAG and LMA. > >>>> > >>>> 4) Fast Handover PMIPv6 (FPMIPv6) > >>>> 4.1 SA between MN and serving MAG. > >>>> 4.2 SA between serving MAG and LMA. > >>>> 4.3 SA between previous and new MAGs. > >>>> > >>>> Note that the above ones do not consider the cases of SA with a > >> security- > >>> backend server (e.g., AAA server) and with a correspondent node > (CN). > >>>> > >>>> However, depending on DMM solutions, SAs are configured that are > >>>> different from those of the existing IP mobility support > protocols. > >>>> For instance, > >>>> > >>>> 1) the case of "MN sends mobility signaling to its all mobility > >>>> anchors" (client-based mobility solution) > >>>> 1.1 SA between MN and serving mobility anchor providing wireless > >> link to > >>> the MN. > >>>> 1.2 SA between MN and origin mobility anchors, i.e., (n - 1) SAs > >> required > >>> with MN and origin mobility anchors. > >>>> > >>>> 2) the case of "MN sends mobility signaling only to its serving > >>>> mobility anchor" (client-based mobility solution) > >>>> 2.1 SA between MN and serving mobility anchor. > >>>> 2.2 SA between serving mobility anchor and origin mobility > anchors, > >> i.e., (n > >>> - 1) SAs required with serving mobility anchor and origin mobility > >> anchors. > >>>> > >>>> 3) the case of "serving mobility anchor sends signaling on behalf > >> of > >>>> the MN to origin mobility anchors" (network-based mobility > >> solution) > >>>> 3.1 SA between MN and serving mobility anchor. > >>>> 3.2 SA between serving mobility anchor and origin mobility > anchors, > >> i.e., (n > >>> - 1) SAs required with serving mobility anchor and origin mobility > >> anchors. > >>>> > >>>> Note that as like before SAs with a security-backend server (e.g., > >> AAA > >>> server) and with a CN are not presented. > >>>> > >>>> As shown above, DMM solutions (that relies on bidirectional > >> tunnelings for > >>> packet forwarding between MN and mobility anchors or between just > >>> mobility anchors) might bring the key management issues to > establish > >> such > >>> SAs. > >>>> > >>>> Since it's a holiday season, I cannot fully address all of them in > >> my mind, but > >>> kindly consider these ones. > >>>> > >>>> Cheers. > >>>> > >>>> -- > >>>> 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/ > >>>> > >>>> _______________________________________________ > >>>> 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 > > > > > ______________________________________________________________________ > > ________ ___________________________________________ > > > > Ce message et ses pieces jointes peuvent contenir des informations > > confidentielles ou privilegiees et ne doivent donc pas etre diffuses, > > exploites ou copies sans autorisation. Si vous avez recu ce message > > par erreur, veuillez le signaler a l'expediteur et le detruire ainsi > > que les pieces jointes. Les messages electroniques etant susceptibles > > d'alteration, France Telecom - Orange decline toute responsabilite si > > ce message a ete altere, deforme ou falsifie. Merci. > > > > This message and its attachments may contain confidential or > > privileged information that may be protected by law; they should not > > be distributed, used or copied without authorisation. > > If you have received this email in error, please notify the sender > and > > delete this message and its attachments. > > As emails may be altered, France Telecom - Orange is not liable for > > messages that have been modified, changed or falsified. > > Thank you. > > ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, France Telecom - Orange decline toute responsabilite si ce message a ete al= tere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, France Telecom - Orange is not liable for message= s that have been modified, changed or falsified. Thank you. From sarikaya2012@gmail.com Thu Sep 20 09:19:18 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 7A34021F870B for ; Thu, 20 Sep 2012 09:19:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.74 X-Spam-Level: X-Spam-Status: No, score=-2.74 tagged_above=-999 required=5 tests=[AWL=-0.381, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, SARE_LWSHORTT=1.24] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VdntnHO2PWRz for ; Thu, 20 Sep 2012 09:19:16 -0700 (PDT) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 5E6F021F8709 for ; Thu, 20 Sep 2012 09:19:16 -0700 (PDT) Received: by iabz21 with SMTP id z21so2056031iab.31 for ; Thu, 20 Sep 2012 09:19:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:content-transfer-encoding; bh=m761hpjZ3lRKZwCddGzWgxi2oOcHv1usPFBSmJmMHyQ=; b=OhaAlMi+wfblclhBSbW12H1EHIBFlJep0RIgyunMg91ts0R5YfuLKOwqkgAuKMmH4J QR2udkMVNyRxMZ381pHk6ckbG22I2zUy/rfnYSu71eu059Ze1L/WUldJoQwMablnJhfd D44QCTb6+Y5i8h9nd+5HKGNhp5HYnukf8qnAv8GwVlDpM+z9RST1HkHxC7FQdk243fET vAXuqmqfdCK3CRUzFBz9MZ+p4vQsvFy8UOQqRqSwPkBbMJO9Yg+ntG0PFtK9+DRbN6n/ maXEOtnlxN0eh6UCucBoPpF6pmXMR2PW5HIN6b9MPKUXPmCP4zrKA3YdmJrs/+fNeGyc KN4g== MIME-Version: 1.0 Received: by 10.43.45.200 with SMTP id ul8mr1835832icb.36.1348157955542; Thu, 20 Sep 2012 09:19:15 -0700 (PDT) Received: by 10.231.55.70 with HTTP; Thu, 20 Sep 2012 09:19:15 -0700 (PDT) In-Reply-To: References: <13040_1348059786_5059C28A_13040_17047_1_81C77F07008CA24F9783A98CFD706F71038847@PEXCVZYM12.corporate.adroot.infra.ftgroup> Date: Thu, 20 Sep 2012 11:19:15 -0500 Message-ID: From: Behcet Sarikaya To: Jouni Korhonen Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "dmm@ietf.org" Subject: Re: [DMM] Comments on DMM Gap Analysis. X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: sarikaya@ieee.org List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Sep 2012 16:19:18 -0000 Hi Jouni, Isn't the gap obvious? Has this not yet been discussed already? The gap is the use of a central anchor. Yes there is possibility of LMA/HA selection but it is not dynamic. Why can't we document this in a document quickly and move on? What we need to do is to document the implications of moving away from this single anchoring towards dynamic anchoring or DMM. As I mentioned, what is the impact of cloud networks in DMM? As you mentioned, we should also consider 3GPP case, i.e. GTP which brings control plane/data plane separation. What are the impact of DMM in control/data plane separation? I think to write a document on these is the real challenge. Regards, Behcet On Thu, Sep 20, 2012 at 3:34 AM, Jouni Korhonen wr= ote: > Pierrick, > > On 9/19/12 4:03 PM, "ext pierrick.seite@orange.com" > wrote: > >> Hi Jouni and Julien, >> >> >> Sorry for jumping into the discussion but I'm a little bit confused with >> recent discussions in DMM. So, let me ask for clarifications about the s= cope >> of the gap analysis... >> >> The WG is now tackling with the work item 'Practices and Gap Analysis' a= nd, in >> my understanding, we are expected to provide a gap analysis regarding th= e use >> of mobility protocols in a distributed mobility management environment. >> However, it seems that the scope of discussions on gap analysis is >> different.... and I'm confused :-) > > The "distributed" environment would be what we have now.. Like if you > operate a network that has more than one anchor node, you can consider th= at > as a system which could enable distribution. And if e.g. anchor distribut= ion > is possible/done today that would be documented (example: LMA selection > during the attach time based on geographical location). > > o Practices: Document practices for the deployment of existing > mobility protocols in a distributed mobility management > environment. > > Gap analysis is then based on that.. and > >> Actually, in the charter, we agreed to firstly "document practices for t= he >> deployment of existing mobility protocols in a distributed mobility mana= gement > > ..during the meeting I asked the question whether we deal current practic= es > and gap analysis in the same document, since there are conflicting > milestones. There was no clear answer from the room as far as I remember > (and minutes indicate). > > I am (still) on the opinion that these two can and probably should be the > one same document. There are not too many current practices given the rat= her > low number of _really_deployed_ IP mobility technologies that we can writ= e > meaningful current practices about. Then you would do the gap analysis > against those. > >> environment" and, then, to make the gap analysis. However, considering c= urrent >> discussions on "gap analysis": the document on practices has been omitte= d and >> discussions are about vanilla mobility protocols and architectures with >> respect to DMM requirements. So, maybe, such considerations are interest= ing in >> the scope of the problem statement, but it seems to me that it is not th= e goal >> of the gap analysis, as initially intended in the charter. Am I missing >> something? > > I should have been clearer that I would like to see these two combined. > o Submit I-D 'Practices and Gap Analysis' as a working group document. > > That also kind of forces strict scoping of mobility technologies I mentio= ned > about in my earlier mail. > > I don't want to see a current practices or gap analysis of solutions that > has no relation to an existing and rather short term planned deployment > reality.. > >> If I refer to previous DMM charter (because current DMM charter is empty= ... >> BTW, is there a reason for an empty charter?), one Work item was: "Docum= ent > > There are issues between datatracker and tools coordination or something. > Tools guys are on this. You can find older(?) version of the charter on t= he > tools page and yesterday the charter re-appeared again to datatracker. > >> practices for the deployment of existing mobility protocols in a distrib= uted >> mobility management environment". Is this document still in DMM stuff? = If >> yes, shouldn't we document practices before going into the gap analysis? > > Mmm yes. But if you combine both you should be fine too. If folks think a= nd > insist that there shall be a current practices as a separate document, so= be > it. > > - Jouni > > > >> >> 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 : mercredi 19 septembre 2012 13:11 >>> =C0 : jouni.nospam@gmail.com; dmm@ietf.org; h.anthony.chan@huawei.com; >>> JuanCarlos.Zuniga@interdigital.com >>> Cc : dmm-chairs@tools.ietf.org >>> Objet : Re: [DMM] Comments on DMM Gap Analysis. >>> >>> Hi Jouni, Hi all, >>> >>> After discussing this issue with Carlos Jes=FAs Bernardos and Juan Carl= os >>> Zuniga, we concluded that the following set of possible technologies >>> could be included in the Gap analysis draft: >>> >>> =3D> Shim6: Level 3 Multihoming Shim Protocol for IPv6 http://www.rfc- >>> editor.org/rfc/rfc5533.txt >>> >>> >>> =3D> LISP Mobile Node >>> http://www.ietf.org/id/draft-meyer-lisp-mn-07.txt >>> Locator/ID Separation Protocol (LISP) >>> http://www.ietf.org/id/draft-ietf-lisp-23.txt >>> >>> =3D> Mobile IPv6 Fast Handovers >>> http://tools.ietf.org/id/draft-ietf-mipshop-rfc5268bis-01.txt >>> This is the draft that became then RFC5568, so no need to mention it. >>> http://www.rfc-editor.org/rfc/rfc5568.txt >>> >>> >>> =3D> Fast Handovers for Proxy Mobile IPv6 >>> http://www.rfc-editor.org/rfc/rfc5949.txt >>> >>> =3D> Host Identity Protocol >>> http://www.rfc-editor.org/rfc/rfc4423.txt >>> http://www.rfc-editor.org/rfc/rfc5201.txt >>> http://www.rfc-editor.org/rfc/rfc6253.txt >>> http://www.rfc-editor.org/rfc/rfc5206.txt >>> >>> >>> >>> =3D> IKEv2 Mobility and Multihoming Protocol (MOBIKE) >>> http://www.rfc-editor.org/rfc/rfc4555.txt >>> >>> >>> =3D> GTPv2-C: 3rd Generation Partnership Project; Technical Specificati= on >>> Group Core Network and Terminals; 3GPP Evolved Packet System (EPS); >>> Evolved General Packet Radio Service (GPRS) Tunnelling Protocol for >>> Control plane (GTPv2-C); Stage 3 (Release 11) >>> http://www.3gpp.org/ftp/Specs/archive/29_series/29.274/29274-b30.zip >>> >>> Please inform us if this list makes sense to you? >>> >>> Best regards, >>> Georgios >>> >>> >>>> -----Original Message----- >>>> From: dmm-bounces@ietf.org [mailto:dmm-bounces@ietf.org] On Behalf Of >>>> jouni korhonen >>>> Sent: woensdag 19 september 2012 9:58 >>>> To: dmm@ietf.org; h chan; Juan Carlos Zuniga >>>> Cc: dmm-chairs@tools.ietf.org >>>> Subject: Re: [DMM] Comments on DMM Gap Analysis. >>>> >>>> >>>> Folks, >>>> >>>> It has been rather silent on the list recently. Regarding the >>> "explosion" of >>>> possible technologies in the GAP analysis, we discussed (chairs) that >>> it is >>>> better to scope the area "a bit". The charter today has the >>> assumption that >>>> we build on top of existing _IP_ _Mobility_ protocols (and bunch of >>> IETF >>>> defined examples follow). So, to tighten the scope, the Gap Analysis >>> should >>>> leave all routing, session (SIP, ..), transport (MPTCP, SCTP, DCCP, >>> ..), >>>> locator/identifier split (HIP, Lisp, ..), naming (DNS tricks, ..) etc >>> based >>>> solutions out. Coarse but should help us to make progress. We could >>> discuss >>>> whether transport layer solution like SCTP fit in but I do not see >>> them as end- >>>> 2-end solutions being deployable in Internet at the moment. >>>> >>>> Let us stick with technologies out there that have/had a place in >>> sun: few >>>> MIP variants, MOBIKE, stuff in 3GPP(2) (oops.. but I think this >>> deserves to be >>>> evaluated since they are somewhat popular), and what applications do >>>> (reconnecting..). This analysis should be down to earth practical and >>> realistic >>>> on what is already out there to play with. >>>> >>>> - Jouni & Julien >>>> >>>> >>>> >>>> On Jul 27, 2012, at 3:53 PM, Jong-Hyouk Lee wrote: >>>> >>>>> Dear Anthony and Juan. >>>>> >>>>> I enjoyed the both gap analysis documents (draft-chan-dmm- >>> framework- >>>> gap-analysis-02 and draft-zuniga-dmm-gap-analysis-01). Here I give >>> some >>>> comments that should be used directly in the gap analysis documents >>> if you >>>> guys like. >>>>> >>>>> Kindly consider the followings during the gap analysis discussion >>> (since I will >>>> not be attending the IETF meeting this time). >>>>> >>>>> 1. Comment on address (resource) management in a DMM environment. >>>>> 2. Comment on a deployment of a client-based mobility solution >>> (i.e., >>>> MIPv6) in a DMM environment. >>>>> 3. Commnet on neighbor mobility anchors' information in a DMM >>>> environment. >>>>> 4. Commnet on an establishment of security associations in a DMM >>>> environment. >>>>> >>>>> =3D=3D=3D 1. Comment on address (resource) management in a DMM >>>> environment. >>>>> =3D=3D=3D When existing IP mobility support protocols (e.g., MIPv6 an= d >>> PMIPv6) >>>> are considered to be deployed in a DMM environment, a mobile node >>> (MN) >>>> is allowed to configure a new address while keeping its previous >>> address(es). >>>> It introduces the following differences with the address (resource) >>>> management of the existing ones: >>>>> >>>>> MN's address configured at the interface with a DMM environment: n >>> =3D >>>>> (IP address at the current access network + previously configured >>> IP >>>>> address(es) with ongoing sessions) MN's address configured at the >>>>> interface without a DMM environment: 1 =3D (care-of address in MIPv6 >>> or >>>>> MN's home address in PMIPv6) >>>>> >>>>> This leads a couple of considerations we didn't have with the >>> existing >>>>> IP mobility support protocols. For instance, >>>>> >>>>> 1) MN's address management: use of a newly configured address at >>> the >>>> current access network for new communication sessions while a proper >>>> address selection for previously established ongoing communication >>>> sessions. >>>>> >>>>> 2) Additional treatment for ingress filtering: Ingress filtering is >>> widely used >>>> against source address spoofing. The source addresses (especially, >>> the >>>> network prefix part) of incoming packets are strictly checked to make >>> sure >>>> that those packets are actually from the network that they claim to >>> be from. >>>> As the MN are allowed to send data packets with the previously >>> configured >>>> address(es) at the new access network, those data packets would be >>> filtered >>>> at the ingress filtering place because the source address of those >>> data >>>> packets is not belonging to the new access network. Accordingly, an >>>> additional treatment for ingress filtering is required. >>>>> >>>>> 3) MN's address increase at the MN's interface: Recall the number >>> of MN's >>>> address configured at an interface is n. Then, n is increased, as the >>> MN >>>> changes its point of attachment while keeping its ongoing >>> communication >>>> sessions. It brings the question: "How many addresses are currently >>> possible >>>> to be configured at an interface?" >>>>> >>>>> 4) Routing entry increase at the serving mobility anchor: Let the >>> serving >>>> mobility anchor is the mobility anchor serves the MN. Traffic >>> associated to >>>> the MN travels via the serving mobility anchor. The increase of the >>> addresses >>>> associated to the MN, n, is not only concerning to the MN, but also >>>> concerning the serving mobility anchor as it contributes the increase >>> of >>>> routing entries for the MN. >>>>> >>>>> =3D=3D=3D 2. Comment on a deployment of a client-based mobility solut= ion >>>>> (i.e., MIPv6) in a DMM environment. =3D=3D=3D When a client-based >>> mobility >>>> solution (i.e., MIPv6) is consiered to be deployed in a DMM >>> environment, an >>>> MN is involved in mobility signaling such as Binding Update and >>>> Acknowledgement messages. This is the big difference with the >>> network- >>>> based mobility solution (i.e., PMIPv6). As the MN send signaling to >>> inform its >>>> movement to its mobility anchor, the client-based mobility solution >>> allows >>>> the MN to supply client-centric decision for mobility management. >>>>> >>>>> Suppose that the origin mobility anchor is the mobility anchor >>> where the >>>> MN has configured its IP address and established ongoing >>> communication >>>> sessions with the IP address. The number of origin mobility anchors >>> are n - 1. >>>> Recall that the serving mobility anchor is the mobility anchor where >>> the MN is >>>> being served by. Then, the MN's involvement in mobility signaling >>> brings us >>>> the questions: "Should we let the MN send mobilty signaling to its >>> all mobility >>>> anchors?" or "Would it make sense that the MN only sends mobility >>> signaling >>>> to its serving mobility anchor?" Depending on the choice, we will >>> have >>>> different results: >>>>> >>>>> 1) "MN sends mobility signaling to its all mobility anchors" >>> causes: >>>>> 1.1 increased mobility signaling load, e.g., signaling * (n - 1). >>>>> 1.2 bidirectional tunnels are established between the MN and its >>> mobility >>>> anchors. >>>>> 1.3 tunneling overhead over the air is present. >>>>> 1.4 but the tunnels are terminated at the MN so that the MN has >>> control >>>> over the tunnels. >>>>> >>>>> 2) "MN sends mobility signaling only to its serving mobility >>> anchor" causes: >>>>> 2.1 reduced mobility signaling load, e.g., signaling * 1. >>>>> 2.2 bidirectional tunnels are established between the serving >>> mobility >>>> anchors and origin mobility anchors. >>>>> 2.3 tunneling overhead over the air can be avoided. >>>>> 2.4 but the MN does not have control over the tunnels so it might >>> affect to >>>> NEtwork MObility (NEMO) as the MN (i.e., MR in NEMO) loses the >>> tunneling >>>> control. >>>>> >>>>> =3D=3D=3D 3. Neighbor mobility anchors' information in a DMM environm= ent. >>>>> =3D=3D=3D In the client-based mobility solution such as MIPv6, the >>> network >>>> topology information does not required to be known to the mobility >>> anchor, >>>> i.e., home agent (HA), since the HA is informed the current location >>> of the >>>> MN. As the HA knows the current location of the MN, it is able to >>> tunnel >>>> packets associated to the MN. In the network-based mobility solution >>> such >>>> as PMIPv6, the similar things happen, i.e., the tunnel between the >>> local >>>> mobility anchor (LMA) and the mobile access gateway (MAG) is >>> established >>>> for a given MN. >>>>> >>>>> However, as mobility anchors are distributed and bidirectional >>> tunnels (for >>>> a given MN) between the distributed mobility anchors are required, >>> the >>>> neighbor mobility anchors' information should be provided to the MN >>> or the >>>> mobility anchor for the establishment of the directional tunnels or >>> the >>>> update of the MN's current location. >>>>> >>>>> Decoupling the data plane and control plane while keeping a >>> centralized >>>> node maintaining the mobility context including neighbor mobility >>> anchors' >>>> information (e.g., identification, IP address, etc) in a DMM >>> environment is >>>> one of possible solutions. >>>>> >>>>> =3D=3D=3D 4. Comment on an establishment of security associations in = a >>> DMM >>>>> environment. =3D=3D=3D For each IP mobility support protocol, differe= nt >>> security >>>> associations (SAs) are required for providing secure mobility >>> services to MNs >>>> as follows: >>>>> >>>>> 1) MIPv6 >>>>> 1.1 SA between MN and HA. >>>>> 1.2 SA between MN and serving access router (AR) providing wireless >>> link >>>> to the MN. >>>>> >>>>> 2) Fast Handover MIPv6 (FMIPv6) >>>>> 2.1 SA between MN and HA. >>>>> 2.2 SA between MN and serving AR. >>>>> 2.3 SA between previous and new ARs. >>>>> >>>>> 3) PMIPv6 >>>>> 3.1 SA between MN and serving MAG. >>>>> 3.2 SA between serving MAG and LMA. >>>>> >>>>> 4) Fast Handover PMIPv6 (FPMIPv6) >>>>> 4.1 SA between MN and serving MAG. >>>>> 4.2 SA between serving MAG and LMA. >>>>> 4.3 SA between previous and new MAGs. >>>>> >>>>> Note that the above ones do not consider the cases of SA with a >>> security- >>>> backend server (e.g., AAA server) and with a correspondent node (CN). >>>>> >>>>> However, depending on DMM solutions, SAs are configured that are >>>>> different from those of the existing IP mobility support protocols. >>>>> For instance, >>>>> >>>>> 1) the case of "MN sends mobility signaling to its all mobility >>>>> anchors" (client-based mobility solution) >>>>> 1.1 SA between MN and serving mobility anchor providing wireless >>> link to >>>> the MN. >>>>> 1.2 SA between MN and origin mobility anchors, i.e., (n - 1) SAs >>> required >>>> with MN and origin mobility anchors. >>>>> >>>>> 2) the case of "MN sends mobility signaling only to its serving >>>>> mobility anchor" (client-based mobility solution) >>>>> 2.1 SA between MN and serving mobility anchor. >>>>> 2.2 SA between serving mobility anchor and origin mobility anchors, >>> i.e., (n >>>> - 1) SAs required with serving mobility anchor and origin mobility >>> anchors. >>>>> >>>>> 3) the case of "serving mobility anchor sends signaling on behalf >>> of >>>>> the MN to origin mobility anchors" (network-based mobility >>> solution) >>>>> 3.1 SA between MN and serving mobility anchor. >>>>> 3.2 SA between serving mobility anchor and origin mobility anchors, >>> i.e., (n >>>> - 1) SAs required with serving mobility anchor and origin mobility >>> anchors. >>>>> >>>>> Note that as like before SAs with a security-backend server (e.g., >>> AAA >>>> server) and with a CN are not presented. >>>>> >>>>> As shown above, DMM solutions (that relies on bidirectional >>> tunnelings for >>>> packet forwarding between MN and mobility anchors or between just >>>> mobility anchors) might bring the key management issues to establish >>> such >>>> SAs. >>>>> >>>>> Since it's a holiday season, I cannot fully address all of them in >>> my mind, but >>>> kindly consider these ones. >>>>> >>>>> Cheers. >>>>> >>>>> -- >>>>> 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/ >>>>> >>>>> _______________________________________________ >>>>> 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 >> >> ________________________________________________________________________= ______ >> ___________________________________________ >> >> Ce message et ses pieces jointes peuvent contenir des informations >> confidentielles ou privilegiees et ne doivent donc >> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez r= ecu ce >> message par erreur, veuillez le signaler >> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages >> electroniques etant susceptibles d'alteration, >> France Telecom - Orange decline toute responsabilite si ce message a ete >> altere, deforme ou falsifie. Merci. >> >> This message and its attachments may contain confidential or privileged >> information that may be protected by law; >> they should not be distributed, used or copied without authorisation. >> If you have received this email in error, please notify the sender and d= elete >> this message and its attachments. >> As emails may be altered, France Telecom - Orange is not liable for mess= ages >> that have been modified, changed or falsified. >> Thank you. >> > > _______________________________________________ > dmm mailing list > dmm@ietf.org > https://www.ietf.org/mailman/listinfo/dmm From karagian@cs.utwente.nl Fri Sep 21 01:29: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 BE5BB21F8780 for ; Fri, 21 Sep 2012 01:29:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.116 X-Spam-Level: X-Spam-Status: No, score=0.116 tagged_above=-999 required=5 tests=[AWL=-0.620, BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, SARE_LWSHORTT=1.24] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N4YhuYWwvQgB for ; Fri, 21 Sep 2012 01:29:45 -0700 (PDT) Received: from EXEDGE02.ad.utwente.nl (exedge02.ad.utwente.nl [130.89.5.49]) by ietfa.amsl.com (Postfix) with ESMTP id F0D2121F877A for ; Fri, 21 Sep 2012 01:29:44 -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, 21 Sep 2012 10:29:38 +0200 Received: from EXMBX04.ad.utwente.nl ([169.254.4.4]) by EXHUB01.ad.utwente.nl ([130.89.4.228]) with mapi id 14.01.0339.001; Fri, 21 Sep 2012 10:29:38 +0200 From: To: , Thread-Topic: [DMM] Comments on DMM Gap Analysis. Thread-Index: AQHNa/boI0rituCWdkGdrm+e/9iWcJeRf28AgABUdWCAAADegIABR02AgACB1oCAATBA0A== Date: Fri, 21 Sep 2012 08:29:38 +0000 Message-ID: References: <13040_1348059786_5059C28A_13040_17047_1_81C77F07008CA24F9783A98CFD706F71038847@PEXCVZYM12.corporate.adroot.infra.ftgroup> In-Reply-To: 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] Comments on DMM Gap Analysis. 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, 21 Sep 2012 08:29:47 -0000 Dear all, I also agree with Behcet that the impact of cloud networks in DMM should al= so be included! Best regards, Georgios > -----Original Message----- > From: dmm-bounces@ietf.org [mailto:dmm-bounces@ietf.org] On Behalf Of > Behcet Sarikaya > Sent: donderdag 20 september 2012 18:19 > To: Jouni Korhonen > Cc: dmm@ietf.org > Subject: Re: [DMM] Comments on DMM Gap Analysis. >=20 > Hi Jouni, >=20 > Isn't the gap obvious? Has this not yet been discussed already? The gap i= s the > use of a central anchor. Yes there is possibility of LMA/HA selection but= it is > not dynamic. >=20 > Why can't we document this in a document quickly and move on? >=20 > What we need to do is to document the implications of moving away from > this single anchoring towards dynamic anchoring or DMM. As I mentioned, > what is the impact of cloud networks in DMM? >=20 > As you mentioned, we should also consider 3GPP case, i.e. GTP which bring= s > control plane/data plane separation. What are the impact of DMM in > control/data plane separation? >=20 > I think to write a document on these is the real challenge. >=20 > Regards, >=20 > Behcet >=20 > On Thu, Sep 20, 2012 at 3:34 AM, Jouni Korhonen > wrote: > > Pierrick, > > > > On 9/19/12 4:03 PM, "ext pierrick.seite@orange.com" > > wrote: > > > >> Hi Jouni and Julien, > >> > >> > >> Sorry for jumping into the discussion but I'm a little bit confused > >> with recent discussions in DMM. So, let me ask for clarifications > >> about the scope of the gap analysis... > >> > >> The WG is now tackling with the work item 'Practices and Gap > >> Analysis' and, in my understanding, we are expected to provide a gap > >> analysis regarding the use of mobility protocols in a distributed mob= ility > management environment. > >> However, it seems that the scope of discussions on gap analysis is > >> different.... and I'm confused :-) > > > > The "distributed" environment would be what we have now.. Like if you > > operate a network that has more than one anchor node, you can consider > > that as a system which could enable distribution. And if e.g. anchor > > distribution is possible/done today that would be documented (example: > > LMA selection during the attach time based on geographical location). > > > > o Practices: Document practices for the deployment of existing > > mobility protocols in a distributed mobility management > > environment. > > > > Gap analysis is then based on that.. and > > > >> Actually, in the charter, we agreed to firstly "document practices > >> for the deployment of existing mobility protocols in a distributed > >> mobility management > > > > ..during the meeting I asked the question whether we deal current > > practices and gap analysis in the same document, since there are > > conflicting milestones. There was no clear answer from the room as far > > as I remember (and minutes indicate). > > > > I am (still) on the opinion that these two can and probably should be > > the one same document. There are not too many current practices given > > the rather low number of _really_deployed_ IP mobility technologies > > that we can write meaningful current practices about. Then you would > > do the gap analysis against those. > > > >> environment" and, then, to make the gap analysis. However, > >> considering current discussions on "gap analysis": the document on > >> practices has been omitted and discussions are about vanilla mobility > >> protocols and architectures with respect to DMM requirements. So, > >> maybe, such considerations are interesting in the scope of the > >> problem statement, but it seems to me that it is not the goal of the > >> gap analysis, as initially intended in the charter. Am I missing somet= hing? > > > > I should have been clearer that I would like to see these two combined. > > o Submit I-D 'Practices and Gap Analysis' as a working group document. > > > > That also kind of forces strict scoping of mobility technologies I > > mentioned about in my earlier mail. > > > > I don't want to see a current practices or gap analysis of solutions > > that has no relation to an existing and rather short term planned > > deployment reality.. > > > >> If I refer to previous DMM charter (because current DMM charter is > empty... > >> BTW, is there a reason for an empty charter?), one Work item was: > >> "Document > > > > There are issues between datatracker and tools coordination or somethin= g. > > Tools guys are on this. You can find older(?) version of the charter > > on the tools page and yesterday the charter re-appeared again to > datatracker. > > > >> practices for the deployment of existing mobility protocols in a > >> distributed mobility management environment". Is this document still > >> in DMM stuff? If yes, shouldn't we document practices before going int= o > the gap analysis? > > > > Mmm yes. But if you combine both you should be fine too. If folks > > think and insist that there shall be a current practices as a separate > > document, so be it. > > > > - Jouni > > > > > > > >> > >> 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 : mercredi 19 septembre 2012 13:11 > >>> =C0 : jouni.nospam@gmail.com; dmm@ietf.org; > h.anthony.chan@huawei.com; > >>> JuanCarlos.Zuniga@interdigital.com > >>> Cc : dmm-chairs@tools.ietf.org > >>> Objet : Re: [DMM] Comments on DMM Gap Analysis. > >>> > >>> Hi Jouni, Hi all, > >>> > >>> After discussing this issue with Carlos Jes=FAs Bernardos and Juan > >>> Carlos Zuniga, we concluded that the following set of possible > >>> technologies could be included in the Gap analysis draft: > >>> > >>> =3D> Shim6: Level 3 Multihoming Shim Protocol for IPv6 http://www.rfc= - > >>> editor.org/rfc/rfc5533.txt > >>> > >>> > >>> =3D> LISP Mobile Node > >>> http://www.ietf.org/id/draft-meyer-lisp-mn-07.txt > >>> Locator/ID Separation Protocol (LISP) > >>> http://www.ietf.org/id/draft-ietf-lisp-23.txt > >>> > >>> =3D> Mobile IPv6 Fast Handovers > >>> http://tools.ietf.org/id/draft-ietf-mipshop-rfc5268bis-01.txt > >>> This is the draft that became then RFC5568, so no need to mention it. > >>> http://www.rfc-editor.org/rfc/rfc5568.txt > >>> > >>> > >>> =3D> Fast Handovers for Proxy Mobile IPv6 > >>> http://www.rfc-editor.org/rfc/rfc5949.txt > >>> > >>> =3D> Host Identity Protocol > >>> http://www.rfc-editor.org/rfc/rfc4423.txt > >>> http://www.rfc-editor.org/rfc/rfc5201.txt > >>> http://www.rfc-editor.org/rfc/rfc6253.txt > >>> http://www.rfc-editor.org/rfc/rfc5206.txt > >>> > >>> > >>> > >>> =3D> IKEv2 Mobility and Multihoming Protocol (MOBIKE) > >>> http://www.rfc-editor.org/rfc/rfc4555.txt > >>> > >>> > >>> =3D> GTPv2-C: 3rd Generation Partnership Project; Technical > >>> Specification Group Core Network and Terminals; 3GPP Evolved Packet > >>> System (EPS); Evolved General Packet Radio Service (GPRS) Tunnelling > >>> Protocol for Control plane (GTPv2-C); Stage 3 (Release 11) > >>> http://www.3gpp.org/ftp/Specs/archive/29_series/29.274/29274- > b30.zip > >>> > >>> Please inform us if this list makes sense to you? > >>> > >>> Best regards, > >>> Georgios > >>> > >>> > >>>> -----Original Message----- > >>>> From: dmm-bounces@ietf.org [mailto:dmm-bounces@ietf.org] On > Behalf > >>>> Of jouni korhonen > >>>> Sent: woensdag 19 september 2012 9:58 > >>>> To: dmm@ietf.org; h chan; Juan Carlos Zuniga > >>>> Cc: dmm-chairs@tools.ietf.org > >>>> Subject: Re: [DMM] Comments on DMM Gap Analysis. > >>>> > >>>> > >>>> Folks, > >>>> > >>>> It has been rather silent on the list recently. Regarding the > >>> "explosion" of > >>>> possible technologies in the GAP analysis, we discussed (chairs) > >>>> that > >>> it is > >>>> better to scope the area "a bit". The charter today has the > >>> assumption that > >>>> we build on top of existing _IP_ _Mobility_ protocols (and bunch of > >>> IETF > >>>> defined examples follow). So, to tighten the scope, the Gap > >>>> Analysis > >>> should > >>>> leave all routing, session (SIP, ..), transport (MPTCP, SCTP, > >>>> DCCP, > >>> ..), > >>>> locator/identifier split (HIP, Lisp, ..), naming (DNS tricks, ..) > >>>> etc > >>> based > >>>> solutions out. Coarse but should help us to make progress. We could > >>> discuss > >>>> whether transport layer solution like SCTP fit in but I do not see > >>> them as end- > >>>> 2-end solutions being deployable in Internet at the moment. > >>>> > >>>> Let us stick with technologies out there that have/had a place in > >>> sun: few > >>>> MIP variants, MOBIKE, stuff in 3GPP(2) (oops.. but I think this > >>> deserves to be > >>>> evaluated since they are somewhat popular), and what applications > >>>> do (reconnecting..). This analysis should be down to earth > >>>> practical and > >>> realistic > >>>> on what is already out there to play with. > >>>> > >>>> - Jouni & Julien > >>>> > >>>> > >>>> > >>>> On Jul 27, 2012, at 3:53 PM, Jong-Hyouk Lee wrote: > >>>> > >>>>> Dear Anthony and Juan. > >>>>> > >>>>> I enjoyed the both gap analysis documents (draft-chan-dmm- > >>> framework- > >>>> gap-analysis-02 and draft-zuniga-dmm-gap-analysis-01). Here I give > >>> some > >>>> comments that should be used directly in the gap analysis documents > >>> if you > >>>> guys like. > >>>>> > >>>>> Kindly consider the followings during the gap analysis discussion > >>> (since I will > >>>> not be attending the IETF meeting this time). > >>>>> > >>>>> 1. Comment on address (resource) management in a DMM > environment. > >>>>> 2. Comment on a deployment of a client-based mobility solution > >>> (i.e., > >>>> MIPv6) in a DMM environment. > >>>>> 3. Commnet on neighbor mobility anchors' information in a DMM > >>>> environment. > >>>>> 4. Commnet on an establishment of security associations in a DMM > >>>> environment. > >>>>> > >>>>> =3D=3D=3D 1. Comment on address (resource) management in a DMM > >>>> environment. > >>>>> =3D=3D=3D When existing IP mobility support protocols (e.g., MIPv6 = and > >>> PMIPv6) > >>>> are considered to be deployed in a DMM environment, a mobile node > >>> (MN) > >>>> is allowed to configure a new address while keeping its previous > >>> address(es). > >>>> It introduces the following differences with the address (resource) > >>>> management of the existing ones: > >>>>> > >>>>> MN's address configured at the interface with a DMM environment: n > >>> =3D > >>>>> (IP address at the current access network + previously configured > >>> IP > >>>>> address(es) with ongoing sessions) MN's address configured at the > >>>>> interface without a DMM environment: 1 =3D (care-of address in MIPv= 6 > >>> or > >>>>> MN's home address in PMIPv6) > >>>>> > >>>>> This leads a couple of considerations we didn't have with the > >>> existing > >>>>> IP mobility support protocols. For instance, > >>>>> > >>>>> 1) MN's address management: use of a newly configured address at > >>> the > >>>> current access network for new communication sessions while a > >>>> proper address selection for previously established ongoing > >>>> communication sessions. > >>>>> > >>>>> 2) Additional treatment for ingress filtering: Ingress filtering > >>>>> is > >>> widely used > >>>> against source address spoofing. The source addresses (especially, > >>> the > >>>> network prefix part) of incoming packets are strictly checked to > >>>> make > >>> sure > >>>> that those packets are actually from the network that they claim to > >>> be from. > >>>> As the MN are allowed to send data packets with the previously > >>> configured > >>>> address(es) at the new access network, those data packets would be > >>> filtered > >>>> at the ingress filtering place because the source address of those > >>> data > >>>> packets is not belonging to the new access network. Accordingly, an > >>>> additional treatment for ingress filtering is required. > >>>>> > >>>>> 3) MN's address increase at the MN's interface: Recall the number > >>> of MN's > >>>> address configured at an interface is n. Then, n is increased, as > >>>> the > >>> MN > >>>> changes its point of attachment while keeping its ongoing > >>> communication > >>>> sessions. It brings the question: "How many addresses are currently > >>> possible > >>>> to be configured at an interface?" > >>>>> > >>>>> 4) Routing entry increase at the serving mobility anchor: Let the > >>> serving > >>>> mobility anchor is the mobility anchor serves the MN. Traffic > >>> associated to > >>>> the MN travels via the serving mobility anchor. The increase of the > >>> addresses > >>>> associated to the MN, n, is not only concerning to the MN, but also > >>>> concerning the serving mobility anchor as it contributes the > >>>> increase > >>> of > >>>> routing entries for the MN. > >>>>> > >>>>> =3D=3D=3D 2. Comment on a deployment of a client-based mobility sol= ution > >>>>> (i.e., MIPv6) in a DMM environment. =3D=3D=3D When a client-based > >>> mobility > >>>> solution (i.e., MIPv6) is consiered to be deployed in a DMM > >>> environment, an > >>>> MN is involved in mobility signaling such as Binding Update and > >>>> Acknowledgement messages. This is the big difference with the > >>> network- > >>>> based mobility solution (i.e., PMIPv6). As the MN send signaling to > >>> inform its > >>>> movement to its mobility anchor, the client-based mobility solution > >>> allows > >>>> the MN to supply client-centric decision for mobility management. > >>>>> > >>>>> Suppose that the origin mobility anchor is the mobility anchor > >>> where the > >>>> MN has configured its IP address and established ongoing > >>> communication > >>>> sessions with the IP address. The number of origin mobility anchors > >>> are n - 1. > >>>> Recall that the serving mobility anchor is the mobility anchor > >>>> where > >>> the MN is > >>>> being served by. Then, the MN's involvement in mobility signaling > >>> brings us > >>>> the questions: "Should we let the MN send mobilty signaling to its > >>> all mobility > >>>> anchors?" or "Would it make sense that the MN only sends mobility > >>> signaling > >>>> to its serving mobility anchor?" Depending on the choice, we will > >>> have > >>>> different results: > >>>>> > >>>>> 1) "MN sends mobility signaling to its all mobility anchors" > >>> causes: > >>>>> 1.1 increased mobility signaling load, e.g., signaling * (n - 1). > >>>>> 1.2 bidirectional tunnels are established between the MN and its > >>> mobility > >>>> anchors. > >>>>> 1.3 tunneling overhead over the air is present. > >>>>> 1.4 but the tunnels are terminated at the MN so that the MN has > >>> control > >>>> over the tunnels. > >>>>> > >>>>> 2) "MN sends mobility signaling only to its serving mobility > >>> anchor" causes: > >>>>> 2.1 reduced mobility signaling load, e.g., signaling * 1. > >>>>> 2.2 bidirectional tunnels are established between the serving > >>> mobility > >>>> anchors and origin mobility anchors. > >>>>> 2.3 tunneling overhead over the air can be avoided. > >>>>> 2.4 but the MN does not have control over the tunnels so it might > >>> affect to > >>>> NEtwork MObility (NEMO) as the MN (i.e., MR in NEMO) loses the > >>> tunneling > >>>> control. > >>>>> > >>>>> =3D=3D=3D 3. Neighbor mobility anchors' information in a DMM > environment. > >>>>> =3D=3D=3D In the client-based mobility solution such as MIPv6, the > >>> network > >>>> topology information does not required to be known to the mobility > >>> anchor, > >>>> i.e., home agent (HA), since the HA is informed the current > >>>> location > >>> of the > >>>> MN. As the HA knows the current location of the MN, it is able to > >>> tunnel > >>>> packets associated to the MN. In the network-based mobility > >>>> solution > >>> such > >>>> as PMIPv6, the similar things happen, i.e., the tunnel between the > >>> local > >>>> mobility anchor (LMA) and the mobile access gateway (MAG) is > >>> established > >>>> for a given MN. > >>>>> > >>>>> However, as mobility anchors are distributed and bidirectional > >>> tunnels (for > >>>> a given MN) between the distributed mobility anchors are required, > >>> the > >>>> neighbor mobility anchors' information should be provided to the MN > >>> or the > >>>> mobility anchor for the establishment of the directional tunnels or > >>> the > >>>> update of the MN's current location. > >>>>> > >>>>> Decoupling the data plane and control plane while keeping a > >>> centralized > >>>> node maintaining the mobility context including neighbor mobility > >>> anchors' > >>>> information (e.g., identification, IP address, etc) in a DMM > >>> environment is > >>>> one of possible solutions. > >>>>> > >>>>> =3D=3D=3D 4. Comment on an establishment of security associations i= n a > >>> DMM > >>>>> environment. =3D=3D=3D For each IP mobility support protocol, diffe= rent > >>> security > >>>> associations (SAs) are required for providing secure mobility > >>> services to MNs > >>>> as follows: > >>>>> > >>>>> 1) MIPv6 > >>>>> 1.1 SA between MN and HA. > >>>>> 1.2 SA between MN and serving access router (AR) providing > >>>>> wireless > >>> link > >>>> to the MN. > >>>>> > >>>>> 2) Fast Handover MIPv6 (FMIPv6) > >>>>> 2.1 SA between MN and HA. > >>>>> 2.2 SA between MN and serving AR. > >>>>> 2.3 SA between previous and new ARs. > >>>>> > >>>>> 3) PMIPv6 > >>>>> 3.1 SA between MN and serving MAG. > >>>>> 3.2 SA between serving MAG and LMA. > >>>>> > >>>>> 4) Fast Handover PMIPv6 (FPMIPv6) > >>>>> 4.1 SA between MN and serving MAG. > >>>>> 4.2 SA between serving MAG and LMA. > >>>>> 4.3 SA between previous and new MAGs. > >>>>> > >>>>> Note that the above ones do not consider the cases of SA with a > >>> security- > >>>> backend server (e.g., AAA server) and with a correspondent node > (CN). > >>>>> > >>>>> However, depending on DMM solutions, SAs are configured that are > >>>>> different from those of the existing IP mobility support protocols. > >>>>> For instance, > >>>>> > >>>>> 1) the case of "MN sends mobility signaling to its all mobility > >>>>> anchors" (client-based mobility solution) > >>>>> 1.1 SA between MN and serving mobility anchor providing wireless > >>> link to > >>>> the MN. > >>>>> 1.2 SA between MN and origin mobility anchors, i.e., (n - 1) SAs > >>> required > >>>> with MN and origin mobility anchors. > >>>>> > >>>>> 2) the case of "MN sends mobility signaling only to its serving > >>>>> mobility anchor" (client-based mobility solution) > >>>>> 2.1 SA between MN and serving mobility anchor. > >>>>> 2.2 SA between serving mobility anchor and origin mobility > >>>>> anchors, > >>> i.e., (n > >>>> - 1) SAs required with serving mobility anchor and origin mobility > >>> anchors. > >>>>> > >>>>> 3) the case of "serving mobility anchor sends signaling on behalf > >>> of > >>>>> the MN to origin mobility anchors" (network-based mobility > >>> solution) > >>>>> 3.1 SA between MN and serving mobility anchor. > >>>>> 3.2 SA between serving mobility anchor and origin mobility > >>>>> anchors, > >>> i.e., (n > >>>> - 1) SAs required with serving mobility anchor and origin mobility > >>> anchors. > >>>>> > >>>>> Note that as like before SAs with a security-backend server (e.g., > >>> AAA > >>>> server) and with a CN are not presented. > >>>>> > >>>>> As shown above, DMM solutions (that relies on bidirectional > >>> tunnelings for > >>>> packet forwarding between MN and mobility anchors or between just > >>>> mobility anchors) might bring the key management issues to > >>>> establish > >>> such > >>>> SAs. > >>>>> > >>>>> Since it's a holiday season, I cannot fully address all of them in > >>> my mind, but > >>>> kindly consider these ones. > >>>>> > >>>>> Cheers. > >>>>> > >>>>> -- > >>>>> 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/ > >>>>> > >>>>> _______________________________________________ > >>>>> 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 > >> > >> > __________________________________________________________ > ___________ > >> _________ ___________________________________________ > >> > >> Ce message et ses pieces jointes peuvent contenir des informations > >> confidentielles ou privilegiees et ne doivent donc pas etre diffuses, > >> exploites ou copies sans autorisation. Si vous avez recu ce message > >> par erreur, veuillez le signaler a l'expediteur et le detruire ainsi > >> que les pieces jointes. Les messages electroniques etant susceptibles > >> d'alteration, France Telecom - Orange decline toute responsabilite si > >> ce message a ete altere, deforme ou falsifie. Merci. > >> > >> This message and its attachments may contain confidential or > >> privileged information that may be protected by law; they should not > >> be distributed, used or copied without authorisation. > >> If you have received this email in error, please notify the sender > >> and delete this message and its attachments. > >> As emails may be altered, France Telecom - Orange is not liable for > >> messages that have been modified, changed or falsified. > >> Thank you. > >> > > > > _______________________________________________ > > 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 Sep 21 02:10: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 5F6B221F8733 for ; Fri, 21 Sep 2012 02:10:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.941 X-Spam-Level: X-Spam-Status: No, score=-2.941 tagged_above=-999 required=5 tests=[AWL=-0.582, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, SARE_LWSHORTT=1.24] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bvdtd6UHv9yb for ; Fri, 21 Sep 2012 02:10:04 -0700 (PDT) Received: from mail-bk0-f44.google.com (mail-bk0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id 1B8EA21F870F for ; Fri, 21 Sep 2012 02:10:03 -0700 (PDT) Received: by bkty12 with SMTP id y12so1556714bkt.31 for ; Fri, 21 Sep 2012 02:10:03 -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=xbrldVDH7UAskWYBIy72AVUeL6PmVrdhlaZ2yIvwOVs=; b=gxE1VpGyWoq5EZ9bD+u9nY2XqHjZP12E/R186znoxbuKOMXopEbuNxZsZb1R9M9lLN KIfi2wllE87rWDP3PBiTJcWqnaUcjmiSmhmo6GQTmvYskDxL6Q8J1nZukkGSvhG5ahl4 crBsWDFWjcRcTQ46kdv3kxlcx4T5/W/ZObC7KPSX39mXftgBPQeFA7zQ6L/faAB5vniC O2uB7Yibgg/uevqVPcTCqi0WXY+nFJhADDOSR0psABRBeJBGUuzJqQ0c6h5lRAp9o1Eb 0KN0F7myYCJ+ouHxy5gB1g7IF1nSlxUBzg7Jq3i+tonSDR50J+xvKg2/FjwhOaetVx6t MsaA== Received: by 10.204.156.208 with SMTP id y16mr1896442bkw.76.1348218602925; Fri, 21 Sep 2012 02:10:02 -0700 (PDT) Received: from [10.255.134.5] ([194.251.119.201]) by mx.google.com with ESMTPS id p2sm5743660bkw.3.2012.09.21.02.09.55 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 21 Sep 2012 02:10:00 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=iso-8859-1 From: jouni korhonen In-Reply-To: <19629_1348141879_505B0337_19629_713_1_81C77F07008CA24F9783A98CFD706F71038D41@PEXCVZYM12.corporate.adroot.infra.ftgroup> Date: Fri, 21 Sep 2012 12:09:54 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <1B16B62E-851A-4D91-A736-9F73BB6EB087@gmail.com> References: <13040_1348059786_5059C28A_13040_17047_1_81C77F07008CA24F9783A98CFD706F71038847@PEXCVZYM12.corporate.adroot.infra.ftgroup> <19629_1348141879_505B0337_19629_713_1_81C77F07008CA24F9783A98CFD706F71038D41@PEXCVZYM12.corporate.adroot.infra.ftgroup> To: X-Mailer: Apple Mail (2.1084) Cc: "dmm-chairs@tools.ietf.org" , 'Jouni Korhonen' , "dmm@ietf.org" Subject: Re: [DMM] Comments on DMM Gap Analysis. 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, 21 Sep 2012 09:10:06 -0000 Pierrick, On Sep 20, 2012, at 2:51 PM, = wrote: > Jouni, >=20 > Thanks for clarifications. I agree, we have a good idea on what could = be a DMM environment. However, the application of IP mobility protocols = in such environments is worth to be described; we need to clearly figure = out application and issues. Now, you're probably=20 Sure. And I call for realistic environments. Something that we have real = hands-on operational experience with. Even if those were not originally drawn at = the power point level as "distributed environments" but in practice some level = distribution can be achieved. Might not be _currently_ what the DMM aims for but that = is the gap we are after, right? When the real gap is reveal, real new stuff = flows in with even new architectures.. > right when saying there is no room for dedicated document. Actually, I = think it is a good idea to have the description of practices=20 Good. > together with gap analysis in a single document :-) But, the problem = is that, today, we have couple of documents on practices and others on = gap analysis, without real consensus on practices. So, IMHO, we need to = firstly agree on practices the WG will recommend. Having multiple documents and a split at the moment is no problem.. It = might be an issue at a personal level coffee consumption, though ;) Glue and duct = tape works out nicely with small effort. Personally, I would do my analysis against the = practices in DMMish capable architectures I think are relevant, and in one place. > And, to do that, we probably need to consider current contributions = and limit the scope to some protocols (as you reminded in a previous = email). That's my point but I do not push for separate document :-) >=20 > BTW, since mobility management is not deployed in distributed = architecture, it would be better to talk about "recommendations" than = "practices" :) Practices.. what is the problem with that. Honestly, I struggle with = that. Say, some deployed networks already do things like functional split (like user & = control plane separation). Some other deployed technologies allow relocating your = "centralized agents" based on xyz criteria. Not directly DMMish but you have current = practices how to get closer to our distributes goals using the existing tools we got. - Jouni >=20 > Pierrick >=20 >> -----Message d'origine----- >> De : Jouni Korhonen [mailto:jouni.korhonen@nsn.com] >> Envoy=E9 : jeudi 20 septembre 2012 10:35 >> =C0 : SEITE Pierrick RD-RESA; 'karagian@cs.utwente.nl'; >> jouni.nospam@gmail.com; dmm@ietf.org; h.anthony.chan@huawei.com; >> JuanCarlos.Zuniga@interdigital.com >> Cc : dmm-chairs@tools.ietf.org >> Objet : Re: [DMM] Comments on DMM Gap Analysis. >>=20 >> Pierrick, >>=20 >> On 9/19/12 4:03 PM, "ext pierrick.seite@orange.com" >> wrote: >>=20 >>> Hi Jouni and Julien, >>>=20 >>>=20 >>> Sorry for jumping into the discussion but I'm a little bit confused >>> with recent discussions in DMM. So, let me ask for clarifications >>> about the scope of the gap analysis... >>>=20 >>> The WG is now tackling with the work item 'Practices and Gap >> Analysis' >>> and, in my understanding, we are expected to provide a gap analysis >>> regarding the use of mobility protocols in a distributed mobility >> management environment. >>> However, it seems that the scope of discussions on gap analysis is >>> different.... and I'm confused :-) >>=20 >> The "distributed" environment would be what we have now.. Like if you >> operate a network that has more than one anchor node, you can = consider >> that as a system which could enable distribution. And if e.g. anchor >> distribution is possible/done today that would be documented = (example: >> LMA selection during the attach time based on geographical location). >>=20 >> o Practices: Document practices for the deployment of existing >> mobility protocols in a distributed mobility management >> environment. >>=20 >> Gap analysis is then based on that.. and >>=20 >>> Actually, in the charter, we agreed to firstly "document practices >> for >>> the deployment of existing mobility protocols in a distributed >>> mobility management >>=20 >> ..during the meeting I asked the question whether we deal current >> practices and gap analysis in the same document, since there are >> conflicting milestones. There was no clear answer from the room as = far >> as I remember (and minutes indicate). >>=20 >> I am (still) on the opinion that these two can and probably should be >> the one same document. There are not too many current practices given >> the rather low number of _really_deployed_ IP mobility technologies >> that we can write meaningful current practices about. Then you would = do >> the gap analysis against those. >>=20 >>> environment" and, then, to make the gap analysis. However, >> considering >>> current discussions on "gap analysis": the document on practices has >>> been omitted and discussions are about vanilla mobility protocols = and >>> architectures with respect to DMM requirements. So, maybe, such >>> considerations are interesting in the scope of the problem = statement, >>> but it seems to me that it is not the goal of the gap analysis, as >>> initially intended in the charter. Am I missing something? >>=20 >> I should have been clearer that I would like to see these two = combined. >> o Submit I-D 'Practices and Gap Analysis' as a working group = document. >>=20 >> That also kind of forces strict scoping of mobility technologies I >> mentioned about in my earlier mail. >>=20 >> I don't want to see a current practices or gap analysis of solutions >> that has no relation to an existing and rather short term planned >> deployment reality.. >>=20 >>> If I refer to previous DMM charter (because current DMM charter is >> empty... >>> BTW, is there a reason for an empty charter?), one Work item was: >>> "Document >>=20 >> There are issues between datatracker and tools coordination or >> something. >> Tools guys are on this. You can find older(?) version of the charter = on >> the tools page and yesterday the charter re-appeared again to >> datatracker. >>=20 >>> practices for the deployment of existing mobility protocols in a >>> distributed mobility management environment". Is this document = still >>> in DMM stuff? If yes, shouldn't we document practices before going >> into the gap analysis? >>=20 >> Mmm yes. But if you combine both you should be fine too. If folks = think >> and insist that there shall be a current practices as a separate >> document, so be it. >>=20 >> - Jouni >>=20 >>=20 >>=20 >>>=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 : mercredi 19 septembre 2012 13:11 = =C0 : >>>> jouni.nospam@gmail.com; dmm@ietf.org; h.anthony.chan@huawei.com; >>>> JuanCarlos.Zuniga@interdigital.com >>>> Cc : dmm-chairs@tools.ietf.org >>>> Objet : Re: [DMM] Comments on DMM Gap Analysis. >>>>=20 >>>> Hi Jouni, Hi all, >>>>=20 >>>> After discussing this issue with Carlos Jes=FAs Bernardos and Juan >>>> Carlos Zuniga, we concluded that the following set of possible >>>> technologies could be included in the Gap analysis draft: >>>>=20 >>>> =3D> Shim6: Level 3 Multihoming Shim Protocol for IPv6 = http://www.rfc- >>>> editor.org/rfc/rfc5533.txt >>>>=20 >>>>=20 >>>> =3D> LISP Mobile Node >>>> http://www.ietf.org/id/draft-meyer-lisp-mn-07.txt >>>> Locator/ID Separation Protocol (LISP) >>>> http://www.ietf.org/id/draft-ietf-lisp-23.txt >>>>=20 >>>> =3D> Mobile IPv6 Fast Handovers >>>> http://tools.ietf.org/id/draft-ietf-mipshop-rfc5268bis-01.txt >>>> This is the draft that became then RFC5568, so no need to mention >> it. >>>> http://www.rfc-editor.org/rfc/rfc5568.txt >>>>=20 >>>>=20 >>>> =3D> Fast Handovers for Proxy Mobile IPv6 >>>> http://www.rfc-editor.org/rfc/rfc5949.txt >>>>=20 >>>> =3D> Host Identity Protocol >>>> http://www.rfc-editor.org/rfc/rfc4423.txt >>>> http://www.rfc-editor.org/rfc/rfc5201.txt >>>> http://www.rfc-editor.org/rfc/rfc6253.txt >>>> http://www.rfc-editor.org/rfc/rfc5206.txt >>>>=20 >>>>=20 >>>>=20 >>>> =3D> IKEv2 Mobility and Multihoming Protocol (MOBIKE) >>>> http://www.rfc-editor.org/rfc/rfc4555.txt >>>>=20 >>>>=20 >>>> =3D> GTPv2-C: 3rd Generation Partnership Project; Technical >>>> Specification Group Core Network and Terminals; 3GPP Evolved Packet >>>> System (EPS); Evolved General Packet Radio Service (GPRS) = Tunnelling >>>> Protocol for Control plane (GTPv2-C); Stage 3 (Release 11) >>>> = http://www.3gpp.org/ftp/Specs/archive/29_series/29.274/29274-b30.zip >>>>=20 >>>> Please inform us if this list makes sense to you? >>>>=20 >>>> Best regards, >>>> Georgios >>>>=20 >>>>=20 >>>>> -----Original Message----- >>>>> From: dmm-bounces@ietf.org [mailto:dmm-bounces@ietf.org] On Behalf >>>>> Of jouni korhonen >>>>> Sent: woensdag 19 september 2012 9:58 >>>>> To: dmm@ietf.org; h chan; Juan Carlos Zuniga >>>>> Cc: dmm-chairs@tools.ietf.org >>>>> Subject: Re: [DMM] Comments on DMM Gap Analysis. >>>>>=20 >>>>>=20 >>>>> Folks, >>>>>=20 >>>>> It has been rather silent on the list recently. Regarding the >>>> "explosion" of >>>>> possible technologies in the GAP analysis, we discussed (chairs) >>>>> that >>>> it is >>>>> better to scope the area "a bit". The charter today has the >>>> assumption that >>>>> we build on top of existing _IP_ _Mobility_ protocols (and bunch = of >>>> IETF >>>>> defined examples follow). So, to tighten the scope, the Gap >> Analysis >>>> should >>>>> leave all routing, session (SIP, ..), transport (MPTCP, SCTP, >> DCCP, >>>> ..), >>>>> locator/identifier split (HIP, Lisp, ..), naming (DNS tricks, ..) >>>>> etc >>>> based >>>>> solutions out. Coarse but should help us to make progress. We = could >>>> discuss >>>>> whether transport layer solution like SCTP fit in but I do not see >>>> them as end- >>>>> 2-end solutions being deployable in Internet at the moment. >>>>>=20 >>>>> Let us stick with technologies out there that have/had a place in >>>> sun: few >>>>> MIP variants, MOBIKE, stuff in 3GPP(2) (oops.. but I think this >>>> deserves to be >>>>> evaluated since they are somewhat popular), and what applications >> do >>>>> (reconnecting..). This analysis should be down to earth practical >>>>> and >>>> realistic >>>>> on what is already out there to play with. >>>>>=20 >>>>> - Jouni & Julien >>>>>=20 >>>>>=20 >>>>>=20 >>>>> On Jul 27, 2012, at 3:53 PM, Jong-Hyouk Lee wrote: >>>>>=20 >>>>>> Dear Anthony and Juan. >>>>>>=20 >>>>>> I enjoyed the both gap analysis documents (draft-chan-dmm- >>>> framework- >>>>> gap-analysis-02 and draft-zuniga-dmm-gap-analysis-01). Here I give >>>> some >>>>> comments that should be used directly in the gap analysis = documents >>>> if you >>>>> guys like. >>>>>>=20 >>>>>> Kindly consider the followings during the gap analysis discussion >>>> (since I will >>>>> not be attending the IETF meeting this time). >>>>>>=20 >>>>>> 1. Comment on address (resource) management in a DMM environment. >>>>>> 2. Comment on a deployment of a client-based mobility solution >>>> (i.e., >>>>> MIPv6) in a DMM environment. >>>>>> 3. Commnet on neighbor mobility anchors' information in a DMM >>>>> environment. >>>>>> 4. Commnet on an establishment of security associations in a DMM >>>>> environment. >>>>>>=20 >>>>>> =3D=3D=3D 1. Comment on address (resource) management in a DMM >>>>> environment. >>>>>> =3D=3D=3D When existing IP mobility support protocols (e.g., = MIPv6 and >>>> PMIPv6) >>>>> are considered to be deployed in a DMM environment, a mobile node >>>> (MN) >>>>> is allowed to configure a new address while keeping its previous >>>> address(es). >>>>> It introduces the following differences with the address = (resource) >>>>> management of the existing ones: >>>>>>=20 >>>>>> MN's address configured at the interface with a DMM environment: = n >>>> =3D >>>>>> (IP address at the current access network + previously configured >>>> IP >>>>>> address(es) with ongoing sessions) MN's address configured at the >>>>>> interface without a DMM environment: 1 =3D (care-of address in = MIPv6 >>>> or >>>>>> MN's home address in PMIPv6) >>>>>>=20 >>>>>> This leads a couple of considerations we didn't have with the >>>> existing >>>>>> IP mobility support protocols. For instance, >>>>>>=20 >>>>>> 1) MN's address management: use of a newly configured address at >>>> the >>>>> current access network for new communication sessions while a >> proper >>>>> address selection for previously established ongoing communication >>>>> sessions. >>>>>>=20 >>>>>> 2) Additional treatment for ingress filtering: Ingress filtering >> is >>>> widely used >>>>> against source address spoofing. The source addresses (especially, >>>> the >>>>> network prefix part) of incoming packets are strictly checked to >>>>> make >>>> sure >>>>> that those packets are actually from the network that they claim = to >>>> be from. >>>>> As the MN are allowed to send data packets with the previously >>>> configured >>>>> address(es) at the new access network, those data packets would be >>>> filtered >>>>> at the ingress filtering place because the source address of those >>>> data >>>>> packets is not belonging to the new access network. Accordingly, = an >>>>> additional treatment for ingress filtering is required. >>>>>>=20 >>>>>> 3) MN's address increase at the MN's interface: Recall the number >>>> of MN's >>>>> address configured at an interface is n. Then, n is increased, as >>>>> the >>>> MN >>>>> changes its point of attachment while keeping its ongoing >>>> communication >>>>> sessions. It brings the question: "How many addresses are = currently >>>> possible >>>>> to be configured at an interface?" >>>>>>=20 >>>>>> 4) Routing entry increase at the serving mobility anchor: Let the >>>> serving >>>>> mobility anchor is the mobility anchor serves the MN. Traffic >>>> associated to >>>>> the MN travels via the serving mobility anchor. The increase of = the >>>> addresses >>>>> associated to the MN, n, is not only concerning to the MN, but = also >>>>> concerning the serving mobility anchor as it contributes the >>>>> increase >>>> of >>>>> routing entries for the MN. >>>>>>=20 >>>>>> =3D=3D=3D 2. Comment on a deployment of a client-based mobility = solution >>>>>> (i.e., MIPv6) in a DMM environment. =3D=3D=3D When a client-based >>>> mobility >>>>> solution (i.e., MIPv6) is consiered to be deployed in a DMM >>>> environment, an >>>>> MN is involved in mobility signaling such as Binding Update and >>>>> Acknowledgement messages. This is the big difference with the >>>> network- >>>>> based mobility solution (i.e., PMIPv6). As the MN send signaling = to >>>> inform its >>>>> movement to its mobility anchor, the client-based mobility = solution >>>> allows >>>>> the MN to supply client-centric decision for mobility management. >>>>>>=20 >>>>>> Suppose that the origin mobility anchor is the mobility anchor >>>> where the >>>>> MN has configured its IP address and established ongoing >>>> communication >>>>> sessions with the IP address. The number of origin mobility = anchors >>>> are n - 1. >>>>> Recall that the serving mobility anchor is the mobility anchor >> where >>>> the MN is >>>>> being served by. Then, the MN's involvement in mobility signaling >>>> brings us >>>>> the questions: "Should we let the MN send mobilty signaling to its >>>> all mobility >>>>> anchors?" or "Would it make sense that the MN only sends mobility >>>> signaling >>>>> to its serving mobility anchor?" Depending on the choice, we will >>>> have >>>>> different results: >>>>>>=20 >>>>>> 1) "MN sends mobility signaling to its all mobility anchors" >>>> causes: >>>>>> 1.1 increased mobility signaling load, e.g., signaling * (n - 1). >>>>>> 1.2 bidirectional tunnels are established between the MN and its >>>> mobility >>>>> anchors. >>>>>> 1.3 tunneling overhead over the air is present. >>>>>> 1.4 but the tunnels are terminated at the MN so that the MN has >>>> control >>>>> over the tunnels. >>>>>>=20 >>>>>> 2) "MN sends mobility signaling only to its serving mobility >>>> anchor" causes: >>>>>> 2.1 reduced mobility signaling load, e.g., signaling * 1. >>>>>> 2.2 bidirectional tunnels are established between the serving >>>> mobility >>>>> anchors and origin mobility anchors. >>>>>> 2.3 tunneling overhead over the air can be avoided. >>>>>> 2.4 but the MN does not have control over the tunnels so it might >>>> affect to >>>>> NEtwork MObility (NEMO) as the MN (i.e., MR in NEMO) loses the >>>> tunneling >>>>> control. >>>>>>=20 >>>>>> =3D=3D=3D 3. Neighbor mobility anchors' information in a DMM >> environment. >>>>>> =3D=3D=3D In the client-based mobility solution such as MIPv6, = the >>>> network >>>>> topology information does not required to be known to the mobility >>>> anchor, >>>>> i.e., home agent (HA), since the HA is informed the current >> location >>>> of the >>>>> MN. As the HA knows the current location of the MN, it is able to >>>> tunnel >>>>> packets associated to the MN. In the network-based mobility >> solution >>>> such >>>>> as PMIPv6, the similar things happen, i.e., the tunnel between the >>>> local >>>>> mobility anchor (LMA) and the mobile access gateway (MAG) is >>>> established >>>>> for a given MN. >>>>>>=20 >>>>>> However, as mobility anchors are distributed and bidirectional >>>> tunnels (for >>>>> a given MN) between the distributed mobility anchors are required, >>>> the >>>>> neighbor mobility anchors' information should be provided to the = MN >>>> or the >>>>> mobility anchor for the establishment of the directional tunnels = or >>>> the >>>>> update of the MN's current location. >>>>>>=20 >>>>>> Decoupling the data plane and control plane while keeping a >>>> centralized >>>>> node maintaining the mobility context including neighbor mobility >>>> anchors' >>>>> information (e.g., identification, IP address, etc) in a DMM >>>> environment is >>>>> one of possible solutions. >>>>>>=20 >>>>>> =3D=3D=3D 4. Comment on an establishment of security associations = in a >>>> DMM >>>>>> environment. =3D=3D=3D For each IP mobility support protocol, = different >>>> security >>>>> associations (SAs) are required for providing secure mobility >>>> services to MNs >>>>> as follows: >>>>>>=20 >>>>>> 1) MIPv6 >>>>>> 1.1 SA between MN and HA. >>>>>> 1.2 SA between MN and serving access router (AR) providing >> wireless >>>> link >>>>> to the MN. >>>>>>=20 >>>>>> 2) Fast Handover MIPv6 (FMIPv6) >>>>>> 2.1 SA between MN and HA. >>>>>> 2.2 SA between MN and serving AR. >>>>>> 2.3 SA between previous and new ARs. >>>>>>=20 >>>>>> 3) PMIPv6 >>>>>> 3.1 SA between MN and serving MAG. >>>>>> 3.2 SA between serving MAG and LMA. >>>>>>=20 >>>>>> 4) Fast Handover PMIPv6 (FPMIPv6) >>>>>> 4.1 SA between MN and serving MAG. >>>>>> 4.2 SA between serving MAG and LMA. >>>>>> 4.3 SA between previous and new MAGs. >>>>>>=20 >>>>>> Note that the above ones do not consider the cases of SA with a >>>> security- >>>>> backend server (e.g., AAA server) and with a correspondent node >> (CN). >>>>>>=20 >>>>>> However, depending on DMM solutions, SAs are configured that are >>>>>> different from those of the existing IP mobility support >> protocols. >>>>>> For instance, >>>>>>=20 >>>>>> 1) the case of "MN sends mobility signaling to its all mobility >>>>>> anchors" (client-based mobility solution) >>>>>> 1.1 SA between MN and serving mobility anchor providing wireless >>>> link to >>>>> the MN. >>>>>> 1.2 SA between MN and origin mobility anchors, i.e., (n - 1) SAs >>>> required >>>>> with MN and origin mobility anchors. >>>>>>=20 >>>>>> 2) the case of "MN sends mobility signaling only to its serving >>>>>> mobility anchor" (client-based mobility solution) >>>>>> 2.1 SA between MN and serving mobility anchor. >>>>>> 2.2 SA between serving mobility anchor and origin mobility >> anchors, >>>> i.e., (n >>>>> - 1) SAs required with serving mobility anchor and origin mobility >>>> anchors. >>>>>>=20 >>>>>> 3) the case of "serving mobility anchor sends signaling on behalf >>>> of >>>>>> the MN to origin mobility anchors" (network-based mobility >>>> solution) >>>>>> 3.1 SA between MN and serving mobility anchor. >>>>>> 3.2 SA between serving mobility anchor and origin mobility >> anchors, >>>> i.e., (n >>>>> - 1) SAs required with serving mobility anchor and origin mobility >>>> anchors. >>>>>>=20 >>>>>> Note that as like before SAs with a security-backend server = (e.g., >>>> AAA >>>>> server) and with a CN are not presented. >>>>>>=20 >>>>>> As shown above, DMM solutions (that relies on bidirectional >>>> tunnelings for >>>>> packet forwarding between MN and mobility anchors or between just >>>>> mobility anchors) might bring the key management issues to >> establish >>>> such >>>>> SAs. >>>>>>=20 >>>>>> Since it's a holiday season, I cannot fully address all of them = in >>>> my mind, but >>>>> kindly consider these ones. >>>>>>=20 >>>>>> Cheers. >>>>>>=20 >>>>>> -- >>>>>> RSM Department, TELECOM Bretagne, France Jong-Hyouk Lee, living >>>>>> somewhere between /dev/null and /dev/random >>>>>>=20 >>>>>> #email: jonghyouk (at) gmail (dot) com >>>>>> #webpage: http://sites.google.com/site/hurryon/ >>>>>>=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 >>>> _______________________________________________ >>>> dmm mailing list >>>> dmm@ietf.org >>>> https://www.ietf.org/mailman/listinfo/dmm >>>=20 >>>=20 >> = ______________________________________________________________________ >>> ________ ___________________________________________ >>>=20 >>> Ce message et ses pieces jointes peuvent contenir des informations >>> confidentielles ou privilegiees et ne doivent donc pas etre = diffuses, >>> exploites ou copies sans autorisation. Si vous avez recu ce message >>> par erreur, veuillez le signaler a l'expediteur et le detruire ainsi >>> que les pieces jointes. Les messages electroniques etant = susceptibles >>> d'alteration, France Telecom - Orange decline toute responsabilite = si >>> ce message a ete altere, deforme ou falsifie. Merci. >>>=20 >>> This message and its attachments may contain confidential or >>> privileged information that may be protected by law; they should not >>> be distributed, used or copied without authorisation. >>> If you have received this email in error, please notify the sender >> and >>> delete this message and its attachments. >>> As emails may be altered, France Telecom - Orange is not liable for >>> messages that have been modified, changed or falsified. >>> Thank you. >>>=20 >=20 >=20 > = __________________________________________________________________________= _______________________________________________ >=20 > Ce message et ses pieces jointes peuvent contenir des informations = confidentielles ou privilegiees et ne doivent donc > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez = recu ce message par erreur, veuillez le signaler > a l'expediteur et le detruire ainsi que les pieces jointes. Les = messages electroniques etant susceptibles d'alteration, > France Telecom - Orange decline toute responsabilite si ce message a = ete altere, deforme ou falsifie. Merci. >=20 > This message and its attachments may contain confidential or = privileged information that may be protected by law; > they should not be distributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and = delete this message and its attachments. > As emails may be altered, France Telecom - Orange is not liable for = messages that have been modified, changed or falsified. > Thank you. >=20 From k.pentikousis@huawei.com Fri Sep 21 05:18:58 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 2B9E121F8773 for ; Fri, 21 Sep 2012 05:18:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 28KiI0LrQE8Z for ; Fri, 21 Sep 2012 05:18:57 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 1A7C021F871C for ; Fri, 21 Sep 2012 05:18:56 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id AKX43483; Fri, 21 Sep 2012 12:18:55 +0000 (GMT) Received: from LHREML404-HUB.china.huawei.com (10.201.5.218) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.1.323.3; Fri, 21 Sep 2012 13:18:14 +0100 Received: from SZXEML404-HUB.china.huawei.com (10.82.67.59) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.1.323.3; Fri, 21 Sep 2012 20:18:50 +0800 Received: from szxeml545-mbx.china.huawei.com ([169.254.1.98]) by szxeml404-hub.china.huawei.com ([::1]) with mapi id 14.01.0323.003; Fri, 21 Sep 2012 20:18:44 +0800 From: Konstantinos Pentikousis To: "pierrick.seite@orange.com" , "jouni.nospam@gmail.com" , "dmm@ietf.org" Thread-Topic: [DMM] Comments on DMM Gap Analysis. Thread-Index: AQHNl0u11vmmILWXvk63XY4bTwVyXJeUtxjA Date: Fri, 21 Sep 2012 12:18:44 +0000 Message-ID: <8D38716F0C1A444BA0CD7E96454366C23A4DDF04@szxeml545-mbx.china.huawei.com> References: <13040_1348059786_5059C28A_13040_17047_1_81C77F07008CA24F9783A98CFD706F71038847@PEXCVZYM12.corporate.adroot.infra.ftgroup> <19629_1348141879_505B0337_19629_713_1_81C77F07008CA24F9783A98CFD706F71038D41@PEXCVZYM12.corporate.adroot.infra.ftgroup> In-Reply-To: <19629_1348141879_505B0337_19629_713_1_81C77F07008CA24F9783A98CFD706F71038D41@PEXCVZYM12.corporate.adroot.infra.ftgroup> Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.200.37.56] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: Re: [DMM] Comments on DMM Gap Analysis. 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, 21 Sep 2012 12:18:58 -0000 Hi Pierrick, Jouni, All, | we have a good idea on what could be a DMM environment Actually, I would like to see a concrete definition, say, of less than 25 w= ords, of what a "DMM environment" is. Pointers much appreciated. Best Regards, Kostas From k.pentikousis@huawei.com Fri Sep 21 06:13:31 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 AA6C821F87AE for ; Fri, 21 Sep 2012 06:13:31 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iTsX+RZJeQuy for ; Fri, 21 Sep 2012 06:13:31 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id AC47F21F8770 for ; Fri, 21 Sep 2012 06:13:30 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id AKX47579; Fri, 21 Sep 2012 13:13:29 +0000 (GMT) Received: from LHREML406-HUB.china.huawei.com (10.201.5.243) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.1.323.3; Fri, 21 Sep 2012 14:12:29 +0100 Received: from SZXEML421-HUB.china.huawei.com (10.82.67.160) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.1.323.3; Fri, 21 Sep 2012 14:12:57 +0100 Received: from szxeml545-mbx.china.huawei.com ([169.254.1.98]) by szxeml421-hub.china.huawei.com ([10.82.67.160]) with mapi id 14.01.0323.003; Fri, 21 Sep 2012 21:12:48 +0800 From: Konstantinos Pentikousis To: h chan , "dmm@ietf.org" Thread-Topic: [DMM] I-D Action: draft-ietf-dmm-requirements-02.txt Thread-Index: AQHNjH9JZrCc1liiskCM6yCzowi6Ipd9bAAAgBdnjZA= Date: Fri, 21 Sep 2012 13:12:47 +0000 Message-ID: <8D38716F0C1A444BA0CD7E96454366C23A4DDFBE@szxeml545-mbx.china.huawei.com> References: <20120906223025.4376.69767.idtracker@ietfa.amsl.com> <6E31144C030982429702B11D6746B98C270DD223@SZXEML505-MBS.china.huawei.com> In-Reply-To: <6E31144C030982429702B11D6746B98C270DD223@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.200.37.56] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: Re: [DMM] I-D Action: draft-ietf-dmm-requirements-02.txt 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, 21 Sep 2012 13:13:31 -0000 Dear All, |The updated requirements are also being sent out one by one in |separate emails. | |Please check them, and comments are welcome. I guess nobody has publicly voiced major concerns during the last two weeks= . Did I miss something? Best Regards, Kostas From k.pentikousis@huawei.com Fri Sep 21 08:42: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 1DD5F21F8768 for ; Fri, 21 Sep 2012 08:42:27 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hH--FRJEGv0R for ; Fri, 21 Sep 2012 08:42:26 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 0635021F86F4 for ; Fri, 21 Sep 2012 08:42:25 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id AJW94334; Fri, 21 Sep 2012 15:42:24 +0000 (GMT) Received: from LHREML402-HUB.china.huawei.com (10.201.5.241) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.1.323.3; Fri, 21 Sep 2012 16:41:47 +0100 Received: from SZXEML424-HUB.china.huawei.com (10.82.67.163) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.1.323.3; Fri, 21 Sep 2012 16:42:23 +0100 Received: from szxeml545-mbx.china.huawei.com ([169.254.1.98]) by szxeml424-hub.china.huawei.com ([10.82.67.163]) with mapi id 14.01.0323.003; Fri, 21 Sep 2012 23:42:19 +0800 From: Konstantinos Pentikousis To: "JuanCarlos.Zuniga@InterDigital.com" , "cjbc@it.uc3m.es" , "MELIA, TELEMACO (TELEMACO)" Thread-Topic: Review of draft-zuniga-dmm-gap-analysis-01 Thread-Index: Ac2YD6xosOH4iAHMTmmTuXlsg6SPhw== Date: Fri, 21 Sep 2012 15:42:18 +0000 Message-ID: <8D38716F0C1A444BA0CD7E96454366C23A4DE0AE@szxeml545-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.200.37.56] 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: [DMM] Review of draft-zuniga-dmm-gap-analysis-01 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, 21 Sep 2012 15:42:27 -0000 Dear Juan Carlos, Carlos, Telemaco, All, I went over draft-zuniga-dmm-gap-analysis-01 and, although I understand tha= t this draft is a reasonable first shot, at times it reads as if it was wri= tten very hastily. Overall, much work lies ahead. Please find below my com= ments and suggestions after a cursory review.=20 Section 1: Intro ---------------- There is no need to repeat what's in the reqs ID nearly in verbatim. Beside= s the fact that most interested readers would be familiar with this already= , you may end up with synchronization and consistency issues, which need to= be taken care of on a continuous basis till -reqs becomes an RFC. Even so,= I propose to rewrite the intro so that it matches the scope and target of = this document, and remove the repetition of the reqs text. Section 2: "Practices" ---------------------- The term "DMM environment" is not actually defined; ditto the term "DMM mod= e of operation". If you refer to dynamically, on-demand change of the anchor point, then it'= s better to say so explicitly. If, on the other hand, this latter term refe= rs to core offload (as in "thus providing some form of distribution, since = the traffic is locally route[d]"), alternative paths, etc. then it's better= to say so as well, in the respective paragraphs. With respect to Figures 1-4, I like that you tried to visually display vari= ous solutions. Unfortunately, they mostly fail to convey the inherent diffe= rences. Moreover, the text does not take advantage of these figures whatsoe= ver after they are introduced. Further, I am not sure what exactly does the= cloud-like container for the (different) HA (flavors) and LMA is supposed = to tell me. In short, I would consider improving the figures significantly = as they can be powerful in clearly showing what are the "gaps" we're after.= But left as-is, they provide little value; we're better off, for instance,= with a ref to RFC 6301. Fig. 2 could be merged with Fig. 1, as it adds little further info. Somewhere midway in section 2.2.x, the text gets a bit rough. I hope the ne= xt version will take care of this. Then, somehow the text starts talking ab= out possible solutions while still in the "Practices" part (for example the= recurring references to an inter-LMA mobility protocol). I'm also a bit puzzled about the sudden appearance of 3GPP stuff in section= 2.2.2 onwards. Forget about how it actually comes together as smooth text = (it does not). I'm more interested in how it provides a coherent line of ar= gumentation in each 2.x subsection and how this relates to the gap analysis= in section 3. Also, there is a bit of mix-and-match going on, e.g. section= 2.2.5: how's multihoming related with the previous stuff? Section 3: "Gap analysis" ------------------------- >From section 3.1.2 onwards, the text is, at times, just rough/copy-paste no= tes. This is particularly the case for 3.1.3-6 and 3.2.3-6. The format adop= ted for section 3 is also more like a sketch of a gap analysis. Overall comments ---------------- The document is over-structured and does not lead to new insights esp. in s= ection 3. A conclusions section that pulls everything together is clearly missing. Finally, in the references section, I'm not sure why certain RFCs are consi= dered "normative" for this draft, esp. since no requirements language is sp= ecified (there's no ref to RFC 2119 for that matter). A ref that perhaps sh= ould be included is RFC 6301. Ditto, refs for DIDA, OPIIS, and MAPCON are m= issing. Are all listed refs actually used? A couple of nits and editorial suggestions follow: --- s/the MN two different temporal/the MN has two different temporary s/used the RCoA/uses the RCoA s/locally router at/locally routed at s/a point of view of routing/the routing point of view s/considered as a mean to/considered as means to s/provides a better/provides for better s/anchored and a/anchored at a s/[REF to flow mob draft]/ s/signaling overhead/signaling overhead s/only performed/only be performed s/This approach include/This approach includes/g Define acronyms on first appearance. Not all readers are familiar with them= . ---- Best Regards, Kostas From pierrick.seite@orange.com Mon Sep 24 01:14:19 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 93D8721F8574 for ; Mon, 24 Sep 2012 01:14:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.079 X-Spam-Level: X-Spam-Status: No, score=-1.079 tagged_above=-999 required=5 tests=[AWL=-1.209, BAYES_05=-1.11, SARE_LWSHORTT=1.24, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K-rHMYpshokM for ; Mon, 24 Sep 2012 01:14:13 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by ietfa.amsl.com (Postfix) with ESMTP id E975D21F8540 for ; Mon, 24 Sep 2012 01:14:11 -0700 (PDT) Received: from omfedm07.si.francetelecom.fr (unknown [xx.xx.xx.3]) by omfedm14.si.francetelecom.fr (ESMTP service) with ESMTP id 8B36522C523; Mon, 24 Sep 2012 10:14:10 +0200 (CEST) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.183]) by omfedm07.si.francetelecom.fr (ESMTP service) with ESMTP id 6753A4C024; Mon, 24 Sep 2012 10:14:10 +0200 (CEST) Received: from PEXCVZYM12.corporate.adroot.infra.ftgroup ([fe80::81f:1640:4749:5d13]) by PEXCVZYH02.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.02.0298.004; Mon, 24 Sep 2012 10:14:08 +0200 From: To: 'jouni korhonen' Thread-Topic: [DMM] Comments on DMM Gap Analysis. Thread-Index: AQHNl9jcXcpjTD/9QkmtNxNtqHDjdJeZJWeA Date: Mon, 24 Sep 2012 08:14:08 +0000 Message-ID: <28364_1348474450_50601652_28364_5318_1_81C77F07008CA24F9783A98CFD706F710394EB@PEXCVZYM12.corporate.adroot.infra.ftgroup> References: <13040_1348059786_5059C28A_13040_17047_1_81C77F07008CA24F9783A98CFD706F71038847@PEXCVZYM12.corporate.adroot.infra.ftgroup> <19629_1348141879_505B0337_19629_713_1_81C77F07008CA24F9783A98CFD706F71038D41@PEXCVZYM12.corporate.adroot.infra.ftgroup> <1B16B62E-851A-4D91-A736-9F73BB6EB087@gmail.com> In-Reply-To: <1B16B62E-851A-4D91-A736-9F73BB6EB087@gmail.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.197.38.6] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2012.9.24.61222 Cc: "dmm-chairs@tools.ietf.org" , 'Jouni Korhonen' , "dmm@ietf.org" Subject: Re: [DMM] Comments on DMM Gap Analysis. 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, 24 Sep 2012 08:14:19 -0000 Jouni, > -----Message d'origine----- > De=A0: jouni korhonen [mailto:jouni.nospam@gmail.com] > Envoy=E9=A0: vendredi 21 septembre 2012 11:10 > =C0=A0: SEITE Pierrick RD-RESA > Cc=A0: 'Jouni Korhonen'; 'karagian@cs.utwente.nl'; dmm@ietf.org; > h.anthony.chan@huawei.com; JuanCarlos.Zuniga@interdigital.com; dmm- > chairs@tools.ietf.org > Objet=A0: Re: [DMM] Comments on DMM Gap Analysis. >=20 >=20 > Pierrick, >=20 >=20 > On Sep 20, 2012, at 2:51 PM, > wrote: >=20 > > Jouni, > > > > Thanks for clarifications. I agree, we have a good idea on what could > > be a DMM environment. However, the application of IP mobility > > protocols in such environments is worth to be described; we need to > > clearly figure out application and issues. Now, you're probably >=20 > Sure. And I call for realistic environments. Something that we have > real hands-on operational experience with. Even if those were not > originally drawn at the power point level as "distributed environments" > but in practice some level distribution can be achieved. Might not be > _currently_ what the DMM aims for but that is the gap we are after, > right?=20 Ok, I see. I agree. When the real gap is reveal, real new stuff flows in with even > new architectures.. >=20 > > right when saying there is no room for dedicated document. Actually, > I > > think it is a good idea to have the description of practices >=20 > Good. >=20 > > together with gap analysis in a single document :-) But, the problem > is that, today, we have couple of documents on practices and others on > gap analysis, without real consensus on practices. So, IMHO, we need to > firstly agree on practices the WG will recommend. >=20 > Having multiple documents and a split at the moment is no problem.. It > might be an issue at a personal level coffee consumption, though ;) > Glue and duct tape works out nicely with small effort. Personally, I > would do my analysis against the practices in DMMish capable > architectures I think are relevant, and in one place. >=20 > > And, to do that, we probably need to consider current contributions > > and limit the scope to some protocols (as you reminded in a previous > > email). That's my point but I do not push for separate document :-) > > > > BTW, since mobility management is not deployed in distributed > > architecture, it would be better to talk about "recommendations" than > > "practices" :) >=20 > Practices.. what is the problem with that. Honestly, I struggle with > that. Say, some deployed networks already do things like functional > split (like user & control plane separation). Some other deployed > technologies allow relocating your "centralized agents" > based on xyz criteria. Not directly DMMish but you have current > practices how to get closer to our distributes goals using the existing > tools we got. >=20 You're right, some architectures support distribution features; I meant tha= t, IP mobility in distributed architecture is not supported. But, ok, no pr= oblem with "practices" :-) Basically, we are in agreement. Thanks for the clarifications. Pierrick > - Jouni >=20 >=20 > > > > Pierrick > > > >> -----Message d'origine----- > >> De : Jouni Korhonen [mailto:jouni.korhonen@nsn.com] Envoy=E9 : jeudi > 20 > >> septembre 2012 10:35 =C0 : SEITE Pierrick RD-RESA; > >> 'karagian@cs.utwente.nl'; jouni.nospam@gmail.com; dmm@ietf.org; > >> h.anthony.chan@huawei.com; JuanCarlos.Zuniga@interdigital.com > >> Cc : dmm-chairs@tools.ietf.org > >> Objet : Re: [DMM] Comments on DMM Gap Analysis. > >> > >> Pierrick, > >> > >> On 9/19/12 4:03 PM, "ext pierrick.seite@orange.com" > >> wrote: > >> > >>> Hi Jouni and Julien, > >>> > >>> > >>> Sorry for jumping into the discussion but I'm a little bit confused > >>> with recent discussions in DMM. So, let me ask for clarifications > >>> about the scope of the gap analysis... > >>> > >>> The WG is now tackling with the work item 'Practices and Gap > >> Analysis' > >>> and, in my understanding, we are expected to provide a gap analysis > >>> regarding the use of mobility protocols in a distributed mobility > >> management environment. > >>> However, it seems that the scope of discussions on gap analysis is > >>> different.... and I'm confused :-) > >> > >> The "distributed" environment would be what we have now.. Like if > you > >> operate a network that has more than one anchor node, you can > >> consider that as a system which could enable distribution. And if > >> e.g. anchor distribution is possible/done today that would be > documented (example: > >> LMA selection during the attach time based on geographical > location). > >> > >> o Practices: Document practices for the deployment of existing > >> mobility protocols in a distributed mobility management > >> environment. > >> > >> Gap analysis is then based on that.. and > >> > >>> Actually, in the charter, we agreed to firstly "document practices > >> for > >>> the deployment of existing mobility protocols in a distributed > >>> mobility management > >> > >> ..during the meeting I asked the question whether we deal current > >> practices and gap analysis in the same document, since there are > >> conflicting milestones. There was no clear answer from the room as > >> far as I remember (and minutes indicate). > >> > >> I am (still) on the opinion that these two can and probably should > be > >> the one same document. There are not too many current practices > given > >> the rather low number of _really_deployed_ IP mobility technologies > >> that we can write meaningful current practices about. Then you would > >> do the gap analysis against those. > >> > >>> environment" and, then, to make the gap analysis. However, > >> considering > >>> current discussions on "gap analysis": the document on practices > has > >>> been omitted and discussions are about vanilla mobility protocols > >>> and architectures with respect to DMM requirements. So, maybe, such > >>> considerations are interesting in the scope of the problem > >>> statement, but it seems to me that it is not the goal of the gap > >>> analysis, as initially intended in the charter. Am I missing > something? > >> > >> I should have been clearer that I would like to see these two > combined. > >> o Submit I-D 'Practices and Gap Analysis' as a working group > document. > >> > >> That also kind of forces strict scoping of mobility technologies I > >> mentioned about in my earlier mail. > >> > >> I don't want to see a current practices or gap analysis of solutions > >> that has no relation to an existing and rather short term planned > >> deployment reality.. > >> > >>> If I refer to previous DMM charter (because current DMM charter is > >> empty... > >>> BTW, is there a reason for an empty charter?), one Work item was: > >>> "Document > >> > >> There are issues between datatracker and tools coordination or > >> something. > >> Tools guys are on this. You can find older(?) version of the charter > >> on the tools page and yesterday the charter re-appeared again to > >> datatracker. > >> > >>> practices for the deployment of existing mobility protocols in a > >>> distributed mobility management environment". Is this document > >>> still in DMM stuff? If yes, shouldn't we document practices before > >>> going > >> into the gap analysis? > >> > >> Mmm yes. But if you combine both you should be fine too. If folks > >> think and insist that there shall be a current practices as a > >> separate document, so be it. > >> > >> - Jouni > >> > >> > >> > >>> > >>> 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 : mercredi 19 septembre 2012 13:11 = =C0 > : > >>>> jouni.nospam@gmail.com; dmm@ietf.org; h.anthony.chan@huawei.com; > >>>> JuanCarlos.Zuniga@interdigital.com > >>>> Cc : dmm-chairs@tools.ietf.org > >>>> Objet : Re: [DMM] Comments on DMM Gap Analysis. > >>>> > >>>> Hi Jouni, Hi all, > >>>> > >>>> After discussing this issue with Carlos Jes=FAs Bernardos and Juan > >>>> Carlos Zuniga, we concluded that the following set of possible > >>>> technologies could be included in the Gap analysis draft: > >>>> > >>>> =3D> Shim6: Level 3 Multihoming Shim Protocol for IPv6 > >>>> http://www.rfc- editor.org/rfc/rfc5533.txt > >>>> > >>>> > >>>> =3D> LISP Mobile Node > >>>> http://www.ietf.org/id/draft-meyer-lisp-mn-07.txt > >>>> Locator/ID Separation Protocol (LISP) > >>>> http://www.ietf.org/id/draft-ietf-lisp-23.txt > >>>> > >>>> =3D> Mobile IPv6 Fast Handovers > >>>> http://tools.ietf.org/id/draft-ietf-mipshop-rfc5268bis-01.txt > >>>> This is the draft that became then RFC5568, so no need to mention > >> it. > >>>> http://www.rfc-editor.org/rfc/rfc5568.txt > >>>> > >>>> > >>>> =3D> Fast Handovers for Proxy Mobile IPv6 > >>>> http://www.rfc-editor.org/rfc/rfc5949.txt > >>>> > >>>> =3D> Host Identity Protocol > >>>> http://www.rfc-editor.org/rfc/rfc4423.txt > >>>> http://www.rfc-editor.org/rfc/rfc5201.txt > >>>> http://www.rfc-editor.org/rfc/rfc6253.txt > >>>> http://www.rfc-editor.org/rfc/rfc5206.txt > >>>> > >>>> > >>>> > >>>> =3D> IKEv2 Mobility and Multihoming Protocol (MOBIKE) > >>>> http://www.rfc-editor.org/rfc/rfc4555.txt > >>>> > >>>> > >>>> =3D> GTPv2-C: 3rd Generation Partnership Project; Technical > >>>> Specification Group Core Network and Terminals; 3GPP Evolved > Packet > >>>> System (EPS); Evolved General Packet Radio Service (GPRS) > >>>> Tunnelling Protocol for Control plane (GTPv2-C); Stage 3 (Release > >>>> 11) > >>>> http://www.3gpp.org/ftp/Specs/archive/29_series/29.274/29274- > b30.zi > >>>> p > >>>> > >>>> Please inform us if this list makes sense to you? > >>>> > >>>> Best regards, > >>>> Georgios > >>>> > >>>> > >>>>> -----Original Message----- > >>>>> From: dmm-bounces@ietf.org [mailto:dmm-bounces@ietf.org] On > Behalf > >>>>> Of jouni korhonen > >>>>> Sent: woensdag 19 september 2012 9:58 > >>>>> To: dmm@ietf.org; h chan; Juan Carlos Zuniga > >>>>> Cc: dmm-chairs@tools.ietf.org > >>>>> Subject: Re: [DMM] Comments on DMM Gap Analysis. > >>>>> > >>>>> > >>>>> Folks, > >>>>> > >>>>> It has been rather silent on the list recently. Regarding the > >>>> "explosion" of > >>>>> possible technologies in the GAP analysis, we discussed (chairs) > >>>>> that > >>>> it is > >>>>> better to scope the area "a bit". The charter today has the > >>>> assumption that > >>>>> we build on top of existing _IP_ _Mobility_ protocols (and bunch > >>>>> of > >>>> IETF > >>>>> defined examples follow). So, to tighten the scope, the Gap > >> Analysis > >>>> should > >>>>> leave all routing, session (SIP, ..), transport (MPTCP, SCTP, > >> DCCP, > >>>> ..), > >>>>> locator/identifier split (HIP, Lisp, ..), naming (DNS tricks, ..) > >>>>> etc > >>>> based > >>>>> solutions out. Coarse but should help us to make progress. We > >>>>> could > >>>> discuss > >>>>> whether transport layer solution like SCTP fit in but I do not > see > >>>> them as end- > >>>>> 2-end solutions being deployable in Internet at the moment. > >>>>> > >>>>> Let us stick with technologies out there that have/had a place > in > >>>> sun: few > >>>>> MIP variants, MOBIKE, stuff in 3GPP(2) (oops.. but I think this > >>>> deserves to be > >>>>> evaluated since they are somewhat popular), and what applications > >> do > >>>>> (reconnecting..). This analysis should be down to earth practical > >>>>> and > >>>> realistic > >>>>> on what is already out there to play with. > >>>>> > >>>>> - Jouni & Julien > >>>>> > >>>>> > >>>>> > >>>>> On Jul 27, 2012, at 3:53 PM, Jong-Hyouk Lee wrote: > >>>>> > >>>>>> Dear Anthony and Juan. > >>>>>> > >>>>>> I enjoyed the both gap analysis documents (draft-chan-dmm- > >>>> framework- > >>>>> gap-analysis-02 and draft-zuniga-dmm-gap-analysis-01). Here I > give > >>>> some > >>>>> comments that should be used directly in the gap analysis > >>>>> documents > >>>> if you > >>>>> guys like. > >>>>>> > >>>>>> Kindly consider the followings during the gap analysis > discussion > >>>> (since I will > >>>>> not be attending the IETF meeting this time). > >>>>>> > >>>>>> 1. Comment on address (resource) management in a DMM > environment. > >>>>>> 2. Comment on a deployment of a client-based mobility solution > >>>> (i.e., > >>>>> MIPv6) in a DMM environment. > >>>>>> 3. Commnet on neighbor mobility anchors' information in a DMM > >>>>> environment. > >>>>>> 4. Commnet on an establishment of security associations in a DMM > >>>>> environment. > >>>>>> > >>>>>> =3D=3D=3D 1. Comment on address (resource) management in a DMM > >>>>> environment. > >>>>>> =3D=3D=3D When existing IP mobility support protocols (e.g., MIPv6= and > >>>> PMIPv6) > >>>>> are considered to be deployed in a DMM environment, a mobile node > >>>> (MN) > >>>>> is allowed to configure a new address while keeping its previous > >>>> address(es). > >>>>> It introduces the following differences with the address > >>>>> (resource) management of the existing ones: > >>>>>> > >>>>>> MN's address configured at the interface with a DMM environment: > >>>>>> n > >>>> =3D > >>>>>> (IP address at the current access network + previously > configured > >>>> IP > >>>>>> address(es) with ongoing sessions) MN's address configured at > the > >>>>>> interface without a DMM environment: 1 =3D (care-of address in > >>>>>> MIPv6 > >>>> or > >>>>>> MN's home address in PMIPv6) > >>>>>> > >>>>>> This leads a couple of considerations we didn't have with the > >>>> existing > >>>>>> IP mobility support protocols. For instance, > >>>>>> > >>>>>> 1) MN's address management: use of a newly configured address at > >>>> the > >>>>> current access network for new communication sessions while a > >> proper > >>>>> address selection for previously established ongoing > communication > >>>>> sessions. > >>>>>> > >>>>>> 2) Additional treatment for ingress filtering: Ingress filtering > >> is > >>>> widely used > >>>>> against source address spoofing. The source addresses > (especially, > >>>> the > >>>>> network prefix part) of incoming packets are strictly checked to > >>>>> make > >>>> sure > >>>>> that those packets are actually from the network that they claim > >>>>> to > >>>> be from. > >>>>> As the MN are allowed to send data packets with the previously > >>>> configured > >>>>> address(es) at the new access network, those data packets would > be > >>>> filtered > >>>>> at the ingress filtering place because the source address of > those > >>>> data > >>>>> packets is not belonging to the new access network. Accordingly, > >>>>> an additional treatment for ingress filtering is required. > >>>>>> > >>>>>> 3) MN's address increase at the MN's interface: Recall the > number > >>>> of MN's > >>>>> address configured at an interface is n. Then, n is increased, as > >>>>> the > >>>> MN > >>>>> changes its point of attachment while keeping its ongoing > >>>> communication > >>>>> sessions. It brings the question: "How many addresses are > >>>>> currently > >>>> possible > >>>>> to be configured at an interface?" > >>>>>> > >>>>>> 4) Routing entry increase at the serving mobility anchor: Let > the > >>>> serving > >>>>> mobility anchor is the mobility anchor serves the MN. Traffic > >>>> associated to > >>>>> the MN travels via the serving mobility anchor. The increase of > >>>>> the > >>>> addresses > >>>>> associated to the MN, n, is not only concerning to the MN, but > >>>>> also concerning the serving mobility anchor as it contributes the > >>>>> increase > >>>> of > >>>>> routing entries for the MN. > >>>>>> > >>>>>> =3D=3D=3D 2. Comment on a deployment of a client-based mobility > >>>>>> solution (i.e., MIPv6) in a DMM environment. =3D=3D=3D When a > >>>>>> client-based > >>>> mobility > >>>>> solution (i.e., MIPv6) is consiered to be deployed in a DMM > >>>> environment, an > >>>>> MN is involved in mobility signaling such as Binding Update and > >>>>> Acknowledgement messages. This is the big difference with the > >>>> network- > >>>>> based mobility solution (i.e., PMIPv6). As the MN send signaling > >>>>> to > >>>> inform its > >>>>> movement to its mobility anchor, the client-based mobility > >>>>> solution > >>>> allows > >>>>> the MN to supply client-centric decision for mobility management. > >>>>>> > >>>>>> Suppose that the origin mobility anchor is the mobility anchor > >>>> where the > >>>>> MN has configured its IP address and established ongoing > >>>> communication > >>>>> sessions with the IP address. The number of origin mobility > >>>>> anchors > >>>> are n - 1. > >>>>> Recall that the serving mobility anchor is the mobility anchor > >> where > >>>> the MN is > >>>>> being served by. Then, the MN's involvement in mobility signaling > >>>> brings us > >>>>> the questions: "Should we let the MN send mobilty signaling to > its > >>>> all mobility > >>>>> anchors?" or "Would it make sense that the MN only sends mobility > >>>> signaling > >>>>> to its serving mobility anchor?" Depending on the choice, we will > >>>> have > >>>>> different results: > >>>>>> > >>>>>> 1) "MN sends mobility signaling to its all mobility anchors" > >>>> causes: > >>>>>> 1.1 increased mobility signaling load, e.g., signaling * (n - > 1). > >>>>>> 1.2 bidirectional tunnels are established between the MN and its > >>>> mobility > >>>>> anchors. > >>>>>> 1.3 tunneling overhead over the air is present. > >>>>>> 1.4 but the tunnels are terminated at the MN so that the MN has > >>>> control > >>>>> over the tunnels. > >>>>>> > >>>>>> 2) "MN sends mobility signaling only to its serving mobility > >>>> anchor" causes: > >>>>>> 2.1 reduced mobility signaling load, e.g., signaling * 1. > >>>>>> 2.2 bidirectional tunnels are established between the serving > >>>> mobility > >>>>> anchors and origin mobility anchors. > >>>>>> 2.3 tunneling overhead over the air can be avoided. > >>>>>> 2.4 but the MN does not have control over the tunnels so it > might > >>>> affect to > >>>>> NEtwork MObility (NEMO) as the MN (i.e., MR in NEMO) loses the > >>>> tunneling > >>>>> control. > >>>>>> > >>>>>> =3D=3D=3D 3. Neighbor mobility anchors' information in a DMM > >> environment. > >>>>>> =3D=3D=3D In the client-based mobility solution such as MIPv6, the > >>>> network > >>>>> topology information does not required to be known to the > mobility > >>>> anchor, > >>>>> i.e., home agent (HA), since the HA is informed the current > >> location > >>>> of the > >>>>> MN. As the HA knows the current location of the MN, it is able to > >>>> tunnel > >>>>> packets associated to the MN. In the network-based mobility > >> solution > >>>> such > >>>>> as PMIPv6, the similar things happen, i.e., the tunnel between > the > >>>> local > >>>>> mobility anchor (LMA) and the mobile access gateway (MAG) is > >>>> established > >>>>> for a given MN. > >>>>>> > >>>>>> However, as mobility anchors are distributed and bidirectional > >>>> tunnels (for > >>>>> a given MN) between the distributed mobility anchors are > required, > >>>> the > >>>>> neighbor mobility anchors' information should be provided to the > >>>>> MN > >>>> or the > >>>>> mobility anchor for the establishment of the directional tunnels > >>>>> or > >>>> the > >>>>> update of the MN's current location. > >>>>>> > >>>>>> Decoupling the data plane and control plane while keeping a > >>>> centralized > >>>>> node maintaining the mobility context including neighbor mobility > >>>> anchors' > >>>>> information (e.g., identification, IP address, etc) in a DMM > >>>> environment is > >>>>> one of possible solutions. > >>>>>> > >>>>>> =3D=3D=3D 4. Comment on an establishment of security associations = in a > >>>> DMM > >>>>>> environment. =3D=3D=3D For each IP mobility support protocol, > different > >>>> security > >>>>> associations (SAs) are required for providing secure mobility > >>>> services to MNs > >>>>> as follows: > >>>>>> > >>>>>> 1) MIPv6 > >>>>>> 1.1 SA between MN and HA. > >>>>>> 1.2 SA between MN and serving access router (AR) providing > >> wireless > >>>> link > >>>>> to the MN. > >>>>>> > >>>>>> 2) Fast Handover MIPv6 (FMIPv6) > >>>>>> 2.1 SA between MN and HA. > >>>>>> 2.2 SA between MN and serving AR. > >>>>>> 2.3 SA between previous and new ARs. > >>>>>> > >>>>>> 3) PMIPv6 > >>>>>> 3.1 SA between MN and serving MAG. > >>>>>> 3.2 SA between serving MAG and LMA. > >>>>>> > >>>>>> 4) Fast Handover PMIPv6 (FPMIPv6) > >>>>>> 4.1 SA between MN and serving MAG. > >>>>>> 4.2 SA between serving MAG and LMA. > >>>>>> 4.3 SA between previous and new MAGs. > >>>>>> > >>>>>> Note that the above ones do not consider the cases of SA with a > >>>> security- > >>>>> backend server (e.g., AAA server) and with a correspondent node > >> (CN). > >>>>>> > >>>>>> However, depending on DMM solutions, SAs are configured that are > >>>>>> different from those of the existing IP mobility support > >> protocols. > >>>>>> For instance, > >>>>>> > >>>>>> 1) the case of "MN sends mobility signaling to its all mobility > >>>>>> anchors" (client-based mobility solution) > >>>>>> 1.1 SA between MN and serving mobility anchor providing wireless > >>>> link to > >>>>> the MN. > >>>>>> 1.2 SA between MN and origin mobility anchors, i.e., (n - 1) SAs > >>>> required > >>>>> with MN and origin mobility anchors. > >>>>>> > >>>>>> 2) the case of "MN sends mobility signaling only to its serving > >>>>>> mobility anchor" (client-based mobility solution) > >>>>>> 2.1 SA between MN and serving mobility anchor. > >>>>>> 2.2 SA between serving mobility anchor and origin mobility > >> anchors, > >>>> i.e., (n > >>>>> - 1) SAs required with serving mobility anchor and origin > mobility > >>>> anchors. > >>>>>> > >>>>>> 3) the case of "serving mobility anchor sends signaling on > behalf > >>>> of > >>>>>> the MN to origin mobility anchors" (network-based mobility > >>>> solution) > >>>>>> 3.1 SA between MN and serving mobility anchor. > >>>>>> 3.2 SA between serving mobility anchor and origin mobility > >> anchors, > >>>> i.e., (n > >>>>> - 1) SAs required with serving mobility anchor and origin > mobility > >>>> anchors. > >>>>>> > >>>>>> Note that as like before SAs with a security-backend server > >>>>>> (e.g., > >>>> AAA > >>>>> server) and with a CN are not presented. > >>>>>> > >>>>>> As shown above, DMM solutions (that relies on bidirectional > >>>> tunnelings for > >>>>> packet forwarding between MN and mobility anchors or between just > >>>>> mobility anchors) might bring the key management issues to > >> establish > >>>> such > >>>>> SAs. > >>>>>> > >>>>>> Since it's a holiday season, I cannot fully address all of them > >>>>>> in > >>>> my mind, but > >>>>> kindly consider these ones. > >>>>>> > >>>>>> Cheers. > >>>>>> > >>>>>> -- > >>>>>> 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/ > >>>>>> > >>>>>> _______________________________________________ > >>>>>> 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 > >>> > >>> > >> > _____________________________________________________________________ > >> _ > >>> ________ ___________________________________________ > >>> > >>> Ce message et ses pieces jointes peuvent contenir des informations > >>> confidentielles ou privilegiees et ne doivent donc pas etre > >>> diffuses, exploites ou copies sans autorisation. Si vous avez recu > >>> ce message par erreur, veuillez le signaler a l'expediteur et le > >>> detruire ainsi que les pieces jointes. Les messages electroniques > >>> etant susceptibles d'alteration, France Telecom - Orange decline > >>> toute responsabilite si ce message a ete altere, deforme ou > falsifie. Merci. > >>> > >>> This message and its attachments may contain confidential or > >>> privileged information that may be protected by law; they should > not > >>> be distributed, used or copied without authorisation. > >>> If you have received this email in error, please notify the sender > >> and > >>> delete this message and its attachments. > >>> As emails may be altered, France Telecom - Orange is not liable for > >>> messages that have been modified, changed or falsified. > >>> Thank you. > >>> > > > > > > > ______________________________________________________________________ > > ___________________________________________________ > > > > Ce message et ses pieces jointes peuvent contenir des informations > > confidentielles ou privilegiees et ne doivent donc pas etre diffuses, > > exploites ou copies sans autorisation. Si vous avez recu ce message > > par erreur, veuillez le signaler a l'expediteur et le detruire ainsi > que les pieces jointes. Les messages electroniques etant susceptibles > d'alteration, France Telecom - Orange decline toute responsabilite si > ce message a ete altere, deforme ou falsifie. Merci. > > > > This message and its attachments may contain confidential or > > privileged information that may be protected by law; they should not > be distributed, used or copied without authorisation. > > If you have received this email in error, please notify the sender > and delete this message and its attachments. > > As emails may be altered, France Telecom - Orange is not liable for > messages that have been modified, changed or falsified. > > Thank you. > > ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, France Telecom - Orange decline toute responsabilite si ce message a ete al= tere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, France Telecom - Orange is not liable for message= s that have been modified, changed or falsified. Thank you. From Marco.Liebsch@neclab.eu Mon Sep 24 01:17: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 9D22C21F85A0 for ; Mon, 24 Sep 2012 01:17:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d4-BFU+Vi4gg for ; Mon, 24 Sep 2012 01:17:13 -0700 (PDT) Received: from mailer1.neclab.eu (mailer1.neclab.eu [195.37.70.40]) by ietfa.amsl.com (Postfix) with ESMTP id 2697A21F8540 for ; Mon, 24 Sep 2012 01:17:13 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailer1.neclab.eu (Postfix) with ESMTP id 8C282101B25; Mon, 24 Sep 2012 10:17:12 +0200 (CEST) X-Virus-Scanned: Amavisd on Debian GNU/Linux (netlab.nec.de) Received: from mailer1.neclab.eu ([127.0.0.1]) by localhost (atlas-a.office.hd [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6PpCBmxYk5Ke; Mon, 24 Sep 2012 10:17:12 +0200 (CEST) Received: from ENCELADUS.office.hd (enceladus.office.hd [192.168.24.52]) by mailer1.neclab.eu (Postfix) with ESMTP id 6C578101E90; Mon, 24 Sep 2012 10:16:42 +0200 (CEST) Received: from DAPHNIS.office.hd ([169.254.2.111]) by ENCELADUS.office.hd ([192.168.24.52]) with mapi id 14.01.0323.003; Mon, 24 Sep 2012 10:16:06 +0200 From: Marco Liebsch To: liu dapeng , "pierrick.seite@orange.com" , jouni.nospam , Julien Laganier Thread-Topic: [DMM] Comments on DMM Gap Analysis. Thread-Index: AQHNa/bwGh1y1QFPt0KpnYuDISxTwpeRf28AgAA2BYCAAB9NgIAA9xgAgAaveCA= Date: Mon, 24 Sep 2012 08:16:06 +0000 Message-ID: <69756203DDDDE64E987BC4F70B71A26D53397574@DAPHNIS.office.hd> References: <13040_1348059786_5059C28A_13040_17047_1_81C77F07008CA24F9783A98CFD706F71038847@PEXCVZYM12.corporate.adroot.infra.ftgroup> In-Reply-To: Accept-Language: de-DE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.1.6.1] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "dmm@ietf.org" , "dmm-chairs@tools.ietf.org" Subject: Re: [DMM] Comments on DMM Gap Analysis. 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, 24 Sep 2012 08:17:15 -0000 Hi, of course the gap analysis can be limited to a study and assessment of sole= ly available IP mobility protocols. The question is against which template these gaps ar= e assessed. To tackle and address the complete space of DMM problems (and some of them = are very specific to DMM) I doubt that relying only on mobility extensions is s= ufficient. Simply because the nature of DMM moves some problems out of the IP mobility space. Squeezing them to fit into a mobility problem and solving them by mo= bility extension may work functionally, but.. In the past, backend protocols played always role in solving the complete p= roblem. IMHO, some non-mobility protocols should be included in the analysis and th= e solution space. If the WG wants to start with analyzing solely mobility pro= tocols first and extend the scope in a next step, fine. But I just worry that the limite= d gap analysis will be taken as base to solve DMM completely as mobility protocol extensio= n. That'll help only to be fast, nothing else. marco >-----Original Message----- >From: dmm-bounces@ietf.org [mailto:dmm-bounces@ietf.org] On Behalf Of >liu dapeng >Sent: Donnerstag, 20. September 2012 05:47 >To: pierrick.seite@orange.com; jouni.nospam; Julien Laganier >Cc: dmm@ietf.org; dmm-chairs@tools.ietf.org >Subject: Re: [DMM] Comments on DMM Gap Analysis. > >Hello All, > >I also have the similar thinking that we should first document and agree o= n the >"practices for the deployment of existing mobility protocols in a distribu= ted >mobility management environment". After that, if we find that there indee= d >some "gap" existing, we can then move to "gap analysis". > >Best Regards, >Dapeng > >2012/9/19, pierrick.seite@orange.com : >> Hi Jouni and Julien, >> >> >> Sorry for jumping into the discussion but I'm a little bit confused >> with recent discussions in DMM. So, let me ask for clarifications >> about the scope of the gap analysis... >> >> The WG is now tackling with the work item 'Practices and Gap Analysis' >> and, in my understanding, we are expected to provide a gap analysis >> regarding the use of mobility protocols in a distributed mobility >management environment. >> However, it seems that the scope of discussions on gap analysis is >> different.... and I'm confused :-) >> >> Actually, in the charter, we agreed to firstly "document practices for >> the deployment of existing mobility protocols in a distributed >> mobility management environment" and, then, to make the gap analysis. >> However, considering current discussions on "gap analysis": the >> document on practices has been omitted and discussions are about >> vanilla mobility protocols and architectures with respect to DMM >> requirements. So, maybe, such considerations are interesting in the >> scope of the problem statement, but it seems to me that it is not the >> goal of the gap analysis, as initially intended in the charter. Am I mis= sing >something? >> >> If I refer to previous DMM charter (because current DMM charter is >empty... >> BTW, is there a reason for an empty charter?), one Work item was: >> "Document practices for the deployment of existing mobility protocols >> in a distributed mobility management environment". Is this document >> still in DMM stuff? If yes, shouldn't we document practices before going= into >the gap analysis? >> >> 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 : mercredi 19 septembre 2012 13:11 =C0 = : >>> jouni.nospam@gmail.com; dmm@ietf.org; h.anthony.chan@huawei.com; >>> JuanCarlos.Zuniga@interdigital.com >>> Cc : dmm-chairs@tools.ietf.org >>> Objet : Re: [DMM] Comments on DMM Gap Analysis. >>> >>> Hi Jouni, Hi all, >>> >>> After discussing this issue with Carlos Jes=FAs Bernardos and Juan >>> Carlos Zuniga, we concluded that the following set of possible >>> technologies could be included in the Gap analysis draft: >>> >>> =3D> Shim6: Level 3 Multihoming Shim Protocol for IPv6 http://www.rfc- >>> editor.org/rfc/rfc5533.txt >>> >>> >>> =3D> LISP Mobile Node >>> http://www.ietf.org/id/draft-meyer-lisp-mn-07.txt >>> Locator/ID Separation Protocol (LISP) >>> http://www.ietf.org/id/draft-ietf-lisp-23.txt >>> >>> =3D> Mobile IPv6 Fast Handovers >>> http://tools.ietf.org/id/draft-ietf-mipshop-rfc5268bis-01.txt >>> This is the draft that became then RFC5568, so no need to mention it. >>> http://www.rfc-editor.org/rfc/rfc5568.txt >>> >>> >>> =3D> Fast Handovers for Proxy Mobile IPv6 >>> http://www.rfc-editor.org/rfc/rfc5949.txt >>> >>> =3D> Host Identity Protocol >>> http://www.rfc-editor.org/rfc/rfc4423.txt >>> http://www.rfc-editor.org/rfc/rfc5201.txt >>> http://www.rfc-editor.org/rfc/rfc6253.txt >>> http://www.rfc-editor.org/rfc/rfc5206.txt >>> >>> >>> >>> =3D> IKEv2 Mobility and Multihoming Protocol (MOBIKE) >>> http://www.rfc-editor.org/rfc/rfc4555.txt >>> >>> >>> =3D> GTPv2-C: 3rd Generation Partnership Project; Technical >>> Specification Group Core Network and Terminals; 3GPP Evolved Packet >>> System (EPS); Evolved General Packet Radio Service (GPRS) Tunnelling >>> Protocol for Control plane (GTPv2-C); Stage 3 (Release 11) >>> http://www.3gpp.org/ftp/Specs/archive/29_series/29.274/29274-b30.zip >>> >>> Please inform us if this list makes sense to you? >>> >>> Best regards, >>> Georgios >>> >>> >>> > -----Original Message----- >>> > From: dmm-bounces@ietf.org [mailto:dmm-bounces@ietf.org] On >Behalf >>> > Of jouni korhonen >>> > Sent: woensdag 19 september 2012 9:58 >>> > To: dmm@ietf.org; h chan; Juan Carlos Zuniga >>> > Cc: dmm-chairs@tools.ietf.org >>> > Subject: Re: [DMM] Comments on DMM Gap Analysis. >>> > >>> > >>> > Folks, >>> > >>> > It has been rather silent on the list recently. Regarding the >>> "explosion" of >>> > possible technologies in the GAP analysis, we discussed (chairs) >>> > that >>> it is >>> > better to scope the area "a bit". The charter today has the >>> assumption that >>> > we build on top of existing _IP_ _Mobility_ protocols (and bunch of >>> IETF >>> > defined examples follow). So, to tighten the scope, the Gap >>> > Analysis >>> should >>> > leave all routing, session (SIP, ..), transport (MPTCP, SCTP, >>> > DCCP, >>> ..), >>> > locator/identifier split (HIP, Lisp, ..), naming (DNS tricks, ..) >>> > etc >>> based >>> > solutions out. Coarse but should help us to make progress. We could >>> discuss >>> > whether transport layer solution like SCTP fit in but I do not see >>> them as end- >>> > 2-end solutions being deployable in Internet at the moment. >>> > >>> > Let us stick with technologies out there that have/had a place in >>> sun: few >>> > MIP variants, MOBIKE, stuff in 3GPP(2) (oops.. but I think this >>> deserves to be >>> > evaluated since they are somewhat popular), and what applications >>> > do (reconnecting..). This analysis should be down to earth >>> > practical and >>> realistic >>> > on what is already out there to play with. >>> > >>> > - Jouni & Julien >>> > >>> > >>> > >>> > On Jul 27, 2012, at 3:53 PM, Jong-Hyouk Lee wrote: >>> > >>> > > Dear Anthony and Juan. >>> > > >>> > > I enjoyed the both gap analysis documents (draft-chan-dmm- >>> framework- >>> > gap-analysis-02 and draft-zuniga-dmm-gap-analysis-01). Here I give >>> some >>> > comments that should be used directly in the gap analysis documents >>> if you >>> > guys like. >>> > > >>> > > Kindly consider the followings during the gap analysis discussion >>> (since I will >>> > not be attending the IETF meeting this time). >>> > > >>> > > 1. Comment on address (resource) management in a DMM >environment. >>> > > 2. Comment on a deployment of a client-based mobility solution >>> (i.e., >>> > MIPv6) in a DMM environment. >>> > > 3. Commnet on neighbor mobility anchors' information in a DMM >>> > environment. >>> > > 4. Commnet on an establishment of security associations in a DMM >>> > environment. >>> > > >>> > > =3D=3D=3D 1. Comment on address (resource) management in a DMM >>> > environment. >>> > > =3D=3D=3D When existing IP mobility support protocols (e.g., MIPv6 = and >>> PMIPv6) >>> > are considered to be deployed in a DMM environment, a mobile node >>> (MN) >>> > is allowed to configure a new address while keeping its previous >>> address(es). >>> > It introduces the following differences with the address (resource) >>> > management of the existing ones: >>> > > >>> > > MN's address configured at the interface with a DMM environment: >>> > > n >>> =3D >>> > > (IP address at the current access network + previously configured >>> IP >>> > > address(es) with ongoing sessions) MN's address configured at the >>> > > interface without a DMM environment: 1 =3D (care-of address in >>> > > MIPv6 >>> or >>> > > MN's home address in PMIPv6) >>> > > >>> > > This leads a couple of considerations we didn't have with the >>> existing >>> > > IP mobility support protocols. For instance, >>> > > >>> > > 1) MN's address management: use of a newly configured address at >>> the >>> > current access network for new communication sessions while a >>> > proper address selection for previously established ongoing >>> > communication sessions. >>> > > >>> > > 2) Additional treatment for ingress filtering: Ingress filtering >>> > > is >>> widely used >>> > against source address spoofing. The source addresses (especially, >>> the >>> > network prefix part) of incoming packets are strictly checked to >>> > make >>> sure >>> > that those packets are actually from the network that they claim to >>> be from. >>> > As the MN are allowed to send data packets with the previously >>> configured >>> > address(es) at the new access network, those data packets would be >>> filtered >>> > at the ingress filtering place because the source address of those >>> data >>> > packets is not belonging to the new access network. Accordingly, an >>> > additional treatment for ingress filtering is required. >>> > > >>> > > 3) MN's address increase at the MN's interface: Recall the number >>> of MN's >>> > address configured at an interface is n. Then, n is increased, as >>> > the >>> MN >>> > changes its point of attachment while keeping its ongoing >>> communication >>> > sessions. It brings the question: "How many addresses are currently >>> possible >>> > to be configured at an interface?" >>> > > >>> > > 4) Routing entry increase at the serving mobility anchor: Let the >>> serving >>> > mobility anchor is the mobility anchor serves the MN. Traffic >>> associated to >>> > the MN travels via the serving mobility anchor. The increase of the >>> addresses >>> > associated to the MN, n, is not only concerning to the MN, but also >>> > concerning the serving mobility anchor as it contributes the >>> > increase >>> of >>> > routing entries for the MN. >>> > > >>> > > =3D=3D=3D 2. Comment on a deployment of a client-based mobility >>> > > solution (i.e., MIPv6) in a DMM environment. =3D=3D=3D When a >>> > > client-based >>> mobility >>> > solution (i.e., MIPv6) is consiered to be deployed in a DMM >>> environment, an >>> > MN is involved in mobility signaling such as Binding Update and >>> > Acknowledgement messages. This is the big difference with the >>> network- >>> > based mobility solution (i.e., PMIPv6). As the MN send signaling to >>> inform its >>> > movement to its mobility anchor, the client-based mobility solution >>> allows >>> > the MN to supply client-centric decision for mobility management. >>> > > >>> > > Suppose that the origin mobility anchor is the mobility anchor >>> where the >>> > MN has configured its IP address and established ongoing >>> communication >>> > sessions with the IP address. The number of origin mobility anchors >>> are n - 1. >>> > Recall that the serving mobility anchor is the mobility anchor >>> > where >>> the MN is >>> > being served by. Then, the MN's involvement in mobility signaling >>> brings us >>> > the questions: "Should we let the MN send mobilty signaling to its >>> all mobility >>> > anchors?" or "Would it make sense that the MN only sends mobility >>> signaling >>> > to its serving mobility anchor?" Depending on the choice, we will >>> have >>> > different results: >>> > > >>> > > 1) "MN sends mobility signaling to its all mobility anchors" >>> causes: >>> > > 1.1 increased mobility signaling load, e.g., signaling * (n - 1). >>> > > 1.2 bidirectional tunnels are established between the MN and its >>> mobility >>> > anchors. >>> > > 1.3 tunneling overhead over the air is present. >>> > > 1.4 but the tunnels are terminated at the MN so that the MN has >>> control >>> > over the tunnels. >>> > > >>> > > 2) "MN sends mobility signaling only to its serving mobility >>> anchor" causes: >>> > > 2.1 reduced mobility signaling load, e.g., signaling * 1. >>> > > 2.2 bidirectional tunnels are established between the serving >>> mobility >>> > anchors and origin mobility anchors. >>> > > 2.3 tunneling overhead over the air can be avoided. >>> > > 2.4 but the MN does not have control over the tunnels so it might >>> affect to >>> > NEtwork MObility (NEMO) as the MN (i.e., MR in NEMO) loses the >>> tunneling >>> > control. >>> > > >>> > > =3D=3D=3D 3. Neighbor mobility anchors' information in a DMM enviro= nment. >>> > > =3D=3D=3D In the client-based mobility solution such as MIPv6, the >>> network >>> > topology information does not required to be known to the mobility >>> anchor, >>> > i.e., home agent (HA), since the HA is informed the current >>> > location >>> of the >>> > MN. As the HA knows the current location of the MN, it is able to >>> tunnel >>> > packets associated to the MN. In the network-based mobility >>> > solution >>> such >>> > as PMIPv6, the similar things happen, i.e., the tunnel between the >>> local >>> > mobility anchor (LMA) and the mobile access gateway (MAG) is >>> established >>> > for a given MN. >>> > > >>> > > However, as mobility anchors are distributed and bidirectional >>> tunnels (for >>> > a given MN) between the distributed mobility anchors are required, >>> the >>> > neighbor mobility anchors' information should be provided to the MN >>> or the >>> > mobility anchor for the establishment of the directional tunnels or >>> the >>> > update of the MN's current location. >>> > > >>> > > Decoupling the data plane and control plane while keeping a >>> centralized >>> > node maintaining the mobility context including neighbor mobility >>> anchors' >>> > information (e.g., identification, IP address, etc) in a DMM >>> environment is >>> > one of possible solutions. >>> > > >>> > > =3D=3D=3D 4. Comment on an establishment of security associations i= n a >>> DMM >>> > > environment. =3D=3D=3D For each IP mobility support protocol, diffe= rent >>> security >>> > associations (SAs) are required for providing secure mobility >>> services to MNs >>> > as follows: >>> > > >>> > > 1) MIPv6 >>> > > 1.1 SA between MN and HA. >>> > > 1.2 SA between MN and serving access router (AR) providing >>> > > wireless >>> link >>> > to the MN. >>> > > >>> > > 2) Fast Handover MIPv6 (FMIPv6) >>> > > 2.1 SA between MN and HA. >>> > > 2.2 SA between MN and serving AR. >>> > > 2.3 SA between previous and new ARs. >>> > > >>> > > 3) PMIPv6 >>> > > 3.1 SA between MN and serving MAG. >>> > > 3.2 SA between serving MAG and LMA. >>> > > >>> > > 4) Fast Handover PMIPv6 (FPMIPv6) >>> > > 4.1 SA between MN and serving MAG. >>> > > 4.2 SA between serving MAG and LMA. >>> > > 4.3 SA between previous and new MAGs. >>> > > >>> > > Note that the above ones do not consider the cases of SA with a >>> security- >>> > backend server (e.g., AAA server) and with a correspondent node (CN). >>> > > >>> > > However, depending on DMM solutions, SAs are configured that are >>> > > different from those of the existing IP mobility support protocols. >>> > > For instance, >>> > > >>> > > 1) the case of "MN sends mobility signaling to its all mobility >>> > > anchors" (client-based mobility solution) >>> > > 1.1 SA between MN and serving mobility anchor providing wireless >>> link to >>> > the MN. >>> > > 1.2 SA between MN and origin mobility anchors, i.e., (n - 1) SAs >>> required >>> > with MN and origin mobility anchors. >>> > > >>> > > 2) the case of "MN sends mobility signaling only to its serving >>> > > mobility anchor" (client-based mobility solution) >>> > > 2.1 SA between MN and serving mobility anchor. >>> > > 2.2 SA between serving mobility anchor and origin mobility >>> > > anchors, >>> i.e., (n >>> > - 1) SAs required with serving mobility anchor and origin mobility >>> anchors. >>> > > >>> > > 3) the case of "serving mobility anchor sends signaling on behalf >>> of >>> > > the MN to origin mobility anchors" (network-based mobility >>> solution) >>> > > 3.1 SA between MN and serving mobility anchor. >>> > > 3.2 SA between serving mobility anchor and origin mobility >>> > > anchors, >>> i.e., (n >>> > - 1) SAs required with serving mobility anchor and origin mobility >>> anchors. >>> > > >>> > > Note that as like before SAs with a security-backend server >>> > > (e.g., >>> AAA >>> > server) and with a CN are not presented. >>> > > >>> > > As shown above, DMM solutions (that relies on bidirectional >>> tunnelings for >>> > packet forwarding between MN and mobility anchors or between just >>> > mobility anchors) might bring the key management issues to >>> > establish >>> such >>> > SAs. >>> > > >>> > > Since it's a holiday season, I cannot fully address all of them >>> > > in >>> my mind, but >>> > kindly consider these ones. >>> > > >>> > > Cheers. >>> > > >>> > > -- >>> > > 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/ >>> > > >>> > > _______________________________________________ >>> > > 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 >> >> >___________________________________________________________ >___________ >> ___________________________________________________ >> >> Ce message et ses pieces jointes peuvent contenir des informations >> confidentielles ou privilegiees et ne doivent donc pas etre diffuses, >> exploites ou copies sans autorisation. Si vous avez recu ce message >> par erreur, veuillez le signaler a l'expediteur et le detruire ainsi >> que les pieces jointes. Les messages electroniques etant susceptibles >> d'alteration, France Telecom - Orange decline toute responsabilite si >> ce message a ete altere, deforme ou falsifie. Merci. >> >> This message and its attachments may contain confidential or >> privileged information that may be protected by law; they should not >> be distributed, used or copied without authorisation. >> If you have received this email in error, please notify the sender and >> delete this message and its attachments. >> As emails may be altered, France Telecom - Orange is not liable for >> messages that have been modified, changed or falsified. >> Thank you. >> >> _______________________________________________ >> dmm mailing list >> dmm@ietf.org >> https://www.ietf.org/mailman/listinfo/dmm >> > > >-- > >------ >Best Regards, >Dapeng Liu >_______________________________________________ >dmm mailing list >dmm@ietf.org >https://www.ietf.org/mailman/listinfo/dmm From pierrick.seite@orange.com Mon Sep 24 02:44: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 663F421F8646 for ; Mon, 24 Sep 2012 02:44:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.201 X-Spam-Level: X-Spam-Status: No, score=-2.201 tagged_above=-999 required=5 tests=[AWL=0.397, BAYES_00=-2.599, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gcwKgO67bw6z for ; Mon, 24 Sep 2012 02:44:40 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by ietfa.amsl.com (Postfix) with ESMTP id 8642A21F8645 for ; Mon, 24 Sep 2012 02:44:40 -0700 (PDT) Received: from omfedm07.si.francetelecom.fr (unknown [xx.xx.xx.3]) by omfedm12.si.francetelecom.fr (ESMTP service) with ESMTP id BB35818C3E2; Mon, 24 Sep 2012 11:44:39 +0200 (CEST) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.183]) by omfedm07.si.francetelecom.fr (ESMTP service) with ESMTP id A0F544C07D; Mon, 24 Sep 2012 11:44:39 +0200 (CEST) Received: from PEXCVZYM12.corporate.adroot.infra.ftgroup ([fe80::81f:1640:4749:5d13]) by PEXCVZYH02.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.02.0298.004; Mon, 24 Sep 2012 11:44:39 +0200 From: To: 'Konstantinos Pentikousis' , "jouni.nospam@gmail.com" , "dmm@ietf.org" Thread-Topic: [DMM] Comments on DMM Gap Analysis. Thread-Index: AQHNl0u1XcpjTD/9QkmtNxNtqHDjdJeUtxjAgASAkWA= Date: Mon, 24 Sep 2012 09:44:38 +0000 Message-ID: <7545_1348479879_50602B87_7545_782_1_81C77F07008CA24F9783A98CFD706F7103958F@PEXCVZYM12.corporate.adroot.infra.ftgroup> References: <13040_1348059786_5059C28A_13040_17047_1_81C77F07008CA24F9783A98CFD706F71038847@PEXCVZYM12.corporate.adroot.infra.ftgroup> <19629_1348141879_505B0337_19629_713_1_81C77F07008CA24F9783A98CFD706F71038D41@PEXCVZYM12.corporate.adroot.infra.ftgroup> <8D38716F0C1A444BA0CD7E96454366C23A4DDF04@szxeml545-mbx.china.huawei.com> In-Reply-To: <8D38716F0C1A444BA0CD7E96454366C23A4DDF04@szxeml545-mbx.china.huawei.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.197.38.6] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2012.6.19.115414 Subject: Re: [DMM] Comments on DMM Gap Analysis. 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, 24 Sep 2012 09:44:41 -0000 Hi Kostas, Maybe some clues in section 3.2 of draft-ietf-dmm-requirements and in https= ://tools.ietf.org/html/draft-chan-distributed-mobility-ps-05 As well in http://tools.ietf.org/id/draft-yokota-dmm-scenario-00.txt and ht= tp://tools.ietf.org/html/draft-liu-distributed-mobility-02=20 Br, Pierrick > -----Message d'origine----- > De=A0: Konstantinos Pentikousis [mailto:k.pentikousis@huawei.com] > Envoy=E9=A0: vendredi 21 septembre 2012 14:19 > =C0=A0: SEITE Pierrick RD-RESA; jouni.nospam@gmail.com; dmm@ietf.org > Objet=A0: RE: [DMM] Comments on DMM Gap Analysis. >=20 > Hi Pierrick, Jouni, All, >=20 > | we have a good idea on what could be a DMM environment >=20 > Actually, I would like to see a concrete definition, say, of less than > 25 words, of what a "DMM environment" is. Pointers much appreciated. >=20 > Best Regards, >=20 > Kostas >=20 >=20 >=20 ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, France Telecom - Orange decline toute responsabilite si ce message a ete al= tere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, France Telecom - Orange is not liable for message= s that have been modified, changed or falsified. Thank you. From wes@mti-systems.com Wed Sep 26 12:31:48 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 F18B121F84B8 for ; Wed, 26 Sep 2012 12:31:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.388 X-Spam-Level: X-Spam-Status: No, score=-2.388 tagged_above=-999 required=5 tests=[AWL=0.211, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uTGwXLqkWHYb for ; Wed, 26 Sep 2012 12:31:47 -0700 (PDT) Received: from omr9.networksolutionsemail.com (omr9.networksolutionsemail.com [205.178.146.59]) by ietfa.amsl.com (Postfix) with ESMTP id 4DD9621F849D for ; Wed, 26 Sep 2012 12:31:47 -0700 (PDT) Received: from cm-omr4 (mail.networksolutionsemail.com [205.178.146.50]) by omr9.networksolutionsemail.com (8.13.8/8.13.8) with ESMTP id q8QJVkM0012872 for ; Wed, 26 Sep 2012 15:31:46 -0400 Authentication-Results: cm-omr4 smtp.user=wes@mti-systems.com; auth=pass (PLAIN) X-Authenticated-UID: wes@mti-systems.com Received: from [69.81.143.209] ([69.81.143.209:48982] helo=[192.168.1.116]) by cm-omr4 (envelope-from ) (ecelerity 2.2.2.41 r(31179/31189)) with ESMTPA id D6/2F-26629-22853605; Wed, 26 Sep 2012 15:31:46 -0400 Message-ID: <5063581D.5040403@mti-systems.com> Date: Wed, 26 Sep 2012 15:31:41 -0400 From: Wesley Eddy Organization: MTI Systems User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: sarikaya@ieee.org References: In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Cc: dmm@ietf.org, Behcet Sarikaya Subject: Re: [DMM] Comments on DMM Gap Analysis. 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, 26 Sep 2012 19:31:48 -0000 On 9/19/2012 12:14 PM, Behcet Sarikaya wrote: > Hi Jouni, > > I agree. > > I also suggest that we do not take cloud networks lightly. > Operator cloud networks are there already and it is spreading fast, > and I can say that soon it is going to cover all operators worldwide > soon. > > We should not ignore that fact that mobility entities will be in the > cloud. Also many entities we thought they were far away, with cloud > networks they will become neighbors in IPv6 sense. > > I suggest that gap analysis should take into account the cloud. > I think you'll need to be more specific about what you call an operator cloud network. If it is just services hosted within the operator network, I doubt that there's value in using the word "cloud". To the mobile node and rest of the infrastructure how a service is provided above layer-3 should not be of concern. As far as mobile nodes being part of a cloud, that's a totally different problem, is it not? I doubt that should be in scope here. DMM is hard enough without bringing this in. -- Wes Eddy MTI Systems From sarikaya2012@gmail.com Wed Sep 26 12:40:40 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 D1E3621F854A for ; Wed, 26 Sep 2012 12:40:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.434 X-Spam-Level: X-Spam-Status: No, score=-3.434 tagged_above=-999 required=5 tests=[AWL=0.165, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AG0P5YnZWyjg for ; Wed, 26 Sep 2012 12:40:40 -0700 (PDT) Received: from mail-ie0-f172.google.com (mail-ie0-f172.google.com [209.85.223.172]) by ietfa.amsl.com (Postfix) with ESMTP id 5942621F847D for ; Wed, 26 Sep 2012 12:40:40 -0700 (PDT) Received: by iec9 with SMTP id 9so2798879iec.31 for ; Wed, 26 Sep 2012 12:40:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=tJmOZldnSxR62bA/ou7VQcPcij/bDnraZk4zuNKxqvM=; b=lCBT+5n9J6arC+QIuibqD2akG0j8PYS4cpfNydBAbfltTrAMaEiOfUhPRqbW8cxYKE L13IxyunPfvdfLmJ47BuMSQLH4O5ag2fWA2TVbLsyttQ263MarUFrq1fVyQxjYhv6pU6 jdE/JRrumnFI/wrN9MglPYappf678WtHEHRL+9mdIkfEdtrHqGOabBAy0EVl0jbflQzk l3IFPtlm0yyX0szNVeymuEI65Urr7DwiyPgn8mzj1zenGA/fLPIGj+vTdrxz89FkIYb/ zRf99sfwMCIvEJlvA+afORRtxmnIgHT5d+pQUMwaaRO8gi2yvqAVBm5or5cFOge42eHK k+pQ== MIME-Version: 1.0 Received: by 10.50.53.170 with SMTP id c10mr1524695igp.45.1348688439751; Wed, 26 Sep 2012 12:40:39 -0700 (PDT) Received: by 10.231.55.70 with HTTP; Wed, 26 Sep 2012 12:40:39 -0700 (PDT) In-Reply-To: <5063581D.5040403@mti-systems.com> References: <5063581D.5040403@mti-systems.com> Date: Wed, 26 Sep 2012 14:40:39 -0500 Message-ID: From: Behcet Sarikaya To: Wesley Eddy Content-Type: text/plain; charset=ISO-8859-1 Cc: dmm@ietf.org Subject: Re: [DMM] Comments on DMM Gap Analysis. X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: sarikaya@ieee.org List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Sep 2012 19:40:40 -0000 I am talking about 3GPP entities like Serving Gateway and PDN Gateway being placed in the cloud. Regards, Behcet On Wed, Sep 26, 2012 at 2:31 PM, Wesley Eddy wrote: > On 9/19/2012 12:14 PM, Behcet Sarikaya wrote: >> Hi Jouni, >> >> I agree. >> >> I also suggest that we do not take cloud networks lightly. >> Operator cloud networks are there already and it is spreading fast, >> and I can say that soon it is going to cover all operators worldwide >> soon. >> >> We should not ignore that fact that mobility entities will be in the >> cloud. Also many entities we thought they were far away, with cloud >> networks they will become neighbors in IPv6 sense. >> >> I suggest that gap analysis should take into account the cloud. >> > > > I think you'll need to be more specific about what you call > an operator cloud network. > > If it is just services hosted within the operator network, > I doubt that there's value in using the word "cloud". To > the mobile node and rest of the infrastructure how a service > is provided above layer-3 should not be of concern. > > As far as mobile nodes being part of a cloud, that's a > totally different problem, is it not? I doubt that should > be in scope here. DMM is hard enough without bringing > this in. > > -- > Wes Eddy > MTI Systems > From wes@mti-systems.com Wed Sep 26 12:48:58 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 2991E21F8582 for ; Wed, 26 Sep 2012 12:48:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.402 X-Spam-Level: X-Spam-Status: No, score=-2.402 tagged_above=-999 required=5 tests=[AWL=0.197, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a4dP6IlhQYkW for ; Wed, 26 Sep 2012 12:48:57 -0700 (PDT) Received: from omr12.networksolutionsemail.com (omr12.networksolutionsemail.com [205.178.146.62]) by ietfa.amsl.com (Postfix) with ESMTP id 91F4121F8440 for ; Wed, 26 Sep 2012 12:48:57 -0700 (PDT) Received: from cm-omr3 (mail.networksolutionsemail.com [205.178.146.50]) by omr12.networksolutionsemail.com (8.13.8/8.13.8) with ESMTP id q8QJmuXG005371 for ; Wed, 26 Sep 2012 15:48:57 -0400 Authentication-Results: cm-omr3 smtp.user=wes@mti-systems.com; auth=pass (PLAIN) X-Authenticated-UID: wes@mti-systems.com Received: from [69.81.143.209] ([69.81.143.209:39695] helo=[192.168.1.116]) by cm-omr3 (envelope-from ) (ecelerity 2.2.2.41 r(31179/31189)) with ESMTPA id 33/84-16998-82C53605; Wed, 26 Sep 2012 15:48:56 -0400 Message-ID: <50635C23.50907@mti-systems.com> Date: Wed, 26 Sep 2012 15:48:51 -0400 From: Wesley Eddy Organization: MTI Systems User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: sarikaya@ieee.org References: <5063581D.5040403@mti-systems.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: dmm@ietf.org, Behcet Sarikaya Subject: Re: [DMM] Comments on DMM Gap Analysis. 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, 26 Sep 2012 19:48:58 -0000 On 9/26/2012 3:40 PM, Behcet Sarikaya wrote: > I am talking about 3GPP entities like Serving Gateway and PDN Gateway > being placed in the cloud. Sure, so they run on a VM somewhere ... what's the technical challenge that this poses? To the mobile node and rest of the DMM infrastructure, it should not matter whether these are physical or virtualized. -- Wes Eddy MTI Systems From sarikaya2012@gmail.com Wed Sep 26 13:08:10 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 08FEF21F85C0 for ; Wed, 26 Sep 2012 13:08:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.443 X-Spam-Level: X-Spam-Status: No, score=-3.443 tagged_above=-999 required=5 tests=[AWL=0.156, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X4UTYsDJxIMM for ; Wed, 26 Sep 2012 13:08:08 -0700 (PDT) Received: from mail-ie0-f172.google.com (mail-ie0-f172.google.com [209.85.223.172]) by ietfa.amsl.com (Postfix) with ESMTP id C0B3421F8592 for ; Wed, 26 Sep 2012 13:08:08 -0700 (PDT) Received: by iec9 with SMTP id 9so2874178iec.31 for ; Wed, 26 Sep 2012 13:08:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=bhTFFmI/Jq9UPJIaZRTq8rAsizbr28+78s74krymG9Y=; b=b/TX6U0UVUXl1tYs2C5zSwmp+mP9hHVrWW2ulw07znPNdjbc2T9iXFhhDvukSeOWGc mKFxkrDJUbfgaDBlqb7UiY9u+kOi/q2kzFk1YkN3wh69A/xQjBkq7kS46wnyQ5Sflp9x EILRyY3jOUmDzBSbOoUkuB4cJqTNF+yy2O3cbhRlGBKJ+Xtsb5akM5IOiBORBDFpveLd qMmM/QaZEbQ9iG83ZGbwx2a7BzwzE3Oud1cv84zzKOZlOyM/Bh+FfuDv/ysO+KXQEH/X FJXOV+7+C+AQOJLIYeDhWRh97WFQ38CBHng+iTmzvsT+YODk277TKiVCW9HSI3HKLc9G h/cw== MIME-Version: 1.0 Received: by 10.50.47.129 with SMTP id d1mr12390818ign.45.1348690088318; Wed, 26 Sep 2012 13:08:08 -0700 (PDT) Received: by 10.231.55.70 with HTTP; Wed, 26 Sep 2012 13:08:08 -0700 (PDT) In-Reply-To: <50635C23.50907@mti-systems.com> References: <5063581D.5040403@mti-systems.com> <50635C23.50907@mti-systems.com> Date: Wed, 26 Sep 2012 15:08:08 -0500 Message-ID: From: Behcet Sarikaya To: Wesley Eddy Content-Type: text/plain; charset=ISO-8859-1 Cc: dmm@ietf.org Subject: Re: [DMM] Comments on DMM Gap Analysis. X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: sarikaya@ieee.org List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Sep 2012 20:08:10 -0000 On Wed, Sep 26, 2012 at 2:48 PM, Wesley Eddy wrote: > On 9/26/2012 3:40 PM, Behcet Sarikaya wrote: >> I am talking about 3GPP entities like Serving Gateway and PDN Gateway >> being placed in the cloud. > > > Sure, so they run on a VM somewhere ... what's the technical > challenge that this poses? To the mobile node and rest of > the DMM infrastructure, it should not matter whether these > are physical or virtualized. DMM is based on the premise that mobility entities come closer to the UE and UE can access a different one as it moves. Central anchoring in PMIPv6 or MIPv6 is no longer there. With the cloud, two mobility entities may now become IPv6 neighbors in the cloud. Trying to define signaling between such entities maybe no longer a big issue. With cloud, DMM's premise somewhat disappears. We need to find a new premise. Regards, Behcet > > -- > Wes Eddy > MTI Systems From jouni.nospam@gmail.com Thu Sep 27 08:32: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 DB3C021F85F7 for ; Thu, 27 Sep 2012 08:32:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zVYlS9mJ1+Rj for ; Thu, 27 Sep 2012 08:32:49 -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 55C3D21F8508 for ; Thu, 27 Sep 2012 08:32:40 -0700 (PDT) Received: by weyu46 with SMTP id u46so782103wey.31 for ; Thu, 27 Sep 2012 08:32: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=XmgeGKWQ6BaC62WPIlf03CDpkHm8dd3yOJvUlfhPnw0=; b=Oj+J5X+fwGiBUWZkx8oaOGdgbQxWOGY2ILcAYh1tidr06EdnzXSqPyiKcbTRqlb+cr UGpsBMOPpb9JxA+EeyfEKE4eED7FEnaNlTXE55zFDTl/HZMtKtG4ctu2hDK3NWYWNsxm QQKeFjDU7rH2IHAyOjqCJXwwbq41Qsp7pHke5H2/Vp5NWqxIXDMB0yzc5/Un1YUg0bQy ufrAd12K7wN69dtN4udMJtrIy28lMNTAwj7Pn7TjmufKVAb1hE4F5k+KWqEdgWVkmnE3 Yr6crkgaFvN64GMv/rPxMh+C3nMl6SNcsS3J8rK2E9eVMmfZsJ1QL5/Lexp61mcdcErk P5Mg== Received: by 10.180.87.74 with SMTP id v10mr9132913wiz.21.1348759958404; Thu, 27 Sep 2012 08:32:38 -0700 (PDT) Received: from [10.116.0.72] (62-50-217-174.client.stsn.net. [62.50.217.174]) by mx.google.com with ESMTPS id dm3sm13738123wib.3.2012.09.27.08.32.34 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 27 Sep 2012 08:32:37 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: jouni korhonen In-Reply-To: Date: Thu, 27 Sep 2012 18:32:28 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <4A8DF83E-3D17-4C4E-B7FE-4DFADC98D6C0@gmail.com> References: <5063581D.5040403@mti-systems.com> <50635C23.50907@mti-systems.com> To: "sarikaya@ieee.org Sarikaya" , Wesley Eddy X-Mailer: Apple Mail (2.1084) Cc: dmm@ietf.org Subject: Re: [DMM] Comments on DMM Gap Analysis. 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, 27 Sep 2012 15:32:50 -0000 I am inclined to agree with Wes that DMM is hard enough already without having clouds arising in the horizon. Cloud computing and such has a=20 premise but I have hard time seeing how that would drive distributed mobility management. I rather see it as opposite.. shifting the mindset again towards centralized data centers. On the other hand if we just think mobility management entities as VMs, spawning new functions here and there does not differentiate from what we are already trying to figure out - from mobility protocols point of view. The difference would be that the possible gateway is not a = physical box anymore. The herding of VMs is not what we are tasked to do. - Jouni On Sep 26, 2012, at 11:08 PM, Behcet Sarikaya wrote: > On Wed, Sep 26, 2012 at 2:48 PM, Wesley Eddy = wrote: >> On 9/26/2012 3:40 PM, Behcet Sarikaya wrote: >>> I am talking about 3GPP entities like Serving Gateway and PDN = Gateway >>> being placed in the cloud. >>=20 >>=20 >> Sure, so they run on a VM somewhere ... what's the technical >> challenge that this poses? To the mobile node and rest of >> the DMM infrastructure, it should not matter whether these >> are physical or virtualized. >=20 > DMM is based on the premise that mobility entities come closer to the > UE and UE can access a different one as it moves. Central anchoring in > PMIPv6 or MIPv6 is no longer there. >=20 > With the cloud, two mobility entities may now become IPv6 neighbors in > the cloud. Trying to define signaling between such entities maybe no > longer a big issue. >=20 > With cloud, DMM's premise somewhat disappears. We need to find a new = premise. >=20 > Regards, >=20 > Behcet >=20 >=20 >>=20 >> -- >> Wes Eddy >> MTI Systems From sarikaya2012@gmail.com Thu Sep 27 09: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 AAF5321F85B1 for ; Thu, 27 Sep 2012 09:12:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.45 X-Spam-Level: X-Spam-Status: No, score=-3.45 tagged_above=-999 required=5 tests=[AWL=0.149, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IgvVQ8zLJ1Uh for ; Thu, 27 Sep 2012 09:12:33 -0700 (PDT) Received: from mail-ie0-f172.google.com (mail-ie0-f172.google.com [209.85.223.172]) by ietfa.amsl.com (Postfix) with ESMTP id 8191321F855A for ; Thu, 27 Sep 2012 09:12:33 -0700 (PDT) Received: by iec9 with SMTP id 9so5593672iec.31 for ; Thu, 27 Sep 2012 09:12:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=HcsUt1sOwZFCsQiQaoqJenF18rpDdTGsGsMO+DcyOYU=; b=FPmAvRREL4l0ijRN97C7kGOoHgY+MSik2ZXrq2mQcQIXfzbphWLRkMWXw730G+2Tjg yngTKkmZYiplTiAcFdoNAneiBt/C1dayyWGjm7m9s8bERRk6/a/FAhjkWgL52AeGZE3T 9dbTWgbGJ2C3DqAoM7sOH7DAXEW4qytvKdOHkTfm8cg+Zy957mMdW05TvpcF4/2n0L7W p19zU3oKKZclDWPpQdFlj6Xwzwh+1j+H7ocGDKAG8CtcVUY/wqB1eDPLca0umte4LEL9 hW6KrG+dL2CuEMaJz/L2rhnsMxB2kUW5cgqotT+pgJYHn4zM0ADlde/h8bBxLmVKWTLi aTKw== MIME-Version: 1.0 Received: by 10.50.47.129 with SMTP id d1mr14914975ign.45.1348762353103; Thu, 27 Sep 2012 09:12:33 -0700 (PDT) Received: by 10.231.55.70 with HTTP; Thu, 27 Sep 2012 09:12:32 -0700 (PDT) In-Reply-To: <4A8DF83E-3D17-4C4E-B7FE-4DFADC98D6C0@gmail.com> References: <5063581D.5040403@mti-systems.com> <50635C23.50907@mti-systems.com> <4A8DF83E-3D17-4C4E-B7FE-4DFADC98D6C0@gmail.com> Date: Thu, 27 Sep 2012 11:12:32 -0500 Message-ID: From: Behcet Sarikaya To: jouni korhonen Content-Type: text/plain; charset=ISO-8859-1 Cc: dmm@ietf.org Subject: Re: [DMM] Comments on DMM Gap Analysis. X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: sarikaya@ieee.org List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Sep 2012 16:12:38 -0000 On Thu, Sep 27, 2012 at 10:32 AM, jouni korhonen wrote: > > I am inclined to agree with Wes that DMM is hard enough already without > having clouds arising in the horizon. Cloud computing and such has a > premise but I have hard time seeing how that would drive distributed > mobility management. I rather see it as opposite.. shifting the mindset > again towards centralized data centers. > Yes, exactly. So cloud is going in a different direction then DMM, unfortunately. > On the other hand if we just think mobility management entities as VMs, > spawning new functions here and there does not differentiate from what > we are already trying to figure out - from mobility protocols point of > view. The difference would be that the possible gateway is not a physical > box anymore. The herding of VMs is not what we are tasked to do. > Here the issue is these VMs doing mobility functions. We need to develop a different set of goals for DMM implemented in VMs. What are the issues there? Certainly different than the issues we are considering now. Will control plane/data plane separation be the central issue? I am not saying we should not work on the current DMM direction. We can work on both. Regards, Behcet > - Jouni > > On Sep 26, 2012, at 11:08 PM, Behcet Sarikaya wrote: > >> On Wed, Sep 26, 2012 at 2:48 PM, Wesley Eddy wrote: >>> On 9/26/2012 3:40 PM, Behcet Sarikaya wrote: >>>> I am talking about 3GPP entities like Serving Gateway and PDN Gateway >>>> being placed in the cloud. >>> >>> >>> Sure, so they run on a VM somewhere ... what's the technical >>> challenge that this poses? To the mobile node and rest of >>> the DMM infrastructure, it should not matter whether these >>> are physical or virtualized. >> >> DMM is based on the premise that mobility entities come closer to the >> UE and UE can access a different one as it moves. Central anchoring in >> PMIPv6 or MIPv6 is no longer there. >> >> With the cloud, two mobility entities may now become IPv6 neighbors in >> the cloud. Trying to define signaling between such entities maybe no >> longer a big issue. >> >> With cloud, DMM's premise somewhat disappears. We need to find a new premise. >> >> Regards, >> >> Behcet >> >> >>> >>> -- >>> Wes Eddy >>> MTI Systems >