From Fred.L.Templin@boeing.com Wed Oct 5 11:22:21 2011 Return-Path: X-Original-To: mext@ietfa.amsl.com Delivered-To: mext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 52BC211E80CC for ; Wed, 5 Oct 2011 11:22:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.413 X-Spam-Level: X-Spam-Status: No, score=-5.413 tagged_above=-999 required=5 tests=[AWL=-0.891, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SUBJ_ALL_CAPS=2.077] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9PfgKVt8d2wf for ; Wed, 5 Oct 2011 11:22:20 -0700 (PDT) Received: from slb-smtpout-01.boeing.com (slb-smtpout-01.boeing.com [130.76.64.48]) by ietfa.amsl.com (Postfix) with ESMTP id 606AD11E80C5 for ; Wed, 5 Oct 2011 11:22:19 -0700 (PDT) Received: from stl-av-01.boeing.com (stl-av-01.boeing.com [192.76.190.6]) by slb-smtpout-01.ns.cs.boeing.com (8.14.4/8.14.4/8.14.4/SMTPOUT) with ESMTP id p95IPL7Q004518 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 5 Oct 2011 11:25:22 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by stl-av-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_RELAY) with SMTP id p95IPFLS014974; Wed, 5 Oct 2011 13:25:20 -0500 (CDT) Received: from XCH-NWHT-07.nw.nos.boeing.com (xch-nwht-07.nw.nos.boeing.com [130.247.25.111]) by stl-av-01.boeing.com (8.14.4/8.14.4/UPSTREAM_RELAY) with ESMTP id p95IP0EZ014346 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Wed, 5 Oct 2011 13:25:01 -0500 (CDT) Received: from XCH-NW-01V.nw.nos.boeing.com ([130.247.64.120]) by XCH-NWHT-07.nw.nos.boeing.com ([130.247.25.111]) with mapi; Wed, 5 Oct 2011 11:25:00 -0700 From: "Templin, Fred L" To: Ryuji Wakikawa , "sarikaya@ieee.org" Date: Wed, 5 Oct 2011 11:24:59 -0700 Thread-Topic: [MEXT] RFC 6301 Thread-Index: Acx+DGy2lyV9yOXtSF6hJHRoC/dE/AFf2XYw Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "mext@ietf.org" Subject: Re: [MEXT] RFC 6301 X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Oct 2011 18:22:21 -0000 The survey seems to have missed IRON (RFC6179), which along with its supporting technologies (VET, SEAL, AERO) comprehensively addresses the mobility solution space. Thanks - Fred > -----Original Message----- > From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] On=20 > Behalf Of Ryuji Wakikawa > Sent: Wednesday, September 28, 2011 11:28 AM > To: sarikaya@ieee.org > Cc: mext@ietf.org > Subject: Re: [MEXT] RFC 6301 >=20 > Hi Behcet >=20 > Thanks for the message. I believe there are plenty of=20 > potential issues MEXT group can solve... >=20 > ryuji >=20 > On 2011/09/27, at 14:59, Behcet Sarikaya wrote: >=20 > > Hi all, > > Have you seen this recently issued RFC 6301? I suggest=20 > taking a look at it. Good survey from way back 1991 to this=20 > date, thanks to Ryuji. > > It covers protocols like LISP and GTP (yes, GTP) and raises=20 > the issue of interworking such as between Mobile IP and HIP,=20 > I would add Mobile IP and SIP mobility. > >=20 > > Regards, > >=20 > > Behcet > >=20 > > _______________________________________________ > > MEXT mailing list > > MEXT@ietf.org > > https://www.ietf.org/mailman/listinfo/mext >=20 > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext > = From Fred.L.Templin@boeing.com Wed Oct 5 11:35:18 2011 Return-Path: X-Original-To: mext@ietfa.amsl.com Delivered-To: mext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B17301F0C41 for ; Wed, 5 Oct 2011 11:35:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.389 X-Spam-Level: X-Spam-Status: No, score=-5.389 tagged_above=-999 required=5 tests=[AWL=-0.867, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SUBJ_ALL_CAPS=2.077] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id liENCjGDBAeR for ; Wed, 5 Oct 2011 11:35:17 -0700 (PDT) Received: from slb-smtpout-01.boeing.com (slb-smtpout-01.boeing.com [130.76.64.48]) by ietfa.amsl.com (Postfix) with ESMTP id E10B521F8BEE for ; Wed, 5 Oct 2011 11:35:17 -0700 (PDT) Received: from blv-av-01.boeing.com (blv-av-01.boeing.com [130.247.48.231]) by slb-smtpout-01.ns.cs.boeing.com (8.14.4/8.14.4/8.14.4/SMTPOUT) with ESMTP id p95IcOH2014139 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 5 Oct 2011 11:38:25 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by blv-av-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_RELAY) with SMTP id p95IcOxI019442; Wed, 5 Oct 2011 11:38:24 -0700 (PDT) Received: from XCH-NWHT-05.nw.nos.boeing.com (xch-nwht-05.nw.nos.boeing.com [130.247.25.109]) by blv-av-01.boeing.com (8.14.4/8.14.4/UPSTREAM_RELAY) with ESMTP id p95IcLWi019408 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Wed, 5 Oct 2011 11:38:21 -0700 (PDT) Received: from XCH-NW-01V.nw.nos.boeing.com ([130.247.64.120]) by XCH-NWHT-05.nw.nos.boeing.com ([130.247.25.109]) with mapi; Wed, 5 Oct 2011 11:38:22 -0700 From: "Templin, Fred L" To: Ryuji Wakikawa , "sarikaya@ieee.org" Date: Wed, 5 Oct 2011 11:38:20 -0700 Thread-Topic: [MEXT] RFC 6301 Thread-Index: Acx+DGy2lyV9yOXtSF6hJHRoC/dE/AFf2XYwAABgG/A= Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "mext@ietf.org" Subject: Re: [MEXT] RFC 6301 X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Oct 2011 18:35:18 -0000 Also, I think I see an errata candidate in RFC6301: - [Boeing] Andrew, L., "A Border Gateway Protocol 4 (BGP-4)", - Boeing White Paper, 2006. I suspect this should instead be: + [Boeing] Dul, A., "Global IP Network Mobility using Border + Gateway Protocol (BGP)", Boeing White Paper, 2006. Thanks - Fred fred.l.templin@boeing.com > -----Original Message----- > From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] On=20 > Behalf Of Templin, Fred L > Sent: Wednesday, October 05, 2011 11:25 AM > To: Ryuji Wakikawa; sarikaya@ieee.org > Cc: mext@ietf.org > Subject: Re: [MEXT] RFC 6301 >=20 > The survey seems to have missed IRON (RFC6179), which > along with its supporting technologies (VET, SEAL, AERO) > comprehensively addresses the mobility solution space. >=20 > Thanks - Fred >=20 > > -----Original Message----- > > From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] On=20 > > Behalf Of Ryuji Wakikawa > > Sent: Wednesday, September 28, 2011 11:28 AM > > To: sarikaya@ieee.org > > Cc: mext@ietf.org > > Subject: Re: [MEXT] RFC 6301 > >=20 > > Hi Behcet > >=20 > > Thanks for the message. I believe there are plenty of=20 > > potential issues MEXT group can solve... > >=20 > > ryuji > >=20 > > On 2011/09/27, at 14:59, Behcet Sarikaya wrote: > >=20 > > > Hi all, > > > Have you seen this recently issued RFC 6301? I suggest=20 > > taking a look at it. Good survey from way back 1991 to this=20 > > date, thanks to Ryuji. > > > It covers protocols like LISP and GTP (yes, GTP) and raises=20 > > the issue of interworking such as between Mobile IP and HIP,=20 > > I would add Mobile IP and SIP mobility. > > >=20 > > > Regards, > > >=20 > > > Behcet > > >=20 > > > _______________________________________________ > > > MEXT mailing list > > > MEXT@ietf.org > > > https://www.ietf.org/mailman/listinfo/mext > >=20 > > _______________________________________________ > > MEXT mailing list > > MEXT@ietf.org > > https://www.ietf.org/mailman/listinfo/mext > >=20 > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext > = From internet-drafts@ietf.org Tue Oct 11 01:18:44 2011 Return-Path: X-Original-To: mext@ietfa.amsl.com Delivered-To: mext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 501AD21F8D1B; Tue, 11 Oct 2011 01:18:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.582 X-Spam-Level: X-Spam-Status: No, score=-102.582 tagged_above=-999 required=5 tests=[AWL=0.017, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1AH3mYnf1xVy; Tue, 11 Oct 2011 01:18:43 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD54D21F8D05; Tue, 11 Oct 2011 01:18:43 -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: 3.60 Message-ID: <20111011081843.21530.36283.idtracker@ietfa.amsl.com> Date: Tue, 11 Oct 2011 01:18:43 -0700 Cc: mext@ietf.org Subject: [MEXT] I-D Action: draft-ietf-mext-mip6-tls-02.txt X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Oct 2011 08:18:44 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Mobility EXTensions for IPv6 Working = Group of the IETF. Title : Transport Layer Security-based Mobile IPv6 Security Fram= ework for Mobile Node to Home Agent Communication Author(s) : Jouni Korhonen Basavaraj Patil Hannes Tschofenig Dirk Kroeselberg Filename : draft-ietf-mext-mip6-tls-02.txt Pages : 38 Date : 2011-10-11 Mobile IPv6 signaling between a mobile node and its home agent is secured using IPsec. The security association between a mobile node and the home agent is established using IKEv1 or IKEv2. The security model specified for Mobile IPv6, which relies on IKE/IPsec, requires interaction between the Mobile IPv6 protocol component and the IKE/ IPsec module of the IP stack. This document proposes an alternate security framework for Mobile IPv6 and Dual-Stack Mobile IPv6, which relies on Transport Layer Security for establishing keying material and other bootstrapping parameters required to protect Mobile IPv6 signaling and data traffic between the mobile node and home agent. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mext-mip6-tls-02.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-mext-mip6-tls-02.txt From Basavaraj.Patil@nokia.com Wed Oct 12 12:57:00 2011 Return-Path: X-Original-To: mext@ietfa.amsl.com Delivered-To: mext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 106CA21F8B1C for ; Wed, 12 Oct 2011 12:57:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.465 X-Spam-Level: X-Spam-Status: No, score=-102.465 tagged_above=-999 required=5 tests=[AWL=-0.467, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_21=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r4btXvDkNYX7 for ; Wed, 12 Oct 2011 12:56:59 -0700 (PDT) Received: from mgw-sa01.nokia.com (smtp.nokia.com [147.243.1.47]) by ietfa.amsl.com (Postfix) with ESMTP id CE20E21F8B04 for ; Wed, 12 Oct 2011 12:56:58 -0700 (PDT) Received: from vaebh102.NOE.Nokia.com (vaebh102.europe.nokia.com [10.160.244.23]) by mgw-sa01.nokia.com (Switch-3.4.4/Switch-3.4.3) with ESMTP id p9CJuktK029843; Wed, 12 Oct 2011 22:56:55 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.7]) by vaebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Wed, 12 Oct 2011 22:56:53 +0300 Received: from 008-AM1MMR1-001.mgdnok.nokia.com (65.54.30.56) by NOK-AM1MHUB-03.mgdnok.nokia.com (65.54.30.7) with Microsoft SMTP Server (TLS) id 8.2.255.0; Wed, 12 Oct 2011 21:56:53 +0200 Received: from 008-AM1MPN1-053.mgdnok.nokia.com ([169.254.3.208]) by 008-AM1MMR1-001.mgdnok.nokia.com ([65.54.30.56]) with mapi id 14.01.0339.002; Wed, 12 Oct 2011 21:56:53 +0200 From: To: , Thread-Topic: [MEXT] draft-bajko-mext-sod-01 Thread-Index: AQHMiRkVlVQRKLdns0uH4MLVYDBvZg== Date: Wed, 12 Oct 2011 19:56:52 +0000 Message-ID: In-Reply-To: <2979E38DD6FC6544B789C8DAD7BAFC520E0A8085@xmb-sjc-235.amer.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.12.0.110505 x-originating-ip: [173.74.219.186] Content-Type: multipart/alternative; boundary="_000_CABB5B24120BCbasavarajpatilnokiacom_" MIME-Version: 1.0 X-OriginalArrivalTime: 12 Oct 2011 19:56:53.0531 (UTC) FILETIME=[16B8F6B0:01CC8919] X-Nokia-AV: Clean Subject: Re: [MEXT] draft-bajko-mext-sod-01 X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Oct 2011 19:57:00 -0000 --_000_CABB5B24120BCbasavarajpatilnokiacom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Kent, Its been a while since you did the review. Finally getting back to updating the I-D and responding to your comments: >In the last IETF meeting, I signed up to review this draft and >provide my comments to the WG. Some may already be discussed. > >1) Sect. 1: s/cellular accesses/cellular access networks/ Okay. >2) Sect. 1: "that would unnecessarily consume resources on the HA >and radio resources on the access network" Okay. >3) Sect. 1: HA control is mentioned in "Furthermore, the operator >of HA may have policies .. security is to be used". But later "HA has >no ability to force the MN to secure user traffic". Clarify if SoD is >designed to include HA control in addition to MN control. Correct. MIP6 signaling today is primarily MN initiated. As a result it is straightforward for the MN to request the establishment of security for the user plane as needed by sending a binding update message to the HA. From the HA perspective, we only have the binding revocation message today which can be sent to an MN. This is the only unsolicited message that can be used by the HA to send a notification to the MN. SoD is indeed designed to allow user plane security to be initiated either by the MN or the HA. >4) Sect. 2: s/wifi_SSID/WiFi SSID/ Okay. >5) Sect. 2: Why MAC_address of the wifi network? Generally, it's >the WIFI SSID. Probably better to cover general logic and not get >into specific features. SSIDs can be spoofed quite easily. Of course so can MAC addresses. However an HA/Policy store may maintain SSID->MAC address mappings that help determining if the network to which an MN is attached secure and this information can trigger security to be enabled/disabled for the user plane traffic. That is the reason why MAC address is included here. >6) Sect. 2: "MN has either a stored policy ~ or it may be >provided with such information from policy stores such as ANDSF >[23.402] or AAA server ~" There is no interface between MN and AAA >server. So not clear how MN is able to obtain info stored on AAA >server. Also, PCRF may be another policy store. Right.. The MN does not have an interface with the AAA server. What we intended to say is that these policies are delivered to the MN at the time of access authentication. But its a good point and we need to provide more details of how the AAA provides the policies to the MN. One example of course is the use of ANDSF in 3GPP networks. The ANDSF can deliver policies to the MN using OMA-DM. >7) Sect. 2: "HA may require that the user plane traffic be >encrypted on the MN-HA link". No description of how this can be >accomplished. We intend to reuse the binding revocation message with a different semantic to enable this. Details about how this is done will be included in the next rev of the I-D. >8) Sect. 3: 'S' bit indicates encryption for user traffic. But >it~s not clear how encryption can be applied? First of all we are getting rid of the "S" bit and instead specifying a mobility option that enables multiple capabilities w.r.t security for the user plane traffic. The mobility option will indicate whether traffic needs to be ciphered or simply integrity protected. This is achieved by using the applicable type of SA. >9) Sect. 3: What happens if MN does not encrypt after HA >overwrites with S bit set to one? The HA drops the traffic. It could also send an error message to the MN. >10) Sect. 3: What happens if MN encrypt when HA does not want that? Same as above (9). >11) Sect. 3: There is no description of HA triggered SoD, though HA >control was implied in Sect. 1. Right. Please see response to (3) above. >12) Sect 4.2: What this option is in the draft? Location >information can be used for many types of operation, not specific to >SoD The location information can assist the policy store in the network in determining of security for the user plane traffic is required. Hence the option being included in the BU. >13) Sect. 5.: Hmm, Type value reservation needs IANA. Yes. >14) Sect. 6: It~s not clear if there is no impact to the security >model until further explanation provided on how the encryption is >applied. Encryption is applied by using an IPsec SA which is of type ESP tunneled. > >Overall, the I-D is a good start on the idea of SoD. It needs more >clarification on how the S bit interact with the mechanism that >actually provides the encryption/decryption function. Also, how does >SoD work when IKE/IPSec is providing the encryption/decryption. Thanks for your comments. Further clarifications in the next rev should address the shortcomings. Will appreciate your feedback once we post the new rev. -Raj > >Kent --_000_CABB5B24120BCbasavarajpatilnokiacom_ Content-Type: text/html; charset="us-ascii" Content-ID: <729F5B8F6A3967439120144AFDA70E52@nokia.com> Content-Transfer-Encoding: quoted-printable

Hi Kent,

Its been a while since you did the review. Finally getting back to
updating the I-D and responding to your comments:

>In the last IETF meeting, I signed up to review this draft and
>provide my comments to the WG.  Some may already be discussed= . 
> 
>1)      Sect. 1: s/cellular accesses/cellular acces= s networks/

Okay.

>2)      Sect. 1: "that would unnecessarily con= sume resources on the HA
>and radio resources on the access network" 

Okay.

>3)      Sect. 1: HA control is mentioned in "F= urthermore, the operator
>of HA may have policies .. security is to be used".  But= later "HA has
>no ability to force the MN to secure user traffic".  Cla= rify if SoD is
>designed to include HA control in addition to MN control. 

Correct. MIP6 signaling today is primarily MN initiated. As a result
it is straightforward for the MN to request the establishment of
security for the user plane as needed by sending a binding update
message to the HA. From the HA perspective, we only have the binding
revocation message today which can be sent to an MN. This is the only<= /div>
unsolicited message that can be used by the HA to send a notification<= /div>
to the MN. 
SoD is indeed designed to allow user plane security to be initiated
either by the MN or the HA.

>4)      Sect. 2: s/wifi_SSID/WiFi SSID/

Okay.

>5)      Sect. 2: Why MAC_address of the wifi networ= k?  Generally, it's
>the WIFI SSID.  Probably better to cover general logic and no= t get
>into specific features. 

SSIDs can be spoofed quite easily. Of course so can MAC
addresses. However an HA/Policy store may maintain SSID->MAC addres= s
mappings that help determining if the network to which an MN is
attached secure and this information can trigger security to be
enabled/disabled for the user plane traffic. That is the reason why
MAC address is included here.

>6)      Sect. 2: "MN has either a stored polic= y ~ or it may be
>provided with such information from policy stores such as ANDSF
>[23.402] or AAA server ~" There is no interface between MN an= d AAA
>server.  So not clear how MN is able to obtain info stored on= AAA
>server.  Also, PCRF may be another policy store. 

Right.. The MN does not have an interface with the AAA server. What we=
intended to say is that these policies are delivered to the MN at the<= /div>
time of access authentication. But its a good point and we need to
provide more details of how the AAA provides the policies to the MN.
One example of course is the use of ANDSF in 3GPP networks. The ANDSF<= /div>
can deliver policies to the MN using OMA-DM.

>7)      Sect. 2: "HA may require that the user= plane traffic be
>encrypted on the MN-HA link".  No description of how thi= s can be
>accomplished. 

We intend to reuse the binding revocation message with a different
semantic to enable this. Details about how this is done will be
included in the next rev of the I-D.

>8)      Sect. 3: 'S' bit indicates encryption for u= ser traffic.  But
>it~s not clear how encryption can be applied?  

First of all we are getting rid of the "S" bit and instead s= pecifying
a mobility option that enables multiple capabilities w.r.t security
for the user plane traffic. 
The mobility option will indicate whether traffic needs to be ciphered=
or simply integrity protected. This is achieved by using the
applicable type of SA.

>9)      Sect. 3: What happens if MN does not encryp= t after HA
>overwrites with S bit set to one? 

The HA drops the traffic. It could also send an error message to the
MN. 

>10)   Sect. 3: What happens if MN encrypt when HA does not wa= nt that?

Same as above (9).

>11)   Sect. 3: There is no description of HA triggered SoD, t= hough HA
>control was implied in Sect. 1. 

Right. Please see response to (3) above.

>12)   Sect 4.2: What  this option is in the draft?  = ;Location
>information can be used for many types of operation, not specific = to
>SoD 

The location information can assist the policy store in the network in=
determining of security for the user plane traffic is required. Hence<= /div>
the option being included in the BU.

>13)   Sect. 5.: Hmm, Type value reservation needs IANA.

Yes.

>14)   Sect. 6: It~s not clear if there is no impact to the se= curity
>model until further explanation provided on how the encryption is<= /div>
>applied. 

Encryption is applied by using an IPsec SA which is of type ESP
tunneled. 

> 
>Overall, the I-D is a good start on the idea of SoD.  It need= s more
>clarification on how the S bit interact with the mechanism that
>actually provides the encryption/decryption function.  Also, = how does
>SoD work when IKE/IPSec is providing the encryption/decryption. &n= bsp;

Thanks for your comments. Further clarifications in the next rev
should address the shortcomings. Will appreciate your feedback once we=
post the new rev.

-Raj

> 
>Kent
 
--_000_CABB5B24120BCbasavarajpatilnokiacom_-- From internet-drafts@ietf.org Mon Oct 17 11:04:02 2011 Return-Path: X-Original-To: mext@ietfa.amsl.com Delivered-To: mext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D10E411E808D; Mon, 17 Oct 2011 11:04:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.519 X-Spam-Level: X-Spam-Status: No, score=-102.519 tagged_above=-999 required=5 tests=[AWL=0.080, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gJPA8NGhjesT; Mon, 17 Oct 2011 11:04:02 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 75A5021F84B7; Mon, 17 Oct 2011 11:04:02 -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: 3.60 Message-ID: <20111017180402.564.57259.idtracker@ietfa.amsl.com> Date: Mon, 17 Oct 2011 11:04:02 -0700 Cc: mext@ietf.org Subject: [MEXT] I-D Action: draft-ietf-mext-firewall-admin-05.txt X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Oct 2011 18:04:03 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Mobility EXTensions for IPv6 Working = Group of the IETF. Title : Guidelines for firewall administrators regarding MIPv6 t= raffic Author(s) : Suresh Krishnan Niklas Steinleitner Ying Qiu Gabor Bajko Filename : draft-ietf-mext-firewall-admin-05.txt Pages : 12 Date : 2011-10-17 This document presents some recommendations for firewall administrators to help them configure their existing firewalls in a way that allows in certain deployment scenarios the Mobile IPv6 and DSMIPv6 signaling and data messages to pass through. For other scenarios, the support of additional mechanisms to create pinholes required for MIPv6 will be necessary. This document assumes that the firewalls in question include some kind of stateful packet filtering capability. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mext-firewall-admin-05.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-mext-firewall-admin-05.txt From internet-drafts@ietf.org Mon Oct 17 11:05:24 2011 Return-Path: X-Original-To: mext@ietfa.amsl.com Delivered-To: mext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C9C1111E8096; Mon, 17 Oct 2011 11:05:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.523 X-Spam-Level: X-Spam-Status: No, score=-102.523 tagged_above=-999 required=5 tests=[AWL=0.076, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CQ3XLwEkgJzg; Mon, 17 Oct 2011 11:05:24 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C8F011E8093; Mon, 17 Oct 2011 11:05:24 -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: 3.60 Message-ID: <20111017180524.673.21931.idtracker@ietfa.amsl.com> Date: Mon, 17 Oct 2011 11:05:24 -0700 Cc: mext@ietf.org Subject: [MEXT] I-D Action: draft-ietf-mext-firewall-vendor-05.txt X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Oct 2011 18:05:24 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Mobility EXTensions for IPv6 Working = Group of the IETF. Title : Guidelines for firewall vendors regarding MIPv6 traffic Author(s) : Suresh Krishnan Yaron Sheffer Niklas Steinleitner Gabor Bajko Filename : draft-ietf-mext-firewall-vendor-05.txt Pages : 8 Date : 2011-10-17 This document presents some recommendations for firewall vendors to help them implement their firewalls in a way that allows Mobile IPv6 and DSMIPv6 signaling and data messages to pass through. This document describes how to implement stateful packet filtering capability for MIPv6 and DSMIPv6. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mext-firewall-vendor-05.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-mext-firewall-vendor-05.txt From luo.wen@zte.com.cn Tue Oct 18 02:16:09 2011 Return-Path: X-Original-To: mext@ietfa.amsl.com Delivered-To: mext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A6CB921F8A69 for ; Tue, 18 Oct 2011 02:16:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.838 X-Spam-Level: X-Spam-Status: No, score=-101.838 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_DOUBLE_IP_LOOSE=0.76, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VmXaIHulwxxO for ; Tue, 18 Oct 2011 02:16:09 -0700 (PDT) Received: from mx5.zte.com.cn (mx6.zte.com.cn [95.130.199.165]) by ietfa.amsl.com (Postfix) with ESMTP id 955EC21F8A64 for ; Tue, 18 Oct 2011 02:16:08 -0700 (PDT) Received: from [10.30.17.99] by mx5.zte.com.cn with surfront esmtp id 466211783477680; Tue, 18 Oct 2011 17:09:44 +0800 (CST) Received: from [10.30.3.21] by [192.168.168.15] with StormMail ESMTP id 20387.6091098295; Tue, 18 Oct 2011 17:15:56 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse02.zte.com.cn with ESMTP id p9I9Fima083393; Tue, 18 Oct 2011 17:15:44 +0800 (GMT-8) (envelope-from luo.wen@zte.com.cn) To: marcelo bagnulo braun , Julien Laganier MIME-Version: 1.0 X-KeepSent: 9A2E7362:3BDF0852-4825792D:00318A0F; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 6.5.6 March 06, 2007 Message-ID: From: luo.wen@zte.com.cn Date: Tue, 18 Oct 2011 17:15:42 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.1FP4|July 25, 2010) at 2011-10-18 17:15:47, Serialize complete at 2011-10-18 17:15:47 Content-Type: multipart/alternative; boundary="=_alternative 0032DF594825792D_=" X-MAIL: mse02.zte.com.cn p9I9Fima083393 Cc: Dapeng Liu , "mext@ietf.org" Subject: [MEXT] A request to present a draft in MEXT, IETF82 X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Oct 2011 09:16:09 -0000 This is a multipart message in MIME format. --=_alternative 0032DF594825792D_= Content-Type: text/plain; charset="US-ASCII" Dear Chair: I request a slot (about 15min) to present a draft which is related to DMM during the meeting. For your reference, the draft 00-version can be reviewed in http://tools.ietf.org/html/draft-liu-dmm-pmip-based-approach-00. Please consider my request. BR LUOWEN --=_alternative 0032DF594825792D_= Content-Type: text/html; charset="US-ASCII"
Dear Chair:

I request a slot (about 15min) to present a draft which is related to DMMduring the meeting.

For your reference, the draft 00-version can be reviewed in http://tools.ietf.org/html/draft-liu-dmm-pmip-based-approach-00.

Please consider my request.

BR
LUOWEN --=_alternative 0032DF594825792D_=-- From h.anthony.chan@huawei.com Mon Oct 24 10:42:58 2011 Return-Path: X-Original-To: mext@ietfa.amsl.com Delivered-To: mext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6DCED11E80B7 for ; Mon, 24 Oct 2011 10:42:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JKRgVqkqgNPy for ; Mon, 24 Oct 2011 10:42:53 -0700 (PDT) Received: from szxga04-in.huawei.com (szxga04-in.huawei.com [119.145.14.67]) by ietfa.amsl.com (Postfix) with ESMTP id 940CA11E80AA for ; Mon, 24 Oct 2011 10:42:53 -0700 (PDT) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LTK00LF4ZVG41@szxga04-in.huawei.com> for mext@ietf.org; Tue, 25 Oct 2011 01:42:52 +0800 (CST) Received: from szxrg01-dlp.huawei.com ([172.24.2.119]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LTK00ANNZVG5N@szxga04-in.huawei.com> for mext@ietf.org; Tue, 25 Oct 2011 01:42:52 +0800 (CST) Received: from szxeml206-edg.china.huawei.com ([172.24.2.119]) by szxrg01-dlp.huawei.com (MOS 4.1.9-GA) with ESMTP id AEQ45935; Tue, 25 Oct 2011 01:42:52 +0800 Received: from SZXEML404-HUB.china.huawei.com (10.82.67.59) by szxeml206-edg.china.huawei.com (172.24.2.58) with Microsoft SMTP Server (TLS) id 14.1.270.1; Tue, 25 Oct 2011 01:42:50 +0800 Received: from SZXEML505-MBS.china.huawei.com ([169.254.2.127]) by szxeml404-hub.china.huawei.com ([::1]) with mapi id 14.01.0270.001; Tue, 25 Oct 2011 01:42:42 +0800 Date: Mon, 24 Oct 2011 17:42:41 +0000 From: h chan In-reply-to: X-Originating-IP: [10.192.11.138] To: mext Message-id: <6E31144C030982429702B11D6746B98C1927B7F1@SZXEML505-MBS.china.huawei.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-language: en-US Content-transfer-encoding: 7BIT Accept-Language: en-US, zh-CN Thread-topic: Requirements of DMM Thread-index: AcxQwhfLnuKfCPPY3k6t02z05yDwwQAAVYhPD+puflA= X-MS-Has-Attach: X-MS-TNEF-Correlator: x-cr-hashedpuzzle: PxA= Sc0= ARjJ Aew4 A+Th DC+E EhGq FNu3 GEl+ G7Lk HrwM H3+V Igoh IyfG JY/x JoB4; 1; bQBlAHgAdABAAGkAZQB0AGYALgBvAHIAZwA=; Sosha1_v1; 7; {A2338C7E-93FF-4475-9731-68F39DAE0EC9}; aAAuAGEAbgB0AGgAbwBuAHkALgBjAGgAYQBuAEAAaAB1AGEAdwBlAGkALgBjAG8AbQA=; Mon, 24 Oct 2011 17:42:37 GMT; UgBlAHEAdQBpAHIAZQBtAGUAbgB0AHMAIABvAGYAIABEAE0ATQA= x-cr-puzzleid: {A2338C7E-93FF-4475-9731-68F39DAE0EC9} X-CFilter-Loop: Reflected References: Subject: [MEXT] Requirements of DMM X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Oct 2011 17:42:58 -0000 There were discussions on the requirements of DMM in July. I think the email from Sri on the thread "LISP as a solution for some part of the DMM requirement" (which is also attached below) has also elaborated the DMM requirements. Let me try to rephrase in the following: 1. Distributed mobility requirement: The mobility management functions in interconnecting networks may be distributed over a number of smaller networks, and the mobility support for a session in a mobile node may be moved from one network to another network to avoid unnecessarily long route as the node moves. 2. Dynamic mobility requirement: A network supporting a mix of mobile nodes some of which may be stationary for extended time while others may be actively mobile may optimize its resources to avoid unnecessary mobility support. Comments please. H Anthony Chan -----Original Message----- From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] On Behalf Of Sri Gundavelli Sent: Monday, August 01, 2011 10:23 PM To: Seok-Joo Koh; Charles E. Perkins; mext Cc: dino@cisco.com Subject: Re: [MEXT] LISP as a solution for some part of the DMM requirement With respect to the solutions, there are multiple approaches that are on the table. To me, to achieve a flat distributed model, we need: - the ability to select a mobility anchor closer to the access network where the mobile node is attached. 3GPP Rel-10 has done quite a few enhancements on the aspects of gateway selection. Using the parameters eNB, APN, RNC-ID, BSC-ID, ...etc - the ability to re-anchor a session, or create a new session on a new anchor closer to the new attachment point - the ability to allow the mobile node to identify the assigned IP address properties, distinguish between an address assigned in the previous access network, from an address assigned in the current access network, so it can continue to use the new address for new sessions and phase out the older address/mobility session on the previous anchor over a period of time. In other words, enhancing the SAS rules with mobility awareness will give the needed session re-anchoring capabilities This approach gives me the gateway selection closer to the access network where the mobile node is attached and the needed optimized routing path. So, I'm trying to understand what are the expectation from the DMM efforts, beyond this. Sri On 8/1/11 8:13 PM, "Sri Gundavelli" wrote: > Hi Charlie, > > I agree, we have to look at other approaches and bring any value added > features to MIPv6/PMIPv6 protocols that its missing today. But, I've to say, > I'm still trying to understand the DMM problem statement and what DMM should > translate to: > > - Is it about optimized routing path ? This is very subjective and the > requirement may vary based on the use-case. Very much depends on the placement > of the anchor point. No solution on the table can ever solve this, unless we > assume the target site where the CN is located, or the ISP above is providing > some new location functions. This new location function, sure, can be a proxy > home agent at the global internet level too, for the argument sake, providing > direct path to the access network where the MN is currently attached. We also > have talked some time back on the Global HAHA, as an approach of session > re-anchoring. > > - Is it about moving from a centralized one box model to more distributed > zillion box model ? This sounds very promising on the paper. But, as we > discussed during the DMM BOF, rolling out a zillion pizza box type box anchors > sounds very cool. Sure, but we bring back ten-fold complexity in the form of > building distributed charging, Legal Intercept, DPI, Inline services, > hotlining, high-availability ...etc etc, which are now part of that one > central anchor box. It is to be noted, we have not seen a true distributed > service deployed in the internet today, other than DNS. But, I agree, if this > about building a true internet, who the heck cares about all of these > functions, in the true spirit. > > Either way, I assumed any of the new solution will be bound by the following > parameters: > > - The signaling protocol will continue to be based on MIPv6/PMIPv6 signaling > semantics. > > - We will not introduce a new client, what is now MIP client struggling to > make it to every variants of operating systems. > > - Any client-based solution will be an extension on top of DSMIP. Any > network-based solution will be an extension to PMIPv6 > > > > I hope we can discuss the solution approaches in the next meeting and bring > new extension to MIPv6/PMIPv6 protocols. > > > > > Regards > Sri > > > > > > > > > > > > > > > > > > > > > > > > > > > On 8/1/11 4:50 PM, "Seok-Joo Koh" wrote: > >> Dear Charles, >> >> I think the LISP can also be considered as a promising candidate >> in the design of DMM solutions. Several works are being progressed >> to use or extend the LISP for mobility support, which inlcude LISP-MN draft >> and many research papers. Actually, I am also considering how to extend >> the LISP scheme in the DMM perspective. >> >> LISP is a network-based ID-LOC separation scheme and thus it may give some >> advantages for effective mobility support. On the other hand, it is noted >> that >> the current version of LISP and LISP-MN may need to be more enhanced >> in terms of scalability in the mobile environment. For example, one concern >> of >> LISP >> is that the LISP EIDs may not be aggregated anymore in the mobile networks, >> since >> each mobile node will have its own distinctive EIDs that do not conform the >> concerned mobile domain. >> This may decrease the scaling benefits of original LISP. >> We may need to design a new enhanced EID structure to be used for mobile >> environment. >> Nontheless, it is worthwhile to consider LISP as a promisng candidate in the >> disign of DMM, I think. >> >> By the way, as I already said in this IETF DMM ad hoc meeting, the urgent >> action item of DMM is >> to make one or more introductory I-Ds with WG consensus, which may include >> the problem statements and requirements for DMM, use cases/scenarios, and >> comparison matrix, etc. >> >> Regards, >> >> ************************* >> Seok-Joo Koh >> http://protocol.knu.ac.kr/ >> ************************* >> _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From sjkoh@knu.ac.kr Mon Oct 24 16:56:59 2011 Return-Path: X-Original-To: mext@ietfa.amsl.com Delivered-To: mext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8763B21F8B58 for ; Mon, 24 Oct 2011 16:56:59 -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, STOX_REPLY_TYPE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m7qw2cmpqFZI for ; Mon, 24 Oct 2011 16:56:55 -0700 (PDT) Received: from spam2.knu.ac.kr (spam2.knu.ac.kr [155.230.10.253]) by ietfa.amsl.com (Postfix) with ESMTP id 2B5E321F8AF9 for ; Mon, 24 Oct 2011 16:56:52 -0700 (PDT) Received: from unknown (HELO knu.ac.kr) (155.230.11.8) by 155.230.10.253 with SMTP; 25 Oct 2011 08:55:58 +0900 X-Original-SENDERIP: 155.230.11.8 X-Original-MAILFROM: sjkoh@knu.ac.kr x-beehive-trace: sjkoh@knu.ac.kr mext@ietf.org 155.230.105.149 Received: from knu.ac.kr by ietf.org with ESMTP (knu.ac.kr) for mext@ietf.org; Tue, 25 Oct 2011 08:56:42 +0900 (KST) x-beehive-kind: normal x-beehive-modified: received kind Message-ID: <4F9AFA4F247D458BA29A91606B71716B@knucpl> From: "Seok-Joo Koh" To: "mext" References: <6E31144C030982429702B11D6746B98C1927B7F1@SZXEML505-MBS.china.huawei.com> Date: Tue, 25 Oct 2011 08:56:43 +0900 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6109 Subject: Re: [MEXT] Requirements of DMM X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Oct 2011 23:56:59 -0000 Anthony, Good initiation for discussion. As for the Distributed MM, it seems that some people are still confused with "Distributed MM" and "Local MM". What is the difference between them ? In the current sentence, it seems that the objective of DMM is "for route optimization".. Does it include "minimization of the traffic overhead in the control and data plane ? I think it is helpful to clarify the following issues.. - Terms (or definitions) of Distributed, Localized, Dynamic.. - Route optimization, minimization of traffic overhead, resource utilization,... Regards, ************************* Seok-Joo Koh http://protocol.knu.ac.kr/ ************************* ----- Original Message ----- From: "h chan" To: "mext" Sent: Tuesday, October 25, 2011 2:42 AM Subject: [MEXT] Requirements of DMM > > There were discussions on the requirements of DMM in July. > > I think the email from Sri on the thread "LISP as a solution for some part of the DMM requirement" > (which is also attached below) has also elaborated the DMM requirements. > > Let me try to rephrase in the following: > > 1. Distributed mobility requirement: The mobility management > functions in interconnecting networks may be distributed over a > number of smaller networks, and the mobility support for a > session in a mobile node may be moved from one network to another > network to avoid unnecessarily long route as the node moves. > > 2. Dynamic mobility requirement: A network supporting a mix of > mobile nodes some of which may be stationary for extended time > while others may be actively mobile may optimize its resources to > avoid unnecessary mobility support. > > Comments please. > > H Anthony Chan > > -----Original Message----- > From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] On Behalf Of Sri Gundavelli > Sent: Monday, August 01, 2011 10:23 PM > To: Seok-Joo Koh; Charles E. Perkins; mext > Cc: dino@cisco.com > Subject: Re: [MEXT] LISP as a solution for some part of the DMM requirement > > With respect to the solutions, there are multiple approaches that are on the > table. To me, to achieve a flat distributed model, we need: > > - the ability to select a mobility anchor closer to the access network where > the mobile node is attached. 3GPP Rel-10 has done quite a few enhancements > on the aspects of gateway selection. Using the parameters eNB, APN, RNC-ID, > BSC-ID, ...etc > > - the ability to re-anchor a session, or create a new session on a new > anchor closer to the new attachment point > > - the ability to allow the mobile node to identify the assigned IP address > properties, distinguish between an address assigned in the previous access > network, from an address assigned in the current access network, so it can > continue to use the new address for new sessions and phase out the older > address/mobility session on the previous anchor over a period of time. In > other words, enhancing the SAS rules with mobility awareness will give the > needed session re-anchoring capabilities > > This approach gives me the gateway selection closer to the access network > where the mobile node is attached and the needed optimized routing path. So, > I'm trying to understand what are the expectation from the DMM efforts, > beyond this. > > > Sri > > > > > On 8/1/11 8:13 PM, "Sri Gundavelli" wrote: > >> Hi Charlie, >> >> I agree, we have to look at other approaches and bring any value added >> features to MIPv6/PMIPv6 protocols that its missing today. But, I've to say, >> I'm still trying to understand the DMM problem statement and what DMM should >> translate to: >> >> - Is it about optimized routing path ? This is very subjective and the >> requirement may vary based on the use-case. Very much depends on the placement >> of the anchor point. No solution on the table can ever solve this, unless we >> assume the target site where the CN is located, or the ISP above is providing >> some new location functions. This new location function, sure, can be a proxy >> home agent at the global internet level too, for the argument sake, providing >> direct path to the access network where the MN is currently attached. We also >> have talked some time back on the Global HAHA, as an approach of session >> re-anchoring. >> >> - Is it about moving from a centralized one box model to more distributed >> zillion box model ? This sounds very promising on the paper. But, as we >> discussed during the DMM BOF, rolling out a zillion pizza box type box anchors >> sounds very cool. Sure, but we bring back ten-fold complexity in the form of >> building distributed charging, Legal Intercept, DPI, Inline services, >> hotlining, high-availability ...etc etc, which are now part of that one >> central anchor box. It is to be noted, we have not seen a true distributed >> service deployed in the internet today, other than DNS. But, I agree, if this >> about building a true internet, who the heck cares about all of these >> functions, in the true spirit. >> >> Either way, I assumed any of the new solution will be bound by the following >> parameters: >> >> - The signaling protocol will continue to be based on MIPv6/PMIPv6 signaling >> semantics. >> >> - We will not introduce a new client, what is now MIP client struggling to >> make it to every variants of operating systems. >> >> - Any client-based solution will be an extension on top of DSMIP. Any >> network-based solution will be an extension to PMIPv6 >> >> >> >> I hope we can discuss the solution approaches in the next meeting and bring >> new extension to MIPv6/PMIPv6 protocols. >> >> >> >> >> Regards >> Sri >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> On 8/1/11 4:50 PM, "Seok-Joo Koh" wrote: >> >>> Dear Charles, >>> >>> I think the LISP can also be considered as a promising candidate >>> in the design of DMM solutions. Several works are being progressed >>> to use or extend the LISP for mobility support, which inlcude LISP-MN draft >>> and many research papers. Actually, I am also considering how to extend >>> the LISP scheme in the DMM perspective. >>> >>> LISP is a network-based ID-LOC separation scheme and thus it may give some >>> advantages for effective mobility support. On the other hand, it is noted >>> that >>> the current version of LISP and LISP-MN may need to be more enhanced >>> in terms of scalability in the mobile environment. For example, one concern >>> of >>> LISP >>> is that the LISP EIDs may not be aggregated anymore in the mobile networks, >>> since >>> each mobile node will have its own distinctive EIDs that do not conform the >>> concerned mobile domain. >>> This may decrease the scaling benefits of original LISP. >>> We may need to design a new enhanced EID structure to be used for mobile >>> environment. >>> Nontheless, it is worthwhile to consider LISP as a promisng candidate in the >>> disign of DMM, I think. >>> >>> By the way, as I already said in this IETF DMM ad hoc meeting, the urgent >>> action item of DMM is >>> to make one or more introductory I-Ds with WG consensus, which may include >>> the problem statements and requirements for DMM, use cases/scenarios, and >>> comparison matrix, etc. >>> >>> Regards, >>> >>> ************************* >>> Seok-Joo Koh >>> http://protocol.knu.ac.kr/ >>> ************************* >>> > > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext From yanzhiwei@cnnic.cn Mon Oct 24 17:45:46 2011 Return-Path: X-Original-To: mext@ietfa.amsl.com Delivered-To: mext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 84BA711E80DB for ; Mon, 24 Oct 2011 17:45:46 -0700 (PDT) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER SECTION, Duplicate header field: "Message-ID" X-Spam-Flag: NO X-Spam-Score: 2.558 X-Spam-Level: ** X-Spam-Status: No, score=2.558 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, MSGID_FROM_MTA_HEADER=0.803] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yGLUMVHc59er for ; Mon, 24 Oct 2011 17:45:46 -0700 (PDT) Received: from cnnic.cn (smtp.cnnic.cn [159.226.7.146]) by ietfa.amsl.com (Postfix) with SMTP id 6D19821F8C98 for ; Mon, 24 Oct 2011 17:45:43 -0700 (PDT) Received: (eyou send program); Tue, 25 Oct 2011 08:45:42 +0800 Message-ID: <519503542.27702@cnnic.cn> X-EYOUMAIL-SMTPAUTH: yanzhiwei@cnnic.cn Received: from unknown (HELO lenovo-think) (218.241.111.47) by 159.226.7.146 with SMTP; Tue, 25 Oct 2011 08:45:42 +0800 Date: Tue, 25 Oct 2011 08:45:42 +0800 From: "yanzhiwei" To: "mext" References: <519482887.26346@cnnic.cn> Message-ID: <201110250845425045760@cnnic.cn> X-mailer: Foxmail 6, 15, 201, 22 [cn] Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=====001_Dragon453564210722_=====" Subject: [MEXT] New Submission Notification for draft-yan-mext-dnsmip-00.txt X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Oct 2011 00:45:46 -0000 This is a multi-part message in MIME format. --=====001_Dragon453564210722_===== Content-Type: multipart/alternative; boundary="=====003_Dragon453564210722_=====" --=====003_Dragon453564210722_===== Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: 7bit Dear all. I would like to let you know a new draft submitted: "draft-yan-mext-dnsmip-00.txt". The draft specifies the DNS update extension to Mobile IPv6 for the named MN. Specifically speaking, the FQND Option defined in the RFC 4704 is included in the Mobile IPv6 BU signaling message. The DNS update extension has been addressed in RFC 5026. The recommended mechanism from RFC 5026 is that the DNS update should be executed by the HA or AAA server, but not considering the MN's DNS update. In addition, it do not describe the PTR RR update processing. The proposed mechanism is based on RFC 4704 and covers the limitation of the DNS update of RFC 5026. Any comments are welcome. Zhiwei Yan 2011-10-25 yanzhiwei --=====003_Dragon453564210722_===== Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgY29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PWdi MjMxMiIgaHR0cC1lcXVpdj1Db250ZW50LVR5cGU+DQo8TUVUQSBuYW1lPUdFTkVSQVRPUiBjb250 ZW50PSJNU0hUTUwgOS4wMC44MTEyLjE2NDM3Ij4NCjxTVFlMRT5AZm9udC1mYWNlIHsNCglmb250 LWZhbWlseTogy87M5TsNCn0NCkBmb250LWZhY2Ugew0KCWZvbnQtZmFtaWx5OiBWZXJkYW5hOw0K fQ0KQGZvbnQtZmFjZSB7DQoJZm9udC1mYW1pbHk6IEDLzszlOw0KfQ0KQHBhZ2UgU2VjdGlvbjEg e3NpemU6IDU5NS4zcHQgODQxLjlwdDsgbWFyZ2luOiA3Mi4wcHQgOTAuMHB0IDcyLjBwdCA5MC4w cHQ7IGxheW91dC1ncmlkOiAxNS42cHQ7IH0NClAuTXNvTm9ybWFsIHsNCglURVhULUpVU1RJRlk6 IGludGVyLWlkZW9ncmFwaDsgVEVYVC1BTElHTjoganVzdGlmeTsgTUFSR0lOOiAwY20gMGNtIDBw dDsgRk9OVC1GQU1JTFk6ICJUaW1lcyBOZXcgUm9tYW4iOyBGT05ULVNJWkU6IDEwLjVwdA0KfQ0K TEkuTXNvTm9ybWFsIHsNCglURVhULUpVU1RJRlk6IGludGVyLWlkZW9ncmFwaDsgVEVYVC1BTElH TjoganVzdGlmeTsgTUFSR0lOOiAwY20gMGNtIDBwdDsgRk9OVC1GQU1JTFk6ICJUaW1lcyBOZXcg Um9tYW4iOyBGT05ULVNJWkU6IDEwLjVwdA0KfQ0KRElWLk1zb05vcm1hbCB7DQoJVEVYVC1KVVNU SUZZOiBpbnRlci1pZGVvZ3JhcGg7IFRFWFQtQUxJR046IGp1c3RpZnk7IE1BUkdJTjogMGNtIDBj bSAwcHQ7IEZPTlQtRkFNSUxZOiAiVGltZXMgTmV3IFJvbWFuIjsgRk9OVC1TSVpFOiAxMC41cHQN Cn0NCkE6bGluayB7DQoJQ09MT1I6IGJsdWU7IFRFWFQtREVDT1JBVElPTjogdW5kZXJsaW5lDQp9 DQpTUEFOLk1zb0h5cGVybGluayB7DQoJQ09MT1I6IGJsdWU7IFRFWFQtREVDT1JBVElPTjogdW5k ZXJsaW5lDQp9DQpBOnZpc2l0ZWQgew0KCUNPTE9SOiBwdXJwbGU7IFRFWFQtREVDT1JBVElPTjog dW5kZXJsaW5lDQp9DQpTUEFOLk1zb0h5cGVybGlua0ZvbGxvd2VkIHsNCglDT0xPUjogcHVycGxl OyBURVhULURFQ09SQVRJT046IHVuZGVybGluZQ0KfQ0KU1BBTi5FbWFpbFN0eWxlMTcgew0KCUZP TlQtU1RZTEU6IG5vcm1hbDsgRk9OVC1GQU1JTFk6IFZlcmRhbmE7IENPTE9SOiB3aW5kb3d0ZXh0 OyBGT05ULVdFSUdIVDogbm9ybWFsOyBURVhULURFQ09SQVRJT046IG5vbmU7IG1zby1zdHlsZS10 eXBlOiBwZXJzb25hbC1jb21wb3NlDQp9DQpESVYuU2VjdGlvbjEgew0KCXBhZ2U6IFNlY3Rpb24x DQp9DQpVTktOT1dOIHsNCglGT05ULVNJWkU6IDEwcHQNCn0NCkJMT0NLUVVPVEUgew0KCU1BUkdJ Ti1UT1A6IDBweDsgTUFSR0lOLUJPVFRPTTogMHB4OyBNQVJHSU4tTEVGVDogMmVtDQp9DQpPTCB7 DQoJTUFSR0lOLVRPUDogMHB4OyBNQVJHSU4tQk9UVE9NOiAwcHgNCn0NClVMIHsNCglNQVJHSU4t VE9QOiAwcHg7IE1BUkdJTi1CT1RUT006IDBweA0KfQ0KPC9TVFlMRT4NCjwvSEVBRD4NCjxCT0RZ IHN0eWxlPSJNQVJHSU46IDEwcHg7IEZPTlQtRkFNSUxZOiB2ZXJkYW5hOyBGT05ULVNJWkU6IDEw cHQiPg0KPERJVj48Rk9OVCBjb2xvcj0jMDAwMDgwIHNpemU9MiBmYWNlPVZlcmRhbmE+DQo8RElW PkRlYXImbmJzcDthbGwuPC9ESVY+DQo8RElWPjwvRElWPg0KPERJVj5JJm5ic3A7d291bGQmbmJz cDtsaWtlJm5ic3A7dG8mbmJzcDtsZXQmbmJzcDt5b3UmbmJzcDtrbm93Jm5ic3A7YSZuYnNwO25l dyZuYnNwO2RyYWZ0Jm5ic3A7c3VibWl0dGVkOiZuYnNwOyJkcmFmdC15YW4tbWV4dC1kbnNtaXAt MDAudHh0Ii48L0RJVj4NCjxESVY+VGhlJm5ic3A7ZHJhZnQmbmJzcDtzcGVjaWZpZXMmbmJzcDt0 aGUmbmJzcDtETlMmbmJzcDt1cGRhdGUmbmJzcDtleHRlbnNpb24mbmJzcDt0byZuYnNwO01vYmls ZSZuYnNwO0lQdjYmbmJzcDtmb3ImbmJzcDt0aGUmbmJzcDtuYW1lZCZuYnNwO01OLiZuYnNwOzwv RElWPg0KPERJVj5TcGVjaWZpY2FsbHkmbmJzcDtzcGVha2luZywmbmJzcDt0aGUmbmJzcDtGUU5E Jm5ic3A7T3B0aW9uJm5ic3A7ZGVmaW5lZCZuYnNwO2luJm5ic3A7dGhlJm5ic3A7UkZDJm5ic3A7 NDcwNCZuYnNwO2lzJm5ic3A7aW5jbHVkZWQmbmJzcDtpbiZuYnNwO3RoZSZuYnNwO01vYmlsZSZu YnNwO0lQdjYmbmJzcDtCVSZuYnNwO3NpZ25hbGluZyZuYnNwO21lc3NhZ2UuPC9ESVY+DQo8RElW PjwvRElWPg0KPERJVj5UaGUmbmJzcDtETlMmbmJzcDt1cGRhdGUmbmJzcDtleHRlbnNpb24mbmJz cDtoYXMmbmJzcDtiZWVuJm5ic3A7YWRkcmVzc2VkJm5ic3A7aW4mbmJzcDtSRkMmbmJzcDs1MDI2 LiZuYnNwO1RoZSZuYnNwO3JlY29tbWVuZGVkJm5ic3A7bWVjaGFuaXNtJm5ic3A7ZnJvbSZuYnNw O1JGQyZuYnNwOzUwMjYmbmJzcDtpcyZuYnNwOzwvRElWPg0KPERJVj50aGF0Jm5ic3A7dGhlJm5i c3A7RE5TJm5ic3A7dXBkYXRlJm5ic3A7c2hvdWxkJm5ic3A7YmUmbmJzcDtleGVjdXRlZCZuYnNw O2J5Jm5ic3A7dGhlJm5ic3A7SEEmbmJzcDtvciZuYnNwO0FBQSZuYnNwO3NlcnZlciwmbmJzcDti dXQmbmJzcDtub3QmbmJzcDtjb25zaWRlcmluZyZuYnNwO3RoZSZuYnNwO01OJ3MmbmJzcDtETlMm bmJzcDt1cGRhdGUuPC9ESVY+DQo8RElWPkluJm5ic3A7YWRkaXRpb24sJm5ic3A7aXQmbmJzcDtk byZuYnNwO25vdCZuYnNwO2Rlc2NyaWJlJm5ic3A7dGhlJm5ic3A7UFRSJm5ic3A7UlImbmJzcDt1 cGRhdGUmbmJzcDtwcm9jZXNzaW5nLjwvRElWPg0KPERJVj48L0RJVj4NCjxESVY+VGhlJm5ic3A7 cHJvcG9zZWQmbmJzcDttZWNoYW5pc20mbmJzcDtpcyZuYnNwO2Jhc2VkJm5ic3A7b24mbmJzcDtS RkMmbmJzcDs0NzA0Jm5ic3A7YW5kJm5ic3A7Y292ZXJzJm5ic3A7dGhlJm5ic3A7bGltaXRhdGlv biZuYnNwO29mJm5ic3A7dGhlJm5ic3A7RE5TJm5ic3A7dXBkYXRlJm5ic3A7b2YmbmJzcDtSRkMm bmJzcDs1MDI2LjwvRElWPg0KPERJVj48L0RJVj4NCjxESVY+QW55Jm5ic3A7Y29tbWVudHMmbmJz cDthcmUmbmJzcDt3ZWxjb21lLjwvRElWPg0KPERJVj5aaGl3ZWkgWWFuPC9ESVY+DQo8RElWPjwv RElWPjwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQgY29sb3I9IzAwMDA4MCBzaXplPTIgZmFjZT1W ZXJkYW5hPjwvRk9OVD4mbmJzcDs8L0RJVj4NCjxESVY+PEZPTlQgY29sb3I9IzAwMDA4MCBzaXpl PTIgZmFjZT1WZXJkYW5hPjwvRk9OVD4mbmJzcDs8L0RJVj4NCjxESVY+PEZPTlQgY29sb3I9I2Mw YzBjMCBzaXplPTIgZmFjZT1WZXJkYW5hPjIwMTEtMTAtMjUgPC9GT05UPjwvRElWPjxGT05UIA0K Y29sb3I9IzAwMDA4MCBzaXplPTIgZmFjZT1WZXJkYW5hPg0KPEhSIHN0eWxlPSJXSURUSDogMTAw cHgiIGFsaWduPWxlZnQgY29sb3I9I2I1YzRkZiBTSVpFPTE+DQo8L0ZPTlQ+DQo8RElWPjxGT05U IGNvbG9yPSNjMGMwYzAgc2l6ZT0yIGZhY2U9VmVyZGFuYT48U1BBTj55YW56aGl3ZWk8L1NQQU4+ IA0KPC9GT05UPjwvRElWPg0KPEhSIGNvbG9yPSNiNWM0ZGYgU0laRT0xPg0KDQo8RElWPjxGT05U IHNpemU9MiBmYWNlPVZlcmRhbmE+Jm5ic3A7PC9ESVY+PC9GT05UPjwvQk9EWT48L0hUTUw+DQo= --=====003_Dragon453564210722_=====-- --=====001_Dragon453564210722_===== Content-Type: text/x-vcard; name="yanzhiwei(1).vcf" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="yanzhiwei(1).vcf" QkVHSU46VkNBUkQNClZFUlNJT046Mi4xDQpOOnlhbnpoaXdlaTsNCkZOOnlhbnpoaXdlaQ0KT1JH OkNOTklDDQpFTUFJTDtQUkVGO0lOVEVSTkVUOnlhbnpoaXdlaUBjbm5pYy5jbg0KUkVWOjIwMTEx MDI1VDA4NDU0MloNCkVORDpWQ0FSRA0K --=====001_Dragon453564210722_=====-- From h.anthony.chan@huawei.com Wed Oct 26 11:22:05 2011 Return-Path: X-Original-To: mext@ietfa.amsl.com Delivered-To: mext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4382821F8B2E for ; Wed, 26 Oct 2011 11:22:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GIZt6sjOuh0R for ; Wed, 26 Oct 2011 11:22:00 -0700 (PDT) Received: from szxga04-in.huawei.com (szxga04-in.huawei.com [119.145.14.67]) by ietfa.amsl.com (Postfix) with ESMTP id A50A021F8880 for ; Wed, 26 Oct 2011 11:21:54 -0700 (PDT) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LTO00MSQR0H3W@szxga04-in.huawei.com> for mext@ietf.org; Thu, 27 Oct 2011 02:21:53 +0800 (CST) Received: from szxrg02-dlp.huawei.com ([172.24.2.119]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LTO00MLER0HRL@szxga04-in.huawei.com> for mext@ietf.org; Thu, 27 Oct 2011 02:21:53 +0800 (CST) Received: from szxeml207-edg.china.huawei.com ([172.24.2.119]) by szxrg02-dlp.huawei.com (MOS 4.1.9-GA) with ESMTP id AEL33970; Thu, 27 Oct 2011 02:21:51 +0800 Received: from SZXEML410-HUB.china.huawei.com (10.82.67.137) by szxeml207-edg.china.huawei.com (172.24.2.59) with Microsoft SMTP Server (TLS) id 14.1.270.1; Thu, 27 Oct 2011 02:21:47 +0800 Received: from SZXEML505-MBS.china.huawei.com ([169.254.2.127]) by szxeml410-hub.china.huawei.com ([10.82.67.137]) with mapi id 14.01.0270.001; Thu, 27 Oct 2011 02:21:44 +0800 Date: Wed, 26 Oct 2011 18:21:42 +0000 From: h chan In-reply-to: <4F9AFA4F247D458BA29A91606B71716B@knucpl> X-Originating-IP: [10.192.11.138] To: Seok-Joo Koh , mext Message-id: <6E31144C030982429702B11D6746B98C1927CC35@SZXEML505-MBS.china.huawei.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-language: en-US Content-transfer-encoding: 7BIT Accept-Language: en-US, zh-CN Thread-topic: [MEXT] Requirements of DMM Thread-index: AQHMkqj4VRCLKPw5n0KDwoB/mXv0HpWO5jxA X-MS-Has-Attach: X-MS-TNEF-Correlator: X-CFilter-Loop: Reflected References: <6E31144C030982429702B11D6746B98C1927B7F1@SZXEML505-MBS.china.huawei.com> <4F9AFA4F247D458BA29A91606B71716B@knucpl> Subject: Re: [MEXT] Requirements of DMM X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Oct 2011 18:22:05 -0000 Seok-Joo, I agree that the distinguishing feature of DMM needs to be clarified, but I don't know whether we can call that local MM. If the first part of the sentence is taken alone: "The mobility management functions in interconnecting networks may be distributed over a number of smaller networks," One can possibly "disintegrate" into that in a number of smaller networks which support mobility independently. Then the MM in each network may or may not be local depending on which protocol is used. Yet if each network has its own HA using the host-based MIP, the range to which the MN can move is still global. The distinction of DMM is in the second part of the sentence: "and the mobility anchor for a session in a mobile node may be moved from one network to another network to avoid unnecessarily long route as the node moves." If seems that the problem of triangle route is of highest interest. I think Raj had emphasized on this problem in his draft. If we don't want limiting to "to avoid unnecessarily long route," we can add other things such as "to minimize traffic overhead." But then there are other things it can achieve. An example is to enable the capability to better support mobility in the flat network by having a mobility anchor closer to the access network to which the MN is attached, (as pointed out in Sri's email) An alternative is not to mention the advantage at all. The second part of the sentence will simply be "and the mobility anchor for a session in a mobile node may be moved from one network to another network as the node moves." The advantages can then be mentioned separately, but not part of the concise requirement statement. H Anthony Chan -----Original Message----- From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] On Behalf Of Seok-Joo Koh Sent: Monday, October 24, 2011 6:57 PM To: mext Subject: Re: [MEXT] Requirements of DMM Anthony, Good initiation for discussion. As for the Distributed MM, it seems that some people are still confused with "Distributed MM" and "Local MM". What is the difference between them ? In the current sentence, it seems that the objective of DMM is "for route optimization".. Does it include "minimization of the traffic overhead in the control and data plane ? I think it is helpful to clarify the following issues.. - Terms (or definitions) of Distributed, Localized, Dynamic.. - Route optimization, minimization of traffic overhead, resource utilization,... Regards, ************************* Seok-Joo Koh http://protocol.knu.ac.kr/ ************************* ----- Original Message ----- From: "h chan" To: "mext" Sent: Tuesday, October 25, 2011 2:42 AM Subject: [MEXT] Requirements of DMM > > There were discussions on the requirements of DMM in July. > > I think the email from Sri on the thread "LISP as a solution for some part of the DMM requirement" > (which is also attached below) has also elaborated the DMM requirements. > > Let me try to rephrase in the following: > > 1. Distributed mobility requirement: The mobility management > functions in interconnecting networks may be distributed over a > number of smaller networks, and the mobility support for a > session in a mobile node may be moved from one network to another > network to avoid unnecessarily long route as the node moves. > > 2. Dynamic mobility requirement: A network supporting a mix of > mobile nodes some of which may be stationary for extended time > while others may be actively mobile may optimize its resources to > avoid unnecessary mobility support. > > Comments please. > > H Anthony Chan > > -----Original Message----- > From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] On Behalf Of Sri Gundavelli > Sent: Monday, August 01, 2011 10:23 PM > To: Seok-Joo Koh; Charles E. Perkins; mext > Cc: dino@cisco.com > Subject: Re: [MEXT] LISP as a solution for some part of the DMM requirement > > With respect to the solutions, there are multiple approaches that are on the > table. To me, to achieve a flat distributed model, we need: > > - the ability to select a mobility anchor closer to the access network where > the mobile node is attached. 3GPP Rel-10 has done quite a few enhancements > on the aspects of gateway selection. Using the parameters eNB, APN, RNC-ID, > BSC-ID, ...etc > > - the ability to re-anchor a session, or create a new session on a new > anchor closer to the new attachment point > > - the ability to allow the mobile node to identify the assigned IP address > properties, distinguish between an address assigned in the previous access > network, from an address assigned in the current access network, so it can > continue to use the new address for new sessions and phase out the older > address/mobility session on the previous anchor over a period of time. In > other words, enhancing the SAS rules with mobility awareness will give the > needed session re-anchoring capabilities > > This approach gives me the gateway selection closer to the access network > where the mobile node is attached and the needed optimized routing path. So, > I'm trying to understand what are the expectation from the DMM efforts, > beyond this. > > > Sri > > > > > On 8/1/11 8:13 PM, "Sri Gundavelli" wrote: > >> Hi Charlie, >> >> I agree, we have to look at other approaches and bring any value added >> features to MIPv6/PMIPv6 protocols that its missing today. But, I've to say, >> I'm still trying to understand the DMM problem statement and what DMM should >> translate to: >> >> - Is it about optimized routing path ? This is very subjective and the >> requirement may vary based on the use-case. Very much depends on the placement >> of the anchor point. No solution on the table can ever solve this, unless we >> assume the target site where the CN is located, or the ISP above is providing >> some new location functions. This new location function, sure, can be a proxy >> home agent at the global internet level too, for the argument sake, providing >> direct path to the access network where the MN is currently attached. We also >> have talked some time back on the Global HAHA, as an approach of session >> re-anchoring. >> >> - Is it about moving from a centralized one box model to more distributed >> zillion box model ? This sounds very promising on the paper. But, as we >> discussed during the DMM BOF, rolling out a zillion pizza box type box anchors >> sounds very cool. Sure, but we bring back ten-fold complexity in the form of >> building distributed charging, Legal Intercept, DPI, Inline services, >> hotlining, high-availability ...etc etc, which are now part of that one >> central anchor box. It is to be noted, we have not seen a true distributed >> service deployed in the internet today, other than DNS. But, I agree, if this >> about building a true internet, who the heck cares about all of these >> functions, in the true spirit. >> >> Either way, I assumed any of the new solution will be bound by the following >> parameters: >> >> - The signaling protocol will continue to be based on MIPv6/PMIPv6 signaling >> semantics. >> >> - We will not introduce a new client, what is now MIP client struggling to >> make it to every variants of operating systems. >> >> - Any client-based solution will be an extension on top of DSMIP. Any >> network-based solution will be an extension to PMIPv6 >> >> >> >> I hope we can discuss the solution approaches in the next meeting and bring >> new extension to MIPv6/PMIPv6 protocols. >> >> >> >> >> Regards >> Sri >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> On 8/1/11 4:50 PM, "Seok-Joo Koh" wrote: >> >>> Dear Charles, >>> >>> I think the LISP can also be considered as a promising candidate >>> in the design of DMM solutions. Several works are being progressed >>> to use or extend the LISP for mobility support, which inlcude LISP-MN draft >>> and many research papers. Actually, I am also considering how to extend >>> the LISP scheme in the DMM perspective. >>> >>> LISP is a network-based ID-LOC separation scheme and thus it may give some >>> advantages for effective mobility support. On the other hand, it is noted >>> that >>> the current version of LISP and LISP-MN may need to be more enhanced >>> in terms of scalability in the mobile environment. For example, one concern >>> of >>> LISP >>> is that the LISP EIDs may not be aggregated anymore in the mobile networks, >>> since >>> each mobile node will have its own distinctive EIDs that do not conform the >>> concerned mobile domain. >>> This may decrease the scaling benefits of original LISP. >>> We may need to design a new enhanced EID structure to be used for mobile >>> environment. >>> Nontheless, it is worthwhile to consider LISP as a promisng candidate in the >>> disign of DMM, I think. >>> >>> By the way, as I already said in this IETF DMM ad hoc meeting, the urgent >>> action item of DMM is >>> to make one or more introductory I-Ds with WG consensus, which may include >>> the problem statements and requirements for DMM, use cases/scenarios, and >>> comparison matrix, etc. >>> >>> Regards, >>> >>> ************************* >>> Seok-Joo Koh >>> http://protocol.knu.ac.kr/ >>> ************************* >>> > > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From h.anthony.chan@huawei.com Thu Oct 27 17:21:07 2011 Return-Path: X-Original-To: mext@ietfa.amsl.com Delivered-To: mext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 20CA61F0C3E for ; Thu, 27 Oct 2011 17:21:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m30BX0bfK713 for ; Thu, 27 Oct 2011 17:21:05 -0700 (PDT) Received: from szxga03-in.huawei.com (szxga03-in.huawei.com [119.145.14.66]) by ietfa.amsl.com (Postfix) with ESMTP id 19AB51F0C45 for ; Thu, 27 Oct 2011 17:21:03 -0700 (PDT) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LTR00JSU2B0EJ@szxga03-in.huawei.com> for mext@ietf.org; Fri, 28 Oct 2011 08:21:01 +0800 (CST) Received: from szxrg02-dlp.huawei.com ([172.24.2.119]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LTR00IY42B06C@szxga03-in.huawei.com> for mext@ietf.org; Fri, 28 Oct 2011 08:21:00 +0800 (CST) Received: from szxeml205-edg.china.huawei.com ([172.24.2.119]) by szxrg02-dlp.huawei.com (MOS 4.1.9-GA) with ESMTP id AEM17886; Fri, 28 Oct 2011 08:21:00 +0800 Received: from SZXEML406-HUB.china.huawei.com (10.82.67.93) by szxeml205-edg.china.huawei.com (172.24.2.57) with Microsoft SMTP Server (TLS) id 14.1.270.1; Fri, 28 Oct 2011 08:20:51 +0800 Received: from SZXEML505-MBS.china.huawei.com ([169.254.2.127]) by szxeml406-hub.china.huawei.com ([10.82.67.93]) with mapi id 14.01.0270.001; Fri, 28 Oct 2011 08:20:49 +0800 Date: Fri, 28 Oct 2011 00:20:49 +0000 From: h chan In-reply-to: <6E31144C030982429702B11D6746B98C1927CC35@SZXEML505-MBS.china.huawei.com> X-Originating-IP: [10.192.11.138] To: "rute.sofia@ulusofona.pt" , mext Message-id: <6E31144C030982429702B11D6746B98C1927CEC8@SZXEML505-MBS.china.huawei.com> MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-language: en-US Content-transfer-encoding: quoted-printable Accept-Language: en-US, zh-CN Thread-topic: [MEXT] Requirements of DMM Thread-index: AQHMkqj4VRCLKPw5n0KDwoB/mXv0HpWO5jxAgAIAGeA= X-MS-Has-Attach: X-MS-TNEF-Correlator: X-CFilter-Loop: Reflected References: <6E31144C030982429702B11D6746B98C1927B7F1@SZXEML505-MBS.china.huawei.com> <4F9AFA4F247D458BA29A91606B71716B@knucpl> <6E31144C030982429702B11D6746B98C1927CC35@SZXEML505-MBS.china.huawei.com> Subject: Re: [MEXT] Requirements of DMM X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Oct 2011 00:21:07 -0000 Rute, You are welcome to join the DMM discussions and contribute to the work, esp= ecially as your research is so relevant to it. However, DMM has become part= of MEXT so that the DMM discussions need to use the mext mailing list.=20 If you have not subscribed to the mext mailing list, you can subscribe now = and then you can send email directly to mext@ietf.org . If you are not on the mext mailing list, I can forward to the mext so that = the other mext members can see your comments.=20 Here I take the liberty of copying one important point in your suggestion t= o the MEXT mailing list:=20 Lack of user-centricity The mobility anchor point, as the main element of a mobility management sys= tem, has been object of intensive studies in order to create more distribut= ed and decentralized systems. Accordingly, its role, its functionalities an= d the location it should take in the network (e.g. router, server, etc) are= not a consensus. Depending on the architecture, on the network characteris= tics and on the functionalities we have in the mobility anchor element, its= location may vary, and its function in the whole system may change. Consid= ering that user-centric networks present particular characteristics (e.g. t= here is no clear splitting between network elements and end-devices), the c= urrent centralized standards may not be suitable. Thus, a novel mobility ma= nagement approach should be designed for such networks, considering all its= particularities and following this trend of rethinking the mobility anchor= point element. These aspects reinforce the need for distributed and dynamic mobility mecha= nisms. Positioning the anchor-point in network elements closer to the end u= ser provides the capability to have a more flexible mobility management ser= vice, with (potentially) more control in terms of users expectations; it al= so assists the access operation by lowering the operation complexity. For i= nstance, traffic locality can be more easily achieved by having mobility ma= nagement functionality deployed in elements that are closer to customer pre= mises, or on the edges of the access network. H Anthony Chan >> ----- Original Message ----- >> From: "Rute Sofia" To: >> Sent: Monday, July 04, 2011 6:41 AM >> Subject: DMM, Mext relation and potential contribution to the draft=20 >> on problem statement >> >> >> Hello Anthony, >> >> we have been following some work concerning DMM in Mext. >> >> We have a project which focus on most of these aspects (UMM: >> user-centric mobility management, 2009-2012, see=20 >> http://siti.ulusofona.pt/~umm). It is focused not only on=20 >> decentralization of mobility functionality but also on the potential=20 >> decoupling. this is a Portuguese project, developed between two R&D >> units: SITI, my unit (http://siti.ulusofona.pt) and the Instituto of=20 >> Telecomunica=E7=F5es in Aveiro. >> Some initial publications: >> >> http://siti.ulusofona.pt/aigaion/index.php/keywords/single/12 >> http://siti.ulusofona.pt/aigaion/index.php/publications/show/43 >> >> >> I have checked the problem statement draft >> (draft-chan-distributed-mobility-ps-01) and would like to know if you=20 >> are still open to input. We believe that there is valuable input to=20 >> the current draft... >> >> Best Regards, >> Rute Sofia >> >> > > > -- > Rute Sofia, PhD (rute.sofia@ulusofona.pt) Scientific Director for=20 > Technology Research Unit in Informatics Systems and Technologies=20 > (SITI) Coordinator of the Internet Architecture and Networking Lab=20 > (IAN Lab) University Lusofona, Portugal rute.sofia@ulusofona.pt > > http://siti.ulusofona.pt > Tel.: 217 515 500 Fax: 21 757 7006 > ....................................................... > > -----Original Message----- From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] On Behalf Of h c= han Sent: Wednesday, October 26, 2011 1:22 PM To: Seok-Joo Koh; mext Subject: Re: [MEXT] Requirements of DMM Seok-Joo, I agree that the distinguishing feature of DMM needs to be clarified, but I= don't know whether we can call that local MM. =20 If the first part of the sentence is taken alone: "The mobility management functions in interconnecting networks may be distr= ibuted over a number of smaller networks," One can possibly "disintegrate" into that in a number of smaller networks w= hich support mobility independently. Then the MM in each network may or may= not be local depending on which protocol is used. Yet if each network has = its own HA using the host-based MIP, the range to which the MN can move is = still global.=20 The distinction of DMM is in the second part of the sentence: "and the mobility anchor for a session in a mobile node may be moved from o= ne network to another network to avoid unnecessarily long route as the node= moves." If seems that the problem of triangle route is of highest interest. I think= Raj had emphasized on this problem in his draft.=20 If we don't want limiting to "to avoid unnecessarily long route," we can add other things such as "to minimize traffic overhead." But then there are other things it can achieve.=20 An example is to enable the capability to better support mobility in the fl= at network by having a mobility anchor closer to the access network to whic= h the MN is attached, (as pointed out in Sri's email) An alternative is not to mention the advantage at all.=20 The second part of the sentence will simply be "and the mobility anchor for a session in a mobile node may be moved from o= ne network to another network as the node moves." The advantages can then be mentioned separately, but not part of the concis= e requirement statement.=20 H Anthony Chan -----Original Message----- From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] On Behalf Of Seo= k-Joo Koh Sent: Monday, October 24, 2011 6:57 PM To: mext Subject: Re: [MEXT] Requirements of DMM Anthony, Good initiation for discussion. As for the Distributed MM, it seems that some people are still confused wit= h "Distributed MM" and=20 "Local MM". What is the difference between them ? In the current sentence, it seems that the objective of DMM is "for route o= ptimization".. Does it include "minimization of the traffic overhead in the control and da= ta plane ? I think it is helpful to clarify the following issues.. - Terms (or definitions) of Distributed, Localized, Dynamic.. - Route optimization, minimization of traffic overhead, resource utilizatio= n,... Regards, ************************* Seok-Joo Koh http://protocol.knu.ac.kr/ ************************* ----- Original Message -----=20 From: "h chan" To: "mext" Sent: Tuesday, October 25, 2011 2:42 AM Subject: [MEXT] Requirements of DMM > > There were discussions on the requirements of DMM in July. > > I think the email from Sri on the thread "LISP as a solution for some par= t of the DMM requirement"=20 > (which is also attached below) has also elaborated the DMM requirements. > > Let me try to rephrase in the following: > > 1. Distributed mobility requirement: The mobility management > functions in interconnecting networks may be distributed over a > number of smaller networks, and the mobility support for a > session in a mobile node may be moved from one network to another > network to avoid unnecessarily long route as the node moves. > > 2. Dynamic mobility requirement: A network supporting a mix of > mobile nodes some of which may be stationary for extended time > while others may be actively mobile may optimize its resources to > avoid unnecessary mobility support. > > Comments please. > > H Anthony Chan > > -----Original Message----- > From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] On Behalf Of S= ri Gundavelli > Sent: Monday, August 01, 2011 10:23 PM > To: Seok-Joo Koh; Charles E. Perkins; mext > Cc: dino@cisco.com > Subject: Re: [MEXT] LISP as a solution for some part of the DMM requireme= nt > > With respect to the solutions, there are multiple approaches that are on = the > table. To me, to achieve a flat distributed model, we need: > > - the ability to select a mobility anchor closer to the access network wh= ere > the mobile node is attached. 3GPP Rel-10 has done quite a few enhancement= s > on the aspects of gateway selection. Using the parameters eNB, APN, RNC-I= D, > BSC-ID, ...etc > > - the ability to re-anchor a session, or create a new session on a new > anchor closer to the new attachment point > > - the ability to allow the mobile node to identify the assigned IP addres= s > properties, distinguish between an address assigned in the previous acces= s > network, from an address assigned in the current access network, so it ca= n > continue to use the new address for new sessions and phase out the older > address/mobility session on the previous anchor over a period of time. In > other words, enhancing the SAS rules with mobility awareness will give th= e > needed session re-anchoring capabilities > > This approach gives me the gateway selection closer to the access network > where the mobile node is attached and the needed optimized routing path. = So, > I'm trying to understand what are the expectation from the DMM efforts, > beyond this. > > > Sri > > > > > On 8/1/11 8:13 PM, "Sri Gundavelli" wrote: > >> Hi Charlie, >> >> I agree, we have to look at other approaches and bring any value added >> features to MIPv6/PMIPv6 protocols that its missing today. But, I've to = say, >> I'm still trying to understand the DMM problem statement and what DMM sh= ould >> translate to: >> >> - Is it about optimized routing path ? This is very subjective and the >> requirement may vary based on the use-case. Very much depends on the pla= cement >> of the anchor point. No solution on the table can ever solve this, unles= s we >> assume the target site where the CN is located, or the ISP above is prov= iding >> some new location functions. This new location function, sure, can be a = proxy >> home agent at the global internet level too, for the argument sake, prov= iding >> direct path to the access network where the MN is currently attached. We= also >> have talked some time back on the Global HAHA, as an approach of session >> re-anchoring. >> >> - Is it about moving from a centralized one box model to more distribute= d >> zillion box model ? This sounds very promising on the paper. But, as we >> discussed during the DMM BOF, rolling out a zillion pizza box type box a= nchors >> sounds very cool. Sure, but we bring back ten-fold complexity in the for= m of >> building distributed charging, Legal Intercept, DPI, Inline services, >> hotlining, high-availability ...etc etc, which are now part of that one >> central anchor box. It is to be noted, we have not seen a true distribut= ed >> service deployed in the internet today, other than DNS. But, I agree, i= f this >> about building a true internet, who the heck cares about all of these >> functions, in the true spirit. >> >> Either way, I assumed any of the new solution will be bound by the follo= wing >> parameters: >> >> - The signaling protocol will continue to be based on MIPv6/PMIPv6 signa= ling >> semantics. >> >> - We will not introduce a new client, what is now MIP client struggling = to >> make it to every variants of operating systems. >> >> - Any client-based solution will be an extension on top of DSMIP. Any >> network-based solution will be an extension to PMIPv6 >> >> >> >> I hope we can discuss the solution approaches in the next meeting and br= ing >> new extension to MIPv6/PMIPv6 protocols. >> >> >> >> >> Regards >> Sri >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> On 8/1/11 4:50 PM, "Seok-Joo Koh" wrote: >> >>> Dear Charles, >>> >>> I think the LISP can also be considered as a promising candidate >>> in the design of DMM solutions. Several works are being progressed >>> to use or extend the LISP for mobility support, which inlcude LISP-MN d= raft >>> and many research papers. Actually, I am also considering how to extend >>> the LISP scheme in the DMM perspective. >>> >>> LISP is a network-based ID-LOC separation scheme and thus it may give s= ome >>> advantages for effective mobility support. On the other hand, it is not= ed >>> that >>> the current version of LISP and LISP-MN may need to be more enhanced >>> in terms of scalability in the mobile environment. For example, one con= cern >>> of >>> LISP >>> is that the LISP EIDs may not be aggregated anymore in the mobile netwo= rks, >>> since >>> each mobile node will have its own distinctive EIDs that do not conform= the >>> concerned mobile domain. >>> This may decrease the scaling benefits of original LISP. >>> We may need to design a new enhanced EID structure to be used for mobil= e >>> environment. >>> Nontheless, it is worthwhile to consider LISP as a promisng candidate i= n the >>> disign of DMM, I think. >>> >>> By the way, as I already said in this IETF DMM ad hoc meeting, the urge= nt >>> action item of DMM is >>> to make one or more introductory I-Ds with WG consensus, which may incl= ude >>> the problem statements and requirements for DMM, use cases/scenarios, a= nd >>> comparison matrix, etc. >>> >>> Regards, >>> >>> ************************* >>> Seok-Joo Koh >>> http://protocol.knu.ac.kr/ >>> ************************* >>> > > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext=20 _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From jari.arkko@piuha.net Fri Oct 28 05:08:45 2011 Return-Path: X-Original-To: mext@ietfa.amsl.com Delivered-To: mext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A28C21F8B62 for ; Fri, 28 Oct 2011 05:08:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.59 X-Spam-Level: X-Spam-Status: No, score=-102.59 tagged_above=-999 required=5 tests=[AWL=0.009, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Be9eGaUts3Cw for ; Fri, 28 Oct 2011 05:08:44 -0700 (PDT) Received: from p130.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by ietfa.amsl.com (Postfix) with ESMTP id 450A021F84A1 for ; Fri, 28 Oct 2011 05:08:44 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 9937E2CC4A; Fri, 28 Oct 2011 15:08:43 +0300 (EEST) X-Virus-Scanned: amavisd-new at piuha.net Received: from p130.piuha.net ([127.0.0.1]) by localhost (p130.piuha.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IX18UKOrMIxX; Fri, 28 Oct 2011 15:08:43 +0300 (EEST) Received: from [127.0.0.1] (p130.piuha.net [IPv6:2001:14b8:400::130]) by p130.piuha.net (Postfix) with ESMTP id 10B1C2CC44; Fri, 28 Oct 2011 15:08:43 +0300 (EEST) Message-ID: <4EAA9B4A.3020208@piuha.net> Date: Fri, 28 Oct 2011 15:08:42 +0300 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: "mext@ietf.org" , "jouni.korhonen@nsn.com" , marcelo bagnulo braun Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [MEXT] the future of the MEXT working group X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Oct 2011 12:08:45 -0000 All, We are making some changes to the working group. While we have successfully published a large number of specifications in recent years, recently it has been difficult to make progress in the group. The chairs and ADs have looked at the situation and we believe we need a new focus and a bit of new organization as well. We are terminating the working group and moving the one remaining active work item to a new working group, the "DMM" working group. Here's what is going to happen: o Jouni Korhonen and Julien Laganier will become the chairs of the group. o The group will meet in Taipei (there is a MEXT slot in the agenda). o The charter of the group will be changed to focus only on the distributed mobility effort. We should discuss the details of this charter change both on the list and in the meeting. The meeting agenda should reserve some time both for technical discussions as well as the charter discussion. o Once the discussion on the list and in the meeting has finished, we will rename the group to "DMM" and put the new charter in effect. o If there are any other specifications that people would like to publish beyond the distributed mobility work, we can offer to AD sponsor them to RFCs outside the new working group. If there is some significant new activity, we can create new working groups for that. Comments and feedback and/or alternate suggestions on this plan are welcome. We would like to thank Marcelo for your many years of service in MEXT. We could not have completed all the work we did without your energy and push for high quality results. We would also like to thank Jouni for taking on this new challenge, and Julien for continuing the work in this space. Jari and Ralph From jari.arkko@piuha.net Fri Oct 28 05:21:16 2011 Return-Path: X-Original-To: mext@ietfa.amsl.com Delivered-To: mext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B8FE21F8B84 for ; Fri, 28 Oct 2011 05:21:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.704 X-Spam-Level: X-Spam-Status: No, score=-101.704 tagged_above=-999 required=5 tests=[AWL=-0.878, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457, SARE_MILLIONSOF=0.315, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R-689+T1tEzm for ; Fri, 28 Oct 2011 05:21:13 -0700 (PDT) Received: from p130.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by ietfa.amsl.com (Postfix) with ESMTP id 905B921F8B4C for ; Fri, 28 Oct 2011 05:21:11 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id E34AE2CC44 for ; Fri, 28 Oct 2011 15:21:10 +0300 (EEST) X-Virus-Scanned: amavisd-new at piuha.net Received: from p130.piuha.net ([127.0.0.1]) by localhost (p130.piuha.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SRzH7X-txbt4 for ; Fri, 28 Oct 2011 15:21:09 +0300 (EEST) Received: from [127.0.0.1] (p130.piuha.net [IPv6:2001:14b8:400::130]) by p130.piuha.net (Postfix) with ESMTP id 2664B2CC3B for ; Fri, 28 Oct 2011 15:21:09 +0300 (EEST) Message-ID: <4EAA9E34.2080903@piuha.net> Date: Fri, 28 Oct 2011 15:21:08 +0300 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: "mext@ietf.org" References: <4EAA9B4A.3020208@piuha.net> In-Reply-To: <4EAA9B4A.3020208@piuha.net> Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [MEXT] the future of the MEXT working group X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Oct 2011 12:21:16 -0000 And a follow-up on the charter. I'm describing a couple of different takes on what the new charter could be. Comments and alternative proposals are welcome. This is what the current charter says about DMM:

  The working group will also work on operational considerations on
  setting up Mobile IPv6 networks so that traffic is distributed
  in an optimal way, for instance by using existing protocol mechanisms
  to select the closest home agents for new clients.

  Oct 2011 - Submit I-D 'Operational considerations for distributed use of Mobile IPv6' for publication as Informational.

Which is admittedly a bit short, but is also very concrete and achievable, if we work on it. I got another proposal from Hui Deng that extended this a bit, including going beyond mere operational considerations.

In the past decade a fair number of mobility protocols have been standardized. Although the protocols differ in terms of functions and associated message format, we can identify a few key common features:
presence of a centralized mobility anchor providing global reachability and an always-on experience
extensions to optimize handover performance while users roam across wireless cells
extensions to enable the use of heterogeneous wireless interfaces for multi-mode terminals (e.g. cellular phones)
The presence of the centralized mobility anchor allows a mobile device to be reachable when it is not connected to its home domain. The anchor, among other tasks, ensures forwarding of packets destined to or sent from the mobile device. As such, most of the deployed architectures today have a small number of centralized anchors managing the traffic of millions of mobile subscribers.

To optimize handovers for mobile users, the base protocols have been extended to efficiently handle packet forwarding between the previous and new points of attachment. These extensions are necessary when applications impose stringent requirements in terms of delay. Notions of localization and distribution of local agents have been introduced to reduce signalling overhead. Unfortunately today we witness difficulties in getting such protocols deployed, often leading to sub-optimal choices. Moreover, all the availability of multi-mode devices and the possibility to use several network interfaces simultaneously have motivated the development of more new protocol extensions.

Mobile users are, more than ever, consuming Internet content, and impose new requirements on mobile core networks for data traffic delivery. When this traffic demand exceeds available capacity, service providers need to implement new strategies such as selective traffic offload (e.g. 3GPP work items LIPA/SIPTO) through alternative access networks (e.g. WLAN). Moreover, the localization of content providers closer to the Mobile/Fixed Internet Service Providers network requires taking into account local Content Delivery Networks (CDNs) while providing mobility services. 

As long as demand exceeds capacity, both offloading and CDN techniques could benefit from the development of more flat mobile architectures (i.e., fewer levels of routing hierarchy introduced into the data path by the mobility management system). This view is reinforced by the shift in users’ traffic behaviour, aimed at increasing direct communications among peers in the same geographical area. The development of truly flat mobile architectures would result in anchoring the traffic closer to point of attachment of the user and overcoming the suboptimal routing issues of a centralized mobility scheme.

While deploying today’s mobile networks, service providers face new challenges. More often than not, mobile devices remain attached to the same point of attachment, in which case specific IP mobility management support is not required for applications that launch and complete while connected to the same point of attachment. However, the mobility support has been designed to be always on and to maintain the context for each mobile subscriber as long as they are connected to the network. This can result in a waste of resources and ever-increasing costs for the service provider. Infrequent mobility and intelligence of many applications suggest that mobility can be provided dynamically, thus simplifying the context maintained in the different nodes of the mobile network.

The proposed charter will address two complementary aspects of mobility management procedures: the distribution of mobility anchors to achieve a more flat design and the dynamic activation/deactivation of mobility protocol support as an enabler to distributed mobility management. The former has the goal of positioning mobility anchors (HA, LMA) closer to the user; ideally, these mobility anchors could be collocated with the first hop router. The latter, facilitated by the distribution of mobility anchors, aims at identifying when mobility must be activated and identifying sessions that do not impose mobility management -- thus reducing the amount of state information to be maintained in the various mobility anchors of the mobile network. The key idea is that dynamic mobility management relaxes some constraints while also repositioning mobility anchors; it avoids the establishment of non optimal tunnels between two anchors topologically distant.

Considering the above, the working group will:

Define the problem statement and associated requirements for distributed mobility management. This work aims at defining the problem space and identifies the key functional requirements.

Produce a gap analysis mapping the above requirements against existing solutions.

Give best practices for the deployment of existing mobility protocols in a distributed mobility management and describe limitations of each such approach.

Describe extensions, if needed, to current mobility protocols for their application in distributed mobility architectures

Comments?

Jari

From sarikaya2012@gmail.com Fri Oct 28 09:08:51 2011 Return-Path: X-Original-To: mext@ietfa.amsl.com Delivered-To: mext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C8F5E21F8A95 for ; Fri, 28 Oct 2011 09:08:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.27 X-Spam-Level: X-Spam-Status: No, score=-3.27 tagged_above=-999 required=5 tests=[AWL=0.013, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, SARE_MILLIONSOF=0.315] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vhVIxzZyvS+H for ; Fri, 28 Oct 2011 09:08:50 -0700 (PDT) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id 6CFD221F8A6C for ; Fri, 28 Oct 2011 09:08:50 -0700 (PDT) Received: by gyh20 with SMTP id 20so4509870gyh.31 for ; Fri, 28 Oct 2011 09:08:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=UDDJpv9DaS2x8n8kVzQ0dTtdMRx6o1pf03KdvO+B3Rk=; b=r2jDOYJ0R5XDMjxqOSY/iKZIs6U3SH+a4FA49Nvp014v+aOhbCU7NYfFMBfHQDOtDm 3KBf/XvsO8eV3MBaL8SJiMTkBLLIw6gVH3wFIyDNvEZw+QEu7wSjNhmm2F/sIWQQTY+I oOdfVOHAYLrWQIMrd5P0/A4pxybtVg1lAEsOk= MIME-Version: 1.0 Received: by 10.236.73.228 with SMTP id v64mr4656938yhd.103.1319818129939; Fri, 28 Oct 2011 09:08:49 -0700 (PDT) Received: by 10.236.110.39 with HTTP; Fri, 28 Oct 2011 09:08:49 -0700 (PDT) In-Reply-To: <4EAA9E34.2080903@piuha.net> References: <4EAA9B4A.3020208@piuha.net> <4EAA9E34.2080903@piuha.net> Date: Fri, 28 Oct 2011 11:08:49 -0500 Message-ID: From: Behcet Sarikaya To: Jari Arkko Content-Type: multipart/alternative; boundary=20cf30051280cd9aef04b05e1a2e Cc: "mext@ietf.org" Subject: Re: [MEXT] the future of the MEXT working group X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: sarikaya@ieee.org List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Oct 2011 16:08:51 -0000 --20cf30051280cd9aef04b05e1a2e Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi Jari, My comments inline. Regards, Behcet On Fri, Oct 28, 2011 at 7:21 AM, Jari Arkko wrote: > And a follow-up on the charter. I'm describing a couple of different tak= es > on what the new charter could be. Comments and alternative proposals are > welcome. This is what the current charter says about DMM: > > The working group will also work on operational considerations on > setting up Mobile IPv6 networks so that traffic is distributed > in an optimal way, for instance by using existing protocol mechanisms > to select the closest home agents for new clients. > > Oct 2011 - Submit I-D 'Operational considerations for distributed use o= f > Mobile IPv6' for publication as Informational. > > > Which is admittedly a bit short, but is also very concrete and achievable= , > if we work on it. > Agreed. I may suggest adding a requirements draft charter item in order to scope the work better. > I got another proposal from Hui Deng that extended this a bit, including > going beyond mere operational considerations. > > In the past decade a fair number of mobility protocols have been > standardized. Although the protocols differ in terms of functions and > associated message format, we can identify a few key common features: > presence of a centralized mobility anchor providing global reachability a= nd > an always-on experience > extensions to optimize handover performance while users roam across > wireless cells > extensions to enable the use of heterogeneous wireless interfaces for > multi-mode terminals (e.g. cellular phones) > The presence of the centralized mobility anchor allows a mobile device to > be reachable when it is not connected to its home domain. The anchor, amo= ng > other tasks, ensures forwarding of packets destined to or sent from the > mobile device. As such, most of the deployed architectures today have a > small number of centralized anchors managing the traffic of millions of > mobile subscribers. > > To optimize handovers for mobile users, the base protocols have been > extended to efficiently handle packet forwarding between the previous and > new points of attachment. These extensions are necessary when application= s > impose stringent requirements in terms of delay. Notions of localization = and > distribution of local agents have been introduced to reduce signalling > overhead. Unfortunately today we witness difficulties in getting such > protocols deployed, often leading to sub-optimal choices. Moreover, all t= he > availability of multi-mode devices and the possibility to use several > network interfaces simultaneously have motivated the development of more = new > protocol extensions. > > Mobile users are, more than ever, consuming Internet content, and impose > new requirements on mobile core networks for data traffic delivery. When > this traffic demand exceeds available capacity, service providers need to > implement new strategies such as selective traffic offload (e.g. 3GPP wor= k > items LIPA/SIPTO) through alternative access networks (e.g. WLAN). Moreov= er, > the localization of content providers closer to the Mobile/Fixed Internet > Service Providers network requires taking into account local Content > Delivery Networks (CDNs) while providing mobility services. > > As long as demand exceeds capacity, both offloading and CDN techniques > could benefit from the development of more flat mobile architectures (i.e= ., > fewer levels of routing hierarchy introduced into the data path by the > mobility management system). This view is reinforced by the shift in user= s=92 > traffic behaviour, aimed at increasing direct communications among peers = in > the same geographical area. The development of truly flat mobile > architectures would result in anchoring the traffic closer to point of > attachment of the user and overcoming the suboptimal routing issues of a > centralized mobility scheme. > > While deploying today=92s mobile networks, service providers face new > challenges. More often than not, mobile devices remain attached to the sa= me > point of attachment, in which case specific IP mobility management suppor= t > is not required for applications that launch and complete while connected= to > the same point of attachment. However, the mobility support has been > designed to be always on and to maintain the context for each mobile > subscriber as long as they are connected to the network. This can result = in > a waste of resources and ever-increasing costs for the service provider. > Infrequent mobility and intelligence of many applications suggest that > mobility can be provided dynamically, thus simplifying the context > maintained in the different nodes of the mobile network. > > The proposed charter will address two complementary aspects of mobility > management procedures: the distribution of mobility anchors to achieve a > more flat design and the dynamic activation/deactivation of mobility > protocol support as an enabler to distributed mobility management. The > former has the goal of positioning mobility anchors (HA, LMA) closer to t= he > user; ideally, these mobility anchors could be collocated with the first = hop > router. The latter, facilitated by the distribution of mobility anchors, > aims at identifying when mobility must be activated and identifying sessi= ons > that do not impose mobility management -- thus reducing the amount of sta= te > information to be maintained in the various mobility anchors of the mobil= e > network. The key idea is that dynamic mobility management relaxes some > constraints while also repositioning mobility anchors; it avoids the > establishment of non optimal tunnels between two anchors topologically > distant. > > Considering the above, the working group will: > > Define the problem statement and associated requirements for distributed > mobility management. This work aims at defining the problem space and > identifies the key functional requirements. > > Produce a gap analysis mapping the above requirements against existing > solutions. > > Give best practices for the deployment of existing mobility protocols in = a > distributed mobility management and describe limitations of each such > approach. > > Describe extensions, if needed, to current mobility protocols for their > application in distributed mobility architectures > > > This proposal has some nice features like PS and requirements. I believe gap analysis is more like an SDO work and not done much in IETF. Also my main concern is the existing mobility protocols. Since there are many of these protocols, I believe such a scope is too wide for esp. a new WG. --20cf30051280cd9aef04b05e1a2e Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi Jari,
=A0 My comments inline.

Regards,

Behcet
On Fri, Oct 28, 2011 at 7:21 AM, Jari Arkko <jari.arkko@piuha.net> wrote:
=20 =20 =20
And a follow-up on the charter. I'm describing a couple of differen= t takes on what the new charter could be. Comments and alternative proposals are welcome. This is what the current charter says about DMM:

=A0 The working group will also work on operational considerations on
=A0 setting up Mobile IPv6 networks so that traffic is distributed =A0 in an optimal way, for instance by using existing protocol mechanisms
=A0 to select the closest home agents for new clients.

=A0 Oct 2011 - Submit I-D 'Operational considerations for distributed use of Mobile IPv6' for publication as Informational.=

Which is admittedly a bit short, but is also very concrete and achievable, if we work on it.

Agreed. I may = suggest adding a requirements draft charter item in order to scope the work= better.
=A0
I got another proposal from Hui = Deng that extended this a bit, including going beyond mere operational considerations.

In the past decade a fair number of mobility protocols have been standardized. Although the protocols differ in terms of functions and associated message format, we can identify a few key common features:
presence of a centralized mobility anchor providing global reachability and an always-on experience
extensions to optimize handover performance while users roam across wireless cells
extensions to enable the use of heterogeneous wireless interfaces for multi-mode terminals (e.g. cellular phones)
The presence of the centralized mobility anchor allows a mobile device to be reachable when it is not connected to its home domain. The anchor, among other tasks, ensures forwarding of packets destined to or sent from the mobile device. As such, most of the deployed architectures today have a small number of centralized anchors managing the traffic of millions of mobile subscribers.

To optimize handovers for mobile users, the base protocols have been extended to efficiently handle packet forwarding between the previous and new points of attachment. These extensions are necessary when applications impose stringent requirements in terms of delay. Notions of localization and distribution of local agents have been introduced to reduce signalling overhead. Unfortunately today we witness difficulties in getting such protocols deployed, often leading to sub-optimal choices. Moreover, all the availability of multi-mode devices and the possibility to use several network interfaces simultaneously have motivated the development of more new protocol extensions.

Mobile users are, more than ever, consuming Internet content, and impose new requirements on mobile core networks for data traffic delivery. When this traffic demand exceeds available capacity, service providers need to implement new strategies such as selective traffic offload (e.g. 3GPP work items LIPA/SIPTO) through alternative access networks (e.g. WLAN). Moreover, the localization of content providers closer to the Mobile/Fixed Internet Service Providers network requires taking into account local Content Delivery Networks (CDNs) while providing mobility services.=A0

As long as demand exceeds capacity, both offloading and CDN techniques could benefit from the development of more flat mobile architectures (i.e., fewer levels of routing hierarchy introduced into the data path by the mobility management system). This view is reinforced by the shift in users=92 traffic behaviour, aimed at increasing direct communications among peers in the same geographical area. The development of truly flat mobile architectures would result in anchoring the traffic closer to point of attachment of the user and overcoming the suboptimal routing issues of a centralized mobility scheme.

While deploying today=92s mobile networks, service providers face new challenges. More often than not, mobile devices remain attached to the same point of attachment, in which case specific IP mobility management support is not required for applications that launch and complete while connected to the same point of attachment. However, the mobility support has been designed to be always on and to maintain the context for each mobile subscriber as long as they are connected to the network. This can result in a waste of resources and ever-increasing costs for the service provider. Infrequent mobility and intelligence of many applications suggest that mobility can be provided dynamically, thus simplifying the context maintained in the different nodes of the mobile network.

The proposed charter will address two complementary aspects of mobility management procedures: the distribution of mobility anchors to achieve a more flat design and the dynamic activation/deactivation of mobility protocol support as an enabler to distributed mobility management. The former has the goal of positioning mobility anchors (HA, LMA) closer to the user; ideally, these mobility anchors could be collocated with the first hop router. The latter, facilitated by the distribution of mobility anchors, aims at identifying when mobility must be activated and identifying sessions that do not impose mobility management -- thus reducing the amount of state information to be maintained in the various mobility anchors of the mobile network. The key idea is that dynamic mobility management relaxes some constraints while also repositioning mobility anchors; it avoids the establishment of non optimal tunnels between two anchors topologically distant.

Considering the above, the working group will:

Define the problem statement and associated requirements for distributed mobility management. This work aims at defining the problem space and identifies the key functional requirements.

Produce a gap analysis mapping the above requirements against existing solutions.

Give best practices for the deployment of existing mobility protocols in a distributed mobility management and describe limitations of each such approach.

Describe extensions, if needed, to current mobility protocols for their application in distributed mobility architectures

This proposal has some nice features like P= S and requirements. I believe gap analysis is more like an SDO work and not= done much in IETF. Also my main concern is the existing mobility protocols= . Since there are many of these protocols, I believe such a scope is too wi= de for esp. a new WG.


--20cf30051280cd9aef04b05e1a2e-- From denghui02@gmail.com Fri Oct 28 10:51:41 2011 Return-Path: X-Original-To: mext@ietfa.amsl.com Delivered-To: mext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C210C11E808B for ; Fri, 28 Oct 2011 10:51:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.441 X-Spam-Level: X-Spam-Status: No, score=-103.441 tagged_above=-999 required=5 tests=[AWL=-0.157, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, SARE_MILLIONSOF=0.315, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cy9NET1OXC6T for ; Fri, 28 Oct 2011 10:51:40 -0700 (PDT) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id 3C12411E8089 for ; Fri, 28 Oct 2011 10:51:40 -0700 (PDT) Received: by wyh22 with SMTP id 22so4919469wyh.31 for ; Fri, 28 Oct 2011 10:51:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Tuw/qgSsqH+GF2pFSbZrIBhmKNKwtUo7Sxzt0KE52i8=; b=SoaWZTh25dxTsJPE9iYQ7aqn2hPIisfxEqu93qJnh3TeYQXykTm4x3Zsee+Pa0j0cW +v9cH3xtfteqvscG3OqPjMy7zzEgSt8OQMJGW4Aa92znYsi9n8sHDcroa19dci44odyd NZeDgbhmdr38UYXP4JyK1UVJTUKH4HcY9vAn8= MIME-Version: 1.0 Received: by 10.216.205.159 with SMTP id j31mr1223588weo.80.1319824298790; Fri, 28 Oct 2011 10:51:38 -0700 (PDT) Received: by 10.216.82.199 with HTTP; Fri, 28 Oct 2011 10:51:38 -0700 (PDT) In-Reply-To: <4EAA9E34.2080903@piuha.net> References: <4EAA9B4A.3020208@piuha.net> <4EAA9E34.2080903@piuha.net> Date: Sat, 29 Oct 2011 01:51:38 +0800 Message-ID: From: Hui Deng To: Jari Arkko Content-Type: multipart/alternative; boundary=0016e6dd8a2e7ed28204b05f8a63 Cc: "mext@ietf.org" Subject: Re: [MEXT] the future of the MEXT working group X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Oct 2011 17:51:41 -0000 --0016e6dd8a2e7ed28204b05f8a63 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable I just want to mention that the proposal coming from DMM Interesting group which is orginally organized by Dapeng Liu and other contributors all together. -Hui 2011/10/28 Jari Arkko > And a follow-up on the charter. I'm describing a couple of different take= s > on what the new charter could be. Comments and alternative proposals are > welcome. This is what the current charter says about DMM: > > The working group will also work on operational considerations on > setting up Mobile IPv6 networks so that traffic is distributed > in an optimal way, for instance by using existing protocol mechanisms > to select the closest home agents for new clients. > > Oct 2011 - Submit I-D 'Operational considerations for distributed use o= f > Mobile IPv6' for publication as Informational. > > > Which is admittedly a bit short, but is also very concrete and achievable= , > if we work on it. I got another proposal from Hui Deng that extended this= a > bit, including going beyond mere operational considerations. > > In the past decade a fair number of mobility protocols have been > standardized. Although the protocols differ in terms of functions and > associated message format, we can identify a few key common features: > presence of a centralized mobility anchor providing global reachability a= nd > an always-on experience > extensions to optimize handover performance while users roam across > wireless cells > extensions to enable the use of heterogeneous wireless interfaces for > multi-mode terminals (e.g. cellular phones) > The presence of the centralized mobility anchor allows a mobile device to > be reachable when it is not connected to its home domain. The anchor, amo= ng > other tasks, ensures forwarding of packets destined to or sent from the > mobile device. As such, most of the deployed architectures today have a > small number of centralized anchors managing the traffic of millions of > mobile subscribers. > > To optimize handovers for mobile users, the base protocols have been > extended to efficiently handle packet forwarding between the previous and > new points of attachment. These extensions are necessary when application= s > impose stringent requirements in terms of delay. Notions of localization = and > distribution of local agents have been introduced to reduce signalling > overhead. Unfortunately today we witness difficulties in getting such > protocols deployed, often leading to sub-optimal choices. Moreover, all t= he > availability of multi-mode devices and the possibility to use several > network interfaces simultaneously have motivated the development of more = new > protocol extensions. > > Mobile users are, more than ever, consuming Internet content, and impose > new requirements on mobile core networks for data traffic delivery. When > this traffic demand exceeds available capacity, service providers need to > implement new strategies such as selective traffic offload (e.g. 3GPP wor= k > items LIPA/SIPTO) through alternative access networks (e.g. WLAN). Moreov= er, > the localization of content providers closer to the Mobile/Fixed Internet > Service Providers network requires taking into account local Content > Delivery Networks (CDNs) while providing mobility services. > > As long as demand exceeds capacity, both offloading and CDN techniques > could benefit from the development of more flat mobile architectures (i.e= ., > fewer levels of routing hierarchy introduced into the data path by the > mobility management system). This view is reinforced by the shift in user= s=92 > traffic behaviour, aimed at increasing direct communications among peers = in > the same geographical area. The development of truly flat mobile > architectures would result in anchoring the traffic closer to point of > attachment of the user and overcoming the suboptimal routing issues of a > centralized mobility scheme. > > While deploying today=92s mobile networks, service providers face new > challenges. More often than not, mobile devices remain attached to the sa= me > point of attachment, in which case specific IP mobility management suppor= t > is not required for applications that launch and complete while connected= to > the same point of attachment. However, the mobility support has been > designed to be always on and to maintain the context for each mobile > subscriber as long as they are connected to the network. This can result = in > a waste of resources and ever-increasing costs for the service provider. > Infrequent mobility and intelligence of many applications suggest that > mobility can be provided dynamically, thus simplifying the context > maintained in the different nodes of the mobile network. > > The proposed charter will address two complementary aspects of mobility > management procedures: the distribution of mobility anchors to achieve a > more flat design and the dynamic activation/deactivation of mobility > protocol support as an enabler to distributed mobility management. The > former has the goal of positioning mobility anchors (HA, LMA) closer to t= he > user; ideally, these mobility anchors could be collocated with the first = hop > router. The latter, facilitated by the distribution of mobility anchors, > aims at identifying when mobility must be activated and identifying sessi= ons > that do not impose mobility management -- thus reducing the amount of sta= te > information to be maintained in the various mobility anchors of the mobil= e > network. The key idea is that dynamic mobility management relaxes some > constraints while also repositioning mobility anchors; it avoids the > establishment of non optimal tunnels between two anchors topologically > distant. > > Considering the above, the working group will: > > Define the problem statement and associated requirements for distributed > mobility management. This work aims at defining the problem space and > identifies the key functional requirements. > > Produce a gap analysis mapping the above requirements against existing > solutions. > > Give best practices for the deployment of existing mobility protocols in = a > distributed mobility management and describe limitations of each such > approach. > > Describe extensions, if needed, to current mobility protocols for their > application in distributed mobility architectures > > > Comments? > > Jari > > > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext > > --0016e6dd8a2e7ed28204b05f8a63 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
I just want to mention that the proposal coming from DMM Interesting g= roup which is orginally organized by Dapeng Liu and other contributors all = together.
=A0
-Hui
=A0

=A0
2011/10/28 Jari Arkko <jari.arkko@piuha.net>
And a follow-up on the charter. I= 'm describing a couple of different takes on what the new charter could= be. Comments and alternative proposals are welcome. This is what the curre= nt charter says about DMM:

=A0 The working group will also work on operation= al considerations on
=A0 setting up Mobile IPv6 networks so that traffic= is distributed
=A0 in an optimal way, for instance by using existing pr= otocol mechanisms
=A0 to select the closest home agents for new clients.

=A0 Oct 2011 = - Submit I-D 'Operational considerations for distributed use of Mobile = IPv6' for publication as Informational.

Which is ad= mittedly a bit short, but is also very concrete and achievable, if we work = on it. I got another proposal from Hui Deng that extended this a bit, inclu= ding going beyond mere operational considerations.

In the past decade a fair number of mobility prot= ocols have been standardized. Although the protocols differ in terms of fun= ctions and associated message format, we can identify a few key common feat= ures:
presence of a centralized mobility anchor providing global reachability and= an always-on experience
extensions to optimize handover performance whi= le users roam across wireless cells
extensions to enable the use of hete= rogeneous wireless interfaces for multi-mode terminals (e.g. cellular phone= s)
The presence of the centralized mobility anchor allows a mobile device to b= e reachable when it is not connected to its home domain. The anchor, among = other tasks, ensures forwarding of packets destined to or sent from the mob= ile device. As such, most of the deployed architectures today have a small = number of centralized anchors managing the traffic of millions of mobile su= bscribers.

To optimize handovers for mobile users, the base protocols have been ex= tended to efficiently handle packet forwarding between the previous and new= points of attachment. These extensions are necessary when applications imp= ose stringent requirements in terms of delay. Notions of localization and d= istribution of local agents have been introduced to reduce signalling overh= ead. Unfortunately today we witness difficulties in getting such protocols = deployed, often leading to sub-optimal choices. Moreover, all the availabil= ity of multi-mode devices and the possibility to use several network interf= aces simultaneously have motivated the development of more new protocol ext= ensions.

Mobile users are, more than ever, consuming Internet content, and impos= e new requirements on mobile core networks for data traffic delivery. When = this traffic demand exceeds available capacity, service providers need to i= mplement new strategies such as selective traffic offload (e.g. 3GPP work i= tems LIPA/SIPTO) through alternative access networks (e.g. WLAN). Moreover,= the localization of content providers closer to the Mobile/Fixed Internet = Service Providers network requires taking into account local Content Delive= ry Networks (CDNs) while providing mobility services.=A0

As long as demand exceeds capacity, both offloading and CDN techniques = could benefit from the development of more flat mobile architectures (i.e.,= fewer levels of routing hierarchy introduced into the data path by the mob= ility management system). This view is reinforced by the shift in users=92 = traffic behaviour, aimed at increasing direct communications among peers in= the same geographical area. The development of truly flat mobile architect= ures would result in anchoring the traffic closer to point of attachment of= the user and overcoming the suboptimal routing issues of a centralized mob= ility scheme.

While deploying today=92s mobile networks, service providers face new c= hallenges. More often than not, mobile devices remain attached to the same = point of attachment, in which case specific IP mobility management support = is not required for applications that launch and complete while connected t= o the same point of attachment. However, the mobility support has been desi= gned to be always on and to maintain the context for each mobile subscriber= as long as they are connected to the network. This can result in a waste o= f resources and ever-increasing costs for the service provider. Infrequent = mobility and intelligence of many applications suggest that mobility can be= provided dynamically, thus simplifying the context maintained in the diffe= rent nodes of the mobile network.

The proposed charter will address two complementary aspects of mobility= management procedures: the distribution of mobility anchors to achieve a m= ore flat design and the dynamic activation/deactivation of mobility protoco= l support as an enabler to distributed mobility management. The former has = the goal of positioning mobility anchors (HA, LMA) closer to the user; idea= lly, these mobility anchors could be collocated with the first hop router. = The latter, facilitated by the distribution of mobility anchors, aims at id= entifying when mobility must be activated and identifying sessions that do = not impose mobility management -- thus reducing the amount of state informa= tion to be maintained in the various mobility anchors of the mobile network= . The key idea is that dynamic mobility management relaxes some constraints= while also repositioning mobility anchors; it avoids the establishment of = non optimal tunnels between two anchors topologically distant.

Considering the above, the working group will:

Define the proble= m statement and associated requirements for distributed mobility management= . This work aims at defining the problem space and identifies the key funct= ional requirements.

Produce a gap analysis mapping the above requirements against existing = solutions.

Give best practices for the deployment of existing mobili= ty protocols in a distributed mobility management and describe limitations = of each such approach.

Describe extensions, if needed, to current mobility protocols for their= application in distributed mobility architectures

Comment= s?

Jari


____________= ___________________________________
MEXT mailing list
MEXT@ietf.org
= ht= tps://www.ietf.org/mailman/listinfo/mext


--0016e6dd8a2e7ed28204b05f8a63-- From charliep@computer.org Fri Oct 28 14:11:56 2011 Return-Path: X-Original-To: mext@ietfa.amsl.com Delivered-To: mext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C62021F84AD for ; Fri, 28 Oct 2011 14:11:56 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id azzb0ww5G6pm for ; Fri, 28 Oct 2011 14:11:55 -0700 (PDT) Received: from elasmtp-mealy.atl.sa.earthlink.net (elasmtp-mealy.atl.sa.earthlink.net [209.86.89.69]) by ietfa.amsl.com (Postfix) with ESMTP id 98A6821F8496 for ; Fri, 28 Oct 2011 14:11:55 -0700 (PDT) Received: from [138.111.58.2] (helo=[172.17.96.136]) by elasmtp-mealy.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1RJtiS-0001Ep-2C; Fri, 28 Oct 2011 17:11:52 -0400 Message-ID: <4EAB1A93.8050605@computer.org> Date: Fri, 28 Oct 2011 14:11:47 -0700 From: "Charles E. Perkins" Organization: Wichorus Inc. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: Romain KUNTZ References: <20110803185832.21283.61262.idtracker@ietfa.amsl.com> <4E399F6E.8090508@computer.org> <75B8624B-6C94-4B7F-9487-DCF0E06B5256@us.toyota-itc.com> In-Reply-To: <75B8624B-6C94-4B7F-9487-DCF0E06B5256@us.toyota-itc.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956d5d4673fe7faad86a8d414519df2b1aa4aff1bbf7757ba0f350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 138.111.58.2 Cc: mext Subject: Re: [MEXT] New Version Notification for draft-perkins-mext-hatunaddr-01.txt X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: charliep@computer.org List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Oct 2011 21:11:56 -0000 Hello Romain, Thank you for reminding me about this point. It had been raised previously during some related discussions for DMM late last year, and I plainly forgot to fill in any details about the problem. After looking over RFC 3957, I think the most efficient way towards solution will be to define a new extension similar to the Generalized MN-HA Key Generation Nonce Request and Generalized MN-HA Key Generation Nonce Reply extensions. It's not a perfect fit, but it's pretty close. If there is any interest for an IPv4-based solution, I could easily write up a new subtype for the RFC 3957 (IPv4) extensions. The formula for calculating the key in Section 5 needs to be updated, perhaps to the following: key = HMAC-SHA1 (HA-key, {Key Generation Nonce || mobile node identifier || HA-D IPv6_address}) A similar formula would apply for any specification in which the key nonce was generated by AAA instead of the [control-plane] Home Agent [HA-C]. The manner in which the HA-D get the corresponding configuration information doesn't have to be specified in the ...mext-hatunaddr... draft. I'll try to get an updated draft out before the draft deadline on Monday. Thanks for your comment. While mostly straightforward, the update will take a pretty good bit of carefully written text. Regards, Charlie P. On 8/4/2011 11:39 AM, Romain KUNTZ wrote: > Hello Charlie, > > If the MN has to tunnel data to a different HA than the one to which it sends the BU, then it also needs an IPsec SA with that HA. How would the MN create such SA as it does not know in advance what HA it may use for tunneling? My guess is that the MN is supposed to trust the address received in the option and create the SA upon reception of the option. Similarly, all of the HA tunneling box would also need to be configured with the corresponding SA. Some considerations about that may be needed in the draft. > > Regards, > romain > > > On Aug 3, 2011, at 12:20, Charles E. Perkins wrote: > >> >> Hello folks, >> >> My draft has now made it through the submission process. >> Please excuse the repeat notification... >> >> Comments will be appreciated. >> >> Regards, >> Charlie P. >> >> >> -------- Original Message -------- >> Subject: New Version Notification for draft-perkins-mext-hatunaddr-01.txt >> Date: Wed, 03 Aug 2011 11:58:32 -0700 >> From: >> To: >> CC: >> >> A new version of I-D, draft-perkins-mext-hatunaddr-01.txt has been successfully submitted by Charles Perkins and posted to the IETF repository. >> >> Filename: draft-perkins-mext-hatunaddr >> Revision: 01 >> Title: Alternate Tunnel Source Address for Home Agent >> Creation date: 2011-08-03 >> WG ID: Individual Submission >> Number of pages: 10 >> >> Abstract: >> Widely deployed mobility management systems for wireless >> communications have isolated the path for forwarding data from the >> control plane signaling for mobility management. To realize this >> requirement with Mobile IP requires that the control functions of the >> home agent be addressable at a different IP address than the source >> IP address of the tunnel between the home agent and mobile node. >> Similar considerations hold for mobility anchors implementing >> Hierarchical Mobile IP or PMIP. >> >> >> >> >> The IETF Secretariat >> >> _______________________________________________ >> MEXT mailing list >> MEXT@ietf.org >> https://www.ietf.org/mailman/listinfo/mext > > From hesham@elevatemobile.com Sat Oct 29 19:23:51 2011 Return-Path: X-Original-To: mext@ietfa.amsl.com Delivered-To: mext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F8FF1F0C34 for ; Sat, 29 Oct 2011 19:23:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.284 X-Spam-Level: X-Spam-Status: No, score=-2.284 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, SARE_MILLIONSOF=0.315] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q5+niIriirt7 for ; Sat, 29 Oct 2011 19:23:50 -0700 (PDT) Received: from smtp-1.servers.netregistry.net (smtp.netregistry.net [202.124.241.204]) by ietfa.amsl.com (Postfix) with ESMTP id 402B421F84B2 for ; Sat, 29 Oct 2011 19:23:49 -0700 (PDT) Received: from [60.242.128.199] (helo=[192.168.0.2]) by smtp-1.servers.netregistry.net protocol: esmtpa (Exim 4.69 #1 (Debian)) id 1RKL3R-0002Yk-5R; Sun, 30 Oct 2011 13:23:22 +1100 User-Agent: Microsoft-MacOutlook/14.13.0.110805 Date: Sun, 30 Oct 2011 13:23:10 +1100 From: Hesham Soliman To: Jari Arkko , "mext@ietf.org" Message-ID: Thread-Topic: [MEXT] the future of the MEXT working group In-Reply-To: <4EAA9E34.2080903@piuha.net> Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable X-Authenticated-User: hesham@elevatemobile.com Subject: Re: [MEXT] the future of the MEXT working group X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 Oct 2011 02:23:51 -0000 Hi Jari, All, Some comments inline. > And a follow-up on the charter. I'm describing a couple of different > takes on what the new charter could be. Comments and alternative > proposals are welcome. This is what the current charter says about > DMM: > =20 > =20 > The working group will also work on > operational considerations on > setting up Mobile IPv6 networks so that traffic is distributed > in an optimal way, for instance by using existing protocol > mechanisms > to select the closest home agents for new clients. > =20 > Oct 2011 - Submit I-D 'Operational considerations for > distributed use of Mobile IPv6' for publication as Informational. > =20 > > =20 > Which is admittedly a bit short, but is also very concrete and > achievable, if we work on it. I got another proposal from Hui Deng > that extended this a bit, including going beyond mere operational > considerations. =3D> I think that's clear, with the exception of some possible aesthetic improvements. > =20 > =20 >In the past decade a fair number of mobility > protocols have been standardized. Although the protocols differ in > terms of functions and associated message format, we can identify > a few key common features: > presence of a centralized mobility anchor providing global > reachability and an always-on experience > extensions to optimize handover performance while users roam > across wireless cells > extensions to enable the use of heterogeneous wireless interfaces > for multi-mode terminals (e.g. cellular phones) > The presence of the centralized mobility anchor allows a mobile > device to be reachable when it is not connected to its home > domain. The anchor, among other tasks, ensures forwarding of > packets destined to or sent from the mobile device. As such, most > of the deployed architectures today have a small number of > centralized anchors managing the traffic of millions of mobile > subscribers. =3D> This really sounds like a lot of ambiguity, can't we just say that [flow mobility], [HMIPv6] and [FMIPv6] were introduced to optimise mobility? This paragraph can be written in two sentences. > =20 > To optimize handovers for mobile users, the base protocols have > been extended to efficiently handle packet forwarding between the > previous and new points of attachment. These extensions are > necessary when applications impose stringent requirements in terms > of delay.=20 =3D> I don't think this style is needed for a charter. The last sentence is incorrect anyway. TCP suffers from mobility disruptions. >Notions of localization and distribution of local agents > have been introduced to reduce signalling overhead. Unfortunately > today we witness difficulties in getting such protocols deployed, > often leading to sub-optimal choices. =3D> What is the point of this part? Seems like it has no effect on the work unless we have a consensus on why it is difficult to introduce those protocols. Bear in mind that IPv6 is still not widely used and MIPv4 was hardly used outside one mobile network in the US. Isn't the real reason for not deploying IP mobility that the 3G networks were designed to not need IP mobility? If so, then one can't come to a conclusion that those protocols like FMIP, HMIP, flow mobility..etc are too difficult to deploy because they were not seriously tried and that's because they were not seriously needed. I.e. in the 3G architecture, nothing is "broken" without them.=20 >Moreover, all the > availability of multi-mode devices and the possibility to use > several network interfaces simultaneously have motivated the > development of more new protocol extensions. > =20 > Mobile users are, more than ever, consuming Internet content, and > impose new requirements on mobile core networks for data traffic > delivery. When this traffic demand exceeds available capacity, > service providers need to implement new strategies such as > selective traffic offload (e.g. 3GPP work items LIPA/SIPTO) > through alternative access networks (e.g. WLAN). Moreover, the > localization of content providers closer to the Mobile/Fixed > Internet Service Providers network requires taking into account > local Content Delivery Networks (CDNs) while providing mobility > services. =20 > =20 > As long as demand exceeds capacity, both offloading and CDN > techniques could benefit from the development of more flat mobile > architectures (i.e., fewer levels of routing hierarchy introduced > into the data path by the mobility management system). This view > is reinforced by the shift in users=B9 traffic behaviour, aimed at > increasing direct communications among peers in the same > geographical area. The development of truly flat mobile > architectures would result in anchoring the traffic closer to > point of attachment of the user and overcoming the suboptimal > routing issues of a centralized mobility scheme. > =20 > While deploying today=B9s mobile networks, service providers face > new challenges. More often than not, mobile devices remain > attached to the same point of attachment, in which case specific > IP mobility management support is not required for applications > that launch and complete while connected to the same point of > attachment. However, the mobility support has been designed to be > always on and to maintain the context for each mobile subscriber > as long as they are connected to the network. This can result in a > waste of resources and ever-increasing costs for the service > provider. Infrequent mobility and intelligence of many > applications suggest that mobility can be provided dynamically, > thus simplifying the context maintained in the different nodes of > the mobile network. =3D> So reading this last paragraph tells me that Mobile IPv6 is actually not needed (regardless of whether one agrees with that or not). So why would any work item take place in MEXT? The overheads described are not quantified or proven to be substantial for an operator. What are the overheads? Storing a binding? If the mobile node doesn't move, there is no signalling so what's the cost? =20 > =20 > The proposed charter will address two complementary aspects of > mobility management procedures: the distribution of mobility > anchors to achieve a more flat design and the dynamic > activation/deactivation of mobility protocol support as an enabler > to distributed mobility management. =3D> But this sounds like introducing more complexity while maintaining the same overheads? MEaning, if you're still keeping anchors, then you still have the overheads you complain about, but then you add complexity by trying to over-optimise the turning on and off of mobility management. Sounds like extra work for no benefit. >The former has the goal of > positioning mobility anchors (HA, LMA) closer to the user; =3D> Yes but that was only one of the complaints about the current mobility management. The other was overheads of anchors. So having the anchor closer doesn't solve that problem. > ideally, these mobility anchors could be collocated with the first > hop router. The latter, facilitated by the distribution of > mobility anchors, aims at identifying when mobility must be > activated and identifying sessions that do not impose mobility > management -- thus reducing the amount of state information to be > maintained in the various mobility anchors of the mobile network. > The key idea is that dynamic mobility management relaxes some > constraints while also repositioning mobility anchors; it avoids > the establishment of non optimal tunnels between two anchors > topologically distant. > =20 > Considering the above, the working group will: > =20 > Define the problem statement and associated requirements for > distributed mobility management. This work aims at defining the > problem space and identifies the key functional requirements. > =20 > Produce a gap analysis mapping the above requirements against > existing solutions. > =20 > Give best practices for the deployment of existing mobility > protocols in a distributed mobility management and describe > limitations of each such approach. > =20 > Describe extensions, if needed, to current mobility protocols for > their application in distributed mobility architectures >=20 > > =20 > Comments? =3D> Yes a few comments: - As a stylistic matter, the text should just say what it needs done quickly and concisely. - Substantively, the text lists two key problems: 1) being able to allocate anchors close to the MN so that content caches can be allocated based on the MN's location and 2) Anchors introduce overheads. Seems to me that 2) makes 1) irrelevant because if you remove the anchors then you no longer need to worry about efficient allocation. 1) is something that someone who read the protocol and is a good systems engineer can fix by making sure that the anchors are allocated and advertised correctly to the MN (using HMIP as an example here). I can see that people might want to have different mechanisms for allocating anchors but then just say that clearly and describe why. I think if the work item is: - Develop best practices and mechanisms to efficiently allocate mobility anchors to mobile nodes in a manner that is optimised for the mobile node's geo-location. Then that's clear and fine as an item, but I think the long version above goes around in circles and I don't see a clear consequential problem to be solved other than the bullet above. Hesham > =20 > Jari > =20 > =20 > >_______________________________________________ >MEXT mailing list >MEXT@ietf.org >https://www.ietf.org/mailman/listinfo/mext From Basavaraj.Patil@nokia.com Mon Oct 31 07:47:16 2011 Return-Path: X-Original-To: mext@ietfa.amsl.com Delivered-To: mext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8648121F8CCC for ; Mon, 31 Oct 2011 07:47:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.541 X-Spam-Level: X-Spam-Status: No, score=-102.541 tagged_above=-999 required=5 tests=[AWL=-0.258, BAYES_00=-2.599, HTML_MESSAGE=0.001, SARE_MILLIONSOF=0.315, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NVZ5VoWOxw39 for ; Mon, 31 Oct 2011 07:47:12 -0700 (PDT) Received: from mgw-sa01.nokia.com (smtp.nokia.com [147.243.1.47]) by ietfa.amsl.com (Postfix) with ESMTP id C5D7521F8CD6 for ; Mon, 31 Oct 2011 07:47:11 -0700 (PDT) Received: from vaebh102.NOE.Nokia.com (vaebh102.europe.nokia.com [10.160.244.23]) by mgw-sa01.nokia.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id p9VEl9Tg006790; Mon, 31 Oct 2011 16:47:10 +0200 Received: from smtp.mgd.nokia.com ([65.54.30.7]) by vaebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Mon, 31 Oct 2011 16:47:10 +0200 Received: from 008-AM1MMR1-007.mgdnok.nokia.com (65.54.30.23) by NOK-AM1MHUB-03.mgdnok.nokia.com (65.54.30.7) with Microsoft SMTP Server (TLS) id 8.2.255.0; Mon, 31 Oct 2011 15:47:03 +0100 Received: from 008-AM1MPN1-071.mgdnok.nokia.com ([169.254.1.235]) by 008-AM1MMR1-007.mgdnok.nokia.com ([65.54.30.23]) with mapi id 14.01.0339.002; Mon, 31 Oct 2011 15:47:02 +0100 From: To: , Thread-Topic: [MEXT] the future of the MEXT working group Thread-Index: AQHMlWpmfRWG/cEPIEyACm1+ri2dNZWRi8gAgADD+FA= Date: Mon, 31 Oct 2011 14:47:01 +0000 Message-ID: <21E7D9BD69CC7241AAE00F4EA183B719014CE67F@008-AM1MPN1-071.mgdnok.nokia.com> References: <4EAA9B4A.3020208@piuha.net> <4EAA9E34.2080903@piuha.net> In-Reply-To: <4EAA9E34.2080903@piuha.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-tituslabs-classifications-30: TLPropertyRoot=Nokia;Confidentiality=Company Confidential;Project=None; x-titus-version: 3.3.8.1 x-headerinfofordlp: None x-tituslabs-classificationhash-30: VgNFIFU9Hx+/nZJb9Kg7IjQCNpuwNus9ut70eVa/NdKHRZFgdySinxYJu3y3D1U4nE3lPYIuSMwHG9a/XFxQj98oVjMe94TVxZpWS6Yg5Nt4XE2p2VDl4Foyl8CnNlpH5rIyYlGUk6yJPPAfLkB+nQy0tFePtVqQYbiaxn4XdxRjwz2nGF3Qjl2wyWgXRafGjqYhboQAymYT1nge4M/qJnD6KTyE43W6LRP6nEpIDabn6FYOIO7rQAkk2l8z5m5g x-originating-ip: [172.19.59.25] Content-Type: multipart/alternative; boundary="_000_21E7D9BD69CC7241AAE00F4EA183B719014CE67F008AM1MPN1071mg_" MIME-Version: 1.0 X-OriginalArrivalTime: 31 Oct 2011 14:47:10.0166 (UTC) FILETIME=[F805BF60:01CC97DB] X-Nokia-AV: Clean Subject: Re: [MEXT] the future of the MEXT working group X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Oct 2011 14:47:16 -0000 --_000_21E7D9BD69CC7241AAE00F4EA183B719014CE67F008AM1MPN1071mg_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Jari, A couple of quick questions: 1. Is this a recharter of the MEXT WG or the formation of a new WG to= deal with DMM? If it is the latter I would be concerned that a WG is being= formed without going through the IETF BoF process. I realize that DMM was = in the scope of the MEXT WG. But proposed new charter pretty much throws ev= erything else w.r.t MIP6/DSMIP6 out of this new WG. 2. There needs to be a WG and home for continued work w.r.t improveme= nts to MIP6/DSMIP6 protocol in terms of extensions, deployability improveme= nts etc. The proposed charter does not consider this at all. -Basavaraj From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] On Behalf Of ext= Jari Arkko Sent: Friday, October 28, 2011 7:21 AM To: mext@ietf.org Subject: Re: [MEXT] the future of the MEXT working group And a follow-up on the charter. I'm describing a couple of different takes = on what the new charter could be. Comments and alternative proposals are we= lcome. This is what the current charter says about DMM: The working group will also work on operational considerations on setting up Mobile IPv6 networks so that traffic is distributed in an optimal way, for instance by using existing protocol mechanisms to select the closest home agents for new clients. Oct 2011 - Submit I-D 'Operational considerations for distributed use of = Mobile IPv6' for publication as Informational. Which is admittedly a bit short, but is also very concrete and achievable, = if we work on it. I got another proposal from Hui Deng that extended this a= bit, including going beyond mere operational considerations. In the past decade a fair number of mobility protocols have been standardiz= ed. Although the protocols differ in terms of functions and associated mess= age format, we can identify a few key common features: presence of a centralized mobility anchor providing global reachability and= an always-on experience extensions to optimize handover performance while users roam across wireles= s cells extensions to enable the use of heterogeneous wireless interfaces for multi= -mode terminals (e.g. cellular phones) The presence of the centralized mobility anchor allows a mobile device to b= e reachable when it is not connected to its home domain. The anchor, among = other tasks, ensures forwarding of packets destined to or sent from the mob= ile device. As such, most of the deployed architectures today have a small = number of centralized anchors managing the traffic of millions of mobile su= bscribers. To optimize handovers for mobile users, the base protocols have been extend= ed to efficiently handle packet forwarding between the previous and new poi= nts of attachment. These extensions are necessary when applications impose = stringent requirements in terms of delay. Notions of localization and distr= ibution of local agents have been introduced to reduce signalling overhead.= Unfortunately today we witness difficulties in getting such protocols depl= oyed, often leading to sub-optimal choices. Moreover, all the availability = of multi-mode devices and the possibility to use several network interfaces= simultaneously have motivated the development of more new protocol extensi= ons. Mobile users are, more than ever, consuming Internet content, and impose ne= w requirements on mobile core networks for data traffic delivery. When this= traffic demand exceeds available capacity, service providers need to imple= ment new strategies such as selective traffic offload (e.g. 3GPP work items= LIPA/SIPTO) through alternative access networks (e.g. WLAN). Moreover, the= localization of content providers closer to the Mobile/Fixed Internet Serv= ice Providers network requires taking into account local Content Delivery N= etworks (CDNs) while providing mobility services. As long as demand exceeds capacity, both offloading and CDN techniques coul= d benefit from the development of more flat mobile architectures (i.e., few= er levels of routing hierarchy introduced into the data path by the mobilit= y management system). This view is reinforced by the shift in users' traffi= c behaviour, aimed at increasing direct communications among peers in the s= ame geographical area. The development of truly flat mobile architectures w= ould result in anchoring the traffic closer to point of attachment of the u= ser and overcoming the suboptimal routing issues of a centralized mobility = scheme. While deploying today's mobile networks, service providers face new challen= ges. More often than not, mobile devices remain attached to the same point = of attachment, in which case specific IP mobility management support is not= required for applications that launch and complete while connected to the = same point of attachment. However, the mobility support has been designed t= o be always on and to maintain the context for each mobile subscriber as lo= ng as they are connected to the network. This can result in a waste of reso= urces and ever-increasing costs for the service provider. Infrequent mobili= ty and intelligence of many applications suggest that mobility can be provi= ded dynamically, thus simplifying the context maintained in the different n= odes of the mobile network. The proposed charter will address two complementary aspects of mobility man= agement procedures: the distribution of mobility anchors to achieve a more = flat design and the dynamic activation/deactivation of mobility protocol su= pport as an enabler to distributed mobility management. The former has the = goal of positioning mobility anchors (HA, LMA) closer to the user; ideally,= these mobility anchors could be collocated with the first hop router. The = latter, facilitated by the distribution of mobility anchors, aims at identi= fying when mobility must be activated and identifying sessions that do not = impose mobility management -- thus reducing the amount of state information= to be maintained in the various mobility anchors of the mobile network. Th= e key idea is that dynamic mobility management relaxes some constraints whi= le also repositioning mobility anchors; it avoids the establishment of non = optimal tunnels between two anchors topologically distant. Considering the above, the working group will: Define the problem statement and associated requirements for distributed mo= bility management. This work aims at defining the problem space and identif= ies the key functional requirements. Produce a gap analysis mapping the above requirements against existing solu= tions. Give best practices for the deployment of existing mobility protocols in a = distributed mobility management and describe limitations of each such appro= ach. Describe extensions, if needed, to current mobility protocols for their app= lication in distributed mobility architectures Comments? Jari --_000_21E7D9BD69CC7241AAE00F4EA183B719014CE67F008AM1MPN1071mg_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

 <= /p>

Hi Jari,

 <= /p>

A couple of quick questio= ns:

 <= /p>

1. = ;      Is this a rechart= er of the MEXT WG or the formation of a new WG to deal with DMM? If it is t= he latter I would be concerned that a WG is being formed without going through the IETF BoF process. I realize that DMM was in the = scope of the MEXT WG. But proposed new charter pretty much throws everythin= g else w.r.t MIP6/DSMIP6 out of this new WG.

2. = ;      There needs to be= a WG and home for continued work w.r.t improvements to MIP6/DSMIP6 protoco= l in terms of extensions, deployability improvements etc. The proposed charter does not consider this at all.

 <= /p>

-Basavaraj

 <= /p>

From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.o= rg] On Behalf Of ext Jari Arkko
Sent: Friday, October 28, 2011 7:21 AM
To: mext@ietf.org
Subject: Re: [MEXT] the future of the MEXT working group<= /span>

 

And a follow-up on the charter. I'm describing a cou= ple of different takes on what the new charter could be. Comments and alter= native proposals are welcome. This is what the current charter says about D= MM:


  The working group will also work on operation= al considerations on
  setting up Mobile IPv6 networks so that traffic is distributed
  in an optimal way, for instance by using existing protocol mechanism= s
  to select the closest home agents for new clients.

  Oct 2011 - Submit I-D 'Operational considerations for distributed us= e of Mobile IPv6' for publication as Informational.


Which is admittedly a bit short, but is also very concrete and achievable, = if we work on it. I got another proposal from Hui Deng that extended this a= bit, including going beyond mere operational considerations.


In the past decade a fair number of mobility protoco= ls have been standardized. Although the protocols differ in terms of functi= ons and associated message format, we can identify a few key common feature= s:
presence of a centralized mobility anchor providing global reachability and= an always-on experience
extensions to optimize handover performance while users roam across wireles= s cells
extensions to enable the use of heterogeneous wireless interfaces for multi= -mode terminals (e.g. cellular phones)
The presence of the centralized mobility anchor allows a mobile device to b= e reachable when it is not connected to its home domain. The anchor, among = other tasks, ensures forwarding of packets destined to or sent from the mob= ile device. As such, most of the deployed architectures today have a small number of centralized anchors ma= naging the traffic of millions of mobile subscribers.

To optimize handovers for mobile users, the base protocols have been extend= ed to efficiently handle packet forwarding between the previous and new poi= nts of attachment. These extensions are necessary when applications impose = stringent requirements in terms of delay. Notions of localization and distribution of local agents have be= en introduced to reduce signalling overhead. Unfortunately today we witness= difficulties in getting such protocols deployed, often leading to sub-opti= mal choices. Moreover, all the availability of multi-mode devices and the possibility to use several network interface= s simultaneously have motivated the development of more new protocol extens= ions.

Mobile users are, more than ever, consuming Internet content, and impose ne= w requirements on mobile core networks for data traffic delivery. When this= traffic demand exceeds available capacity, service providers need to imple= ment new strategies such as selective traffic offload (e.g. 3GPP work items LIPA/SIPTO) through alternative acce= ss networks (e.g. WLAN). Moreover, the localization of content providers cl= oser to the Mobile/Fixed Internet Service Providers network requires taking= into account local Content Delivery Networks (CDNs) while providing mobility services. 

As long as demand exceeds capacity, both offloading and CDN techniques coul= d benefit from the development of more flat mobile architectures (i.e., few= er levels of routing hierarchy introduced into the data path by the mobilit= y management system). This view is reinforced by the shift in users’ traffic behaviour, aimed at inc= reasing direct communications among peers in the same geographical area. Th= e development of truly flat mobile architectures would result in anchoring = the traffic closer to point of attachment of the user and overcoming the suboptimal routing issues of a centralized = mobility scheme.

While deploying today’s mobile networks, service providers face new c= hallenges. More often than not, mobile devices remain attached to the same = point of attachment, in which case specific IP mobility management support = is not required for applications that launch and complete while connected to the same point of attachment. Howev= er, the mobility support has been designed to be always on and to maintain = the context for each mobile subscriber as long as they are connected to the= network. This can result in a waste of resources and ever-increasing costs for the service provider. Infrequen= t mobility and intelligence of many applications suggest that mobility can = be provided dynamically, thus simplifying the context maintained in the dif= ferent nodes of the mobile network.

The proposed charter will address two complementary aspects of mobility man= agement procedures: the distribution of mobility anchors to achieve a more = flat design and the dynamic activation/deactivation of mobility protocol su= pport as an enabler to distributed mobility management. The former has the goal of positioning mobility ancho= rs (HA, LMA) closer to the user; ideally, these mobility anchors could be c= ollocated with the first hop router. The latter, facilitated by the distrib= ution of mobility anchors, aims at identifying when mobility must be activated and identifying sessions th= at do not impose mobility management -- thus reducing the amount of state i= nformation to be maintained in the various mobility anchors of the mobile n= etwork. The key idea is that dynamic mobility management relaxes some constraints while also repositioning mobi= lity anchors; it avoids the establishment of non optimal tunnels between tw= o anchors topologically distant.

Considering the above, the working group will:

Define the problem statement and associated requirements for distributed mo= bility management. This work aims at defining the problem space and identif= ies the key functional requirements.

Produce a gap analysis mapping the above requirements against existing solu= tions.

Give best practices for the deployment of existing mobility protocols in a = distributed mobility management and describe limitations of each such appro= ach.

Describe extensions, if needed, to current mobility protocols for their app= lication in distributed mobility architectures


Comments?

Jari

--_000_21E7D9BD69CC7241AAE00F4EA183B719014CE67F008AM1MPN1071mg_-- From denghui02@gmail.com Mon Oct 31 09:00:15 2011 Return-Path: X-Original-To: mext@ietfa.amsl.com Delivered-To: mext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 921FC1F0C6C for ; Mon, 31 Oct 2011 09:00:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.134 X-Spam-Level: X-Spam-Status: No, score=-103.134 tagged_above=-999 required=5 tests=[AWL=0.149, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, SARE_MILLIONSOF=0.315, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XypOMSKz1bGH for ; Mon, 31 Oct 2011 09:00:12 -0700 (PDT) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id CB7DD21F8E29 for ; Mon, 31 Oct 2011 09:00:09 -0700 (PDT) Received: by wyg30 with SMTP id 30so1432612wyg.31 for ; Mon, 31 Oct 2011 09:00:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=g3Ifh5akObtNMR8OEHFeX1Syh3vguJNBtwV7YlCydLw=; b=Ji84JshRLToYLEfq1Ga9xt7TeY2MCAYQGNLc284FkT9EQQTqr0T/qiSIcLC2fabOyi 7Zw/SUNjbHOtvc6gJHP1x5/yTkZ1z8g4raaoiFTnKex/u69C5swGDHxG0GWJ7tJpJN9Q xF01jqbUARGEKGtCUSZVNyXlQHs7Ba/GN/CEk= MIME-Version: 1.0 Received: by 10.216.133.86 with SMTP id p64mr4476977wei.95.1320076808237; Mon, 31 Oct 2011 09:00:08 -0700 (PDT) Received: by 10.216.22.137 with HTTP; Mon, 31 Oct 2011 09:00:08 -0700 (PDT) In-Reply-To: <21E7D9BD69CC7241AAE00F4EA183B719014CE67F@008-AM1MPN1-071.mgdnok.nokia.com> References: <4EAA9B4A.3020208@piuha.net> <4EAA9E34.2080903@piuha.net> <21E7D9BD69CC7241AAE00F4EA183B719014CE67F@008-AM1MPN1-071.mgdnok.nokia.com> Date: Tue, 1 Nov 2011 00:00:08 +0800 Message-ID: From: Hui Deng To: Basavaraj.Patil@nokia.com Content-Type: multipart/alternative; boundary=0016e6de17d43b34ce04b09a55de Cc: jari.arkko@piuha.net, mext@ietf.org Subject: Re: [MEXT] the future of the MEXT working group X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Oct 2011 16:00:15 -0000 --0016e6de17d43b34ce04b09a55de Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi Raj, >From my reading of the AD's email, 1. DMM has been already in mext charter before, I don't see why we need BOF process, it is just about rechartering. 2. AD has already said that other left work could be sponsored by AD, so it doesn't kick out any extension of MIP6/DSMIP6 if there is. Thanks -Hui 2011/10/31 > ** ** > > Hi Jari,**** > > ** ** > > A couple of quick questions:**** > > ** ** > > **1. **Is this a recharter of the MEXT WG or the formation of a new > WG to deal with DMM? If it is the latter I would be concerned that a WG i= s > being formed without going through the IETF BoF process. I realize that D= MM > was in the scope of the MEXT WG. But proposed new charter pretty much > throws everything else w.r.t MIP6/DSMIP6 out of this new WG.**** > > **2. **There needs to be a WG and home for continued work w.r.t > improvements to MIP6/DSMIP6 protocol in terms of extensions, deployabilit= y > improvements etc. The proposed charter does not consider this at all.**** > > ** ** > > -Basavaraj**** > > ** ** > > *From:* mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] *On Behalf > Of *ext Jari Arkko > *Sent:* Friday, October 28, 2011 7:21 AM > *To:* mext@ietf.org > *Subject:* Re: [MEXT] the future of the MEXT working group**** > > ** ** > > And a follow-up on the charter. I'm describing a couple of different take= s > on what the new charter could be. Comments and alternative proposals are > welcome. This is what the current charter says about DMM: > > > **** > > The working group will also work on operational considerations on > setting up Mobile IPv6 networks so that traffic is distributed > in an optimal way, for instance by using existing protocol mechanisms > to select the closest home agents for new clients. > > Oct 2011 - Submit I-D 'Operational considerations for distributed use o= f > Mobile IPv6' for publication as Informational.**** > > > Which is admittedly a bit short, but is also very concrete and achievable= , > if we work on it. I got another proposal from Hui Deng that extended this= a > bit, including going beyond mere operational considerations. > > > **** > > In the past decade a fair number of mobility protocols have been > standardized. Although the protocols differ in terms of functions and > associated message format, we can identify a few key common features: > presence of a centralized mobility anchor providing global reachability > and an always-on experience > extensions to optimize handover performance while users roam across > wireless cells > extensions to enable the use of heterogeneous wireless interfaces for > multi-mode terminals (e.g. cellular phones) > The presence of the centralized mobility anchor allows a mobile device to > be reachable when it is not connected to its home domain. The anchor, amo= ng > other tasks, ensures forwarding of packets destined to or sent from the > mobile device. As such, most of the deployed architectures today have a > small number of centralized anchors managing the traffic of millions of > mobile subscribers. > > To optimize handovers for mobile users, the base protocols have been > extended to efficiently handle packet forwarding between the previous and > new points of attachment. These extensions are necessary when application= s > impose stringent requirements in terms of delay. Notions of localization > and distribution of local agents have been introduced to reduce signallin= g > overhead. Unfortunately today we witness difficulties in getting such > protocols deployed, often leading to sub-optimal choices. Moreover, all t= he > availability of multi-mode devices and the possibility to use several > network interfaces simultaneously have motivated the development of more > new protocol extensions. > > Mobile users are, more than ever, consuming Internet content, and impose > new requirements on mobile core networks for data traffic delivery. When > this traffic demand exceeds available capacity, service providers need to > implement new strategies such as selective traffic offload (e.g. 3GPP wor= k > items LIPA/SIPTO) through alternative access networks (e.g. WLAN). > Moreover, the localization of content providers closer to the Mobile/Fixe= d > Internet Service Providers network requires taking into account local > Content Delivery Networks (CDNs) while providing mobility services. > > As long as demand exceeds capacity, both offloading and CDN techniques > could benefit from the development of more flat mobile architectures (i.e= ., > fewer levels of routing hierarchy introduced into the data path by the > mobility management system). This view is reinforced by the shift in user= s=92 > traffic behaviour, aimed at increasing direct communications among peers = in > the same geographical area. The development of truly flat mobile > architectures would result in anchoring the traffic closer to point of > attachment of the user and overcoming the suboptimal routing issues of a > centralized mobility scheme. > > While deploying today=92s mobile networks, service providers face new > challenges. More often than not, mobile devices remain attached to the sa= me > point of attachment, in which case specific IP mobility management suppor= t > is not required for applications that launch and complete while connected > to the same point of attachment. However, the mobility support has been > designed to be always on and to maintain the context for each mobile > subscriber as long as they are connected to the network. This can result = in > a waste of resources and ever-increasing costs for the service provider. > Infrequent mobility and intelligence of many applications suggest that > mobility can be provided dynamically, thus simplifying the context > maintained in the different nodes of the mobile network. > > The proposed charter will address two complementary aspects of mobility > management procedures: the distribution of mobility anchors to achieve a > more flat design and the dynamic activation/deactivation of mobility > protocol support as an enabler to distributed mobility management. The > former has the goal of positioning mobility anchors (HA, LMA) closer to t= he > user; ideally, these mobility anchors could be collocated with the first > hop router. The latter, facilitated by the distribution of mobility > anchors, aims at identifying when mobility must be activated and > identifying sessions that do not impose mobility management -- thus > reducing the amount of state information to be maintained in the various > mobility anchors of the mobile network. The key idea is that dynamic > mobility management relaxes some constraints while also repositioning > mobility anchors; it avoids the establishment of non optimal tunnels > between two anchors topologically distant. > > Considering the above, the working group will: > > Define the problem statement and associated requirements for distributed > mobility management. This work aims at defining the problem space and > identifies the key functional requirements. > > Produce a gap analysis mapping the above requirements against existing > solutions. > > Give best practices for the deployment of existing mobility protocols in = a > distributed mobility management and describe limitations of each such > approach. > > Describe extensions, if needed, to current mobility protocols for their > application in distributed mobility architectures **** > > > Comments? > > Jari**** > > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext > > --0016e6de17d43b34ce04b09a55de Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
Hi Raj,
=A0
From my reading of the AD's email,
1. DMM has been already in mext charter before, I don't see why we= need BOF process, it is just about rechartering.
2. AD has already said that other left work could be sponsored by AD, = so it doesn't kick out any extension of MIP6/DSMIP6 if there is.
Thanks
=A0
-Hui
=A0
2011/10/31 <Basavaraj.Patil@nokia.com>

<= /u>=A0

Hi J= ari,

<= /u>=A0

A co= uple of quick questions:

<= /u>=A0

1.=A0=A0=A0=A0=A0=A0 Is this a re= charter of the MEXT WG or the formation of a new WG to deal with DMM? If it= is the latter I would be concerned that a WG is being formed without going= through the IETF BoF process. I realize that DMM was in the scope of the M= EXT WG. But proposed new charter pretty much throws everything else w.r.t M= IP6/DSMIP6 out of this new WG.

2.=A0=A0=A0=A0=A0=A0 There needs = to be a WG and home for continued work w.r.t improvements to MIP6/DSMIP6 pr= otocol in terms of extensions, deployability improvements etc. The proposed= charter does not consider this at all.

<= /u>=A0

-Bas= avaraj

<= /u>=A0

mext-bounces@ietf.org= [mailto:mex= t-bounces@ietf.org] On Behalf Of ext Jari Arkko
Sent: Friday, October 28, 2011 7:21 AM
To: mext@ietf.org
Subject: Re= : [MEXT] the future of the MEXT working group

=A0

And a follow-up on the charter. I'm describing a= couple of different takes on what the new charter could be. Comments and a= lternative proposals are welcome. This is what the current charter says abo= ut DMM:


=A0 The working group will also work on operational = considerations on
=A0 setting up Mobile IPv6 networks so that traffic is= distributed
=A0 in an optimal way, for instance by using existing proto= col mechanisms
=A0 to select the closest home agents for new clients.

=A0 Oct 2011 = - Submit I-D 'Operational considerations for distributed use of Mobile = IPv6' for publication as Informational.


Which is admittedly a bit short, but is also ver= y concrete and achievable, if we work on it. I got another proposal from Hu= i Deng that extended this a bit, including going beyond mere operational co= nsiderations.


In the past decade a fair number of mobility protoco= ls have been standardized. Although the protocols differ in terms of functi= ons and associated message format, we can identify a few key common feature= s:
presence of a centralized mobility anchor providing global reachability and= an always-on experience
extensions to optimize handover performance whi= le users roam across wireless cells
extensions to enable the use of hete= rogeneous wireless interfaces for multi-mode terminals (e.g. cellular phone= s)
The presence of the centralized mobility anchor allows a mobile device to b= e reachable when it is not connected to its home domain. The anchor, among = other tasks, ensures forwarding of packets destined to or sent from the mob= ile device. As such, most of the deployed architectures today have a small = number of centralized anchors managing the traffic of millions of mobile su= bscribers.

To optimize handovers for mobile users, the base protocols have been ex= tended to efficiently handle packet forwarding between the previous and new= points of attachment. These extensions are necessary when applications imp= ose stringent requirements in terms of delay. Notions of localization and d= istribution of local agents have been introduced to reduce signalling overh= ead. Unfortunately today we witness difficulties in getting such protocols = deployed, often leading to sub-optimal choices. Moreover, all the availabil= ity of multi-mode devices and the possibility to use several network interf= aces simultaneously have motivated the development of more new protocol ext= ensions.

Mobile users are, more than ever, consuming Internet content, and impos= e new requirements on mobile core networks for data traffic delivery. When = this traffic demand exceeds available capacity, service providers need to i= mplement new strategies such as selective traffic offload (e.g. 3GPP work i= tems LIPA/SIPTO) through alternative access networks (e.g. WLAN). Moreover,= the localization of content providers closer to the Mobile/Fixed Internet = Service Providers network requires taking into account local Content Delive= ry Networks (CDNs) while providing mobility services.=A0

As long as demand exceeds capacity, both offloading and CDN techniques = could benefit from the development of more flat mobile architectures (i.e.,= fewer levels of routing hierarchy introduced into the data path by the mob= ility management system). This view is reinforced by the shift in users=92 = traffic behaviour, aimed at increasing direct communications among peers in= the same geographical area. The development of truly flat mobile architect= ures would result in anchoring the traffic closer to point of attachment of= the user and overcoming the suboptimal routing issues of a centralized mob= ility scheme.

While deploying today=92s mobile networks, service providers face new c= hallenges. More often than not, mobile devices remain attached to the same = point of attachment, in which case specific IP mobility management support = is not required for applications that launch and complete while connected t= o the same point of attachment. However, the mobility support has been desi= gned to be always on and to maintain the context for each mobile subscriber= as long as they are connected to the network. This can result in a waste o= f resources and ever-increasing costs for the service provider. Infrequent = mobility and intelligence of many applications suggest that mobility can be= provided dynamically, thus simplifying the context maintained in the diffe= rent nodes of the mobile network.

The proposed charter will address two complementary aspects of mobility= management procedures: the distribution of mobility anchors to achieve a m= ore flat design and the dynamic activation/deactivation of mobility protoco= l support as an enabler to distributed mobility management. The former has = the goal of positioning mobility anchors (HA, LMA) closer to the user; idea= lly, these mobility anchors could be collocated with the first hop router. = The latter, facilitated by the distribution of mobility anchors, aims at id= entifying when mobility must be activated and identifying sessions that do = not impose mobility management -- thus reducing the amount of state informa= tion to be maintained in the various mobility anchors of the mobile network= . The key idea is that dynamic mobility management relaxes some constraints= while also repositioning mobility anchors; it avoids the establishment of = non optimal tunnels between two anchors topologically distant.

Considering the above, the working group will:

Define the proble= m statement and associated requirements for distributed mobility management= . This work aims at defining the problem space and identifies the key funct= ional requirements.

Produce a gap analysis mapping the above requirements against existing = solutions.

Give best practices for the deployment of existing mobili= ty protocols in a distributed mobility management and describe limitations = of each such approach.

Describe extensions, if needed, to current mobility protocols for their= application in distributed mobility architectures


Comments?

J= ari


__________________________= _____________________
MEXT mailing list
MEXT@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/mext


--0016e6de17d43b34ce04b09a55de-- From ryuji.wakikawa@gmail.com Mon Oct 31 10:08:58 2011 Return-Path: X-Original-To: mext@ietfa.amsl.com Delivered-To: mext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 23BFF11E8119 for ; Mon, 31 Oct 2011 10:08:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M+JB8jKrB2tw for ; Mon, 31 Oct 2011 10:08:57 -0700 (PDT) Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by ietfa.amsl.com (Postfix) with ESMTP id 445C211E8180 for ; Mon, 31 Oct 2011 10:08:57 -0700 (PDT) Received: by qadc10 with SMTP id c10so6571672qad.31 for ; Mon, 31 Oct 2011 10:08:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=QBgNsIdfK5usOMrItM8rBZj+H7HVumir0doO+Zdyos4=; b=idhuuiiTKFxrpsvp7sPkNICMnbnsJUEF8YFhrn6wRj/0aKyzc9/Xhyar7kLGrCLFHJ PI2VOGsD7OKY0rjV6Hq/7Czv8WaaRSdA3PpFO/QsCKr5+9FjuEQu4pMOQkoK7oRmFfqA 3PB9O74M3dM7k7vRMuk/le/likuFioVj8h3/o= Received: by 10.68.44.168 with SMTP id f8mr25146803pbm.11.1320080929273; Mon, 31 Oct 2011 10:08:49 -0700 (PDT) Received: from [192.168.110.139] ([206.132.173.18]) by mx.google.com with ESMTPS id y6sm40618193pbi.5.2011.10.31.10.08.46 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 31 Oct 2011 10:08:47 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Ryuji Wakikawa In-Reply-To: <4EAA9B4A.3020208@piuha.net> Date: Mon, 31 Oct 2011 10:08:44 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4EAA9B4A.3020208@piuha.net> To: Jari Arkko X-Mailer: Apple Mail (2.1084) Cc: "jouni.korhonen@nsn.com" , "mext@ietf.org" Subject: Re: [MEXT] the future of the MEXT working group X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Oct 2011 17:08:58 -0000 Jari Thanks for this update. I want to clarify plan of the existing = activity, HA reliability doc, in MEXT.=20 This document completed WGLC and went nowhere after all.=20 It supposes to be proposed standard RFC. Do you want to finish this work with AD sponsor? or just trash it? thanks ryuji On 2011/10/28, at 5:08, Jari Arkko wrote: > All, >=20 > We are making some changes to the working group. While we have = successfully published a large number of specifications in recent years, = recently it has been difficult to make progress in the group. The chairs = and ADs have looked at the situation and we believe we need a new focus = and a bit of new organization as well. We are terminating the working = group and moving the one remaining active work item to a new working = group, the "DMM" working group. Here's what is going to happen: >=20 > o Jouni Korhonen and Julien Laganier will become the chairs of the = group. >=20 > o The group will meet in Taipei (there is a MEXT slot in the agenda). >=20 > o The charter of the group will be changed to focus only on the = distributed mobility effort. We should discuss the details of this = charter change both on the list and in the meeting. The meeting agenda = should reserve some time both for technical discussions as well as the = charter discussion. >=20 > o Once the discussion on the list and in the meeting has finished, we = will rename the group to "DMM" and put the new charter in effect. >=20 > o If there are any other specifications that people would like to = publish beyond the distributed mobility work, we can offer to AD sponsor = them to RFCs outside the new working group. If there is some significant = new activity, we can create new working groups for that. >=20 > Comments and feedback and/or alternate suggestions on this plan are = welcome. >=20 > We would like to thank Marcelo for your many years of service in MEXT. = We could not have completed all the work we did without your energy and = push for high quality results. We would also like to thank Jouni for = taking on this new challenge, and Julien for continuing the work in this = space. >=20 > Jari and Ralph >=20 > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext From Basavaraj.Patil@nokia.com Mon Oct 31 10:24:49 2011 Return-Path: X-Original-To: mext@ietfa.amsl.com Delivered-To: mext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB8831F0C35 for ; Mon, 31 Oct 2011 10:24:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.009 X-Spam-Level: X-Spam-Status: No, score=-103.009 tagged_above=-999 required=5 tests=[AWL=0.274, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, SARE_MILLIONSOF=0.315, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uLL9nc52m6Om for ; Mon, 31 Oct 2011 10:24:48 -0700 (PDT) Received: from mgw-da01.nokia.com (smtp.nokia.com [147.243.128.24]) by ietfa.amsl.com (Postfix) with ESMTP id 15A761F0C3B for ; Mon, 31 Oct 2011 10:24:47 -0700 (PDT) Received: from vaebh101.NOE.Nokia.com (vaebh101.europe.nokia.com [10.160.244.22]) by mgw-da01.nokia.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id p9VHOf3g014793; Mon, 31 Oct 2011 19:24:45 +0200 Received: from smtp.mgd.nokia.com ([65.54.30.8]) by vaebh101.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Mon, 31 Oct 2011 19:24:34 +0200 Received: from 008-AM1MMR1-009.mgdnok.nokia.com (65.54.30.25) by NOK-AM1MHUB-04.mgdnok.nokia.com (65.54.30.8) with Microsoft SMTP Server (TLS) id 8.2.255.0; Mon, 31 Oct 2011 18:24:33 +0100 Received: from 008-AM1MPN1-071.mgdnok.nokia.com ([169.254.1.235]) by 008-AM1MMR1-009.mgdnok.nokia.com ([65.54.30.25]) with mapi id 14.01.0339.002; Mon, 31 Oct 2011 18:24:33 +0100 From: To: Thread-Topic: [MEXT] the future of the MEXT working group Thread-Index: AQHMlWpmfRWG/cEPIEyACm1+ri2dNZWRi8gAgADD+FCABED6AP//w8EA Date: Mon, 31 Oct 2011 17:24:31 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.13.0.110805 x-originating-ip: [172.19.59.135] Content-Type: multipart/alternative; boundary="_000_CAD4426112F00basavarajpatilnokiacom_" MIME-Version: 1.0 X-OriginalArrivalTime: 31 Oct 2011 17:24:34.0758 (UTC) FILETIME=[F5701E60:01CC97F1] X-Nokia-AV: Clean Cc: jari.arkko@piuha.net, mext@ietf.org Subject: Re: [MEXT] the future of the MEXT working group X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Oct 2011 17:24:49 -0000 --_000_CAD4426112F00basavarajpatilnokiacom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi Hui, I will let Jari respond and explain his intent. I recognize that DMM was pa= rt of the charter of MEXT as I mentioned in my email. The new charter is ba= sically nothing but DMM and IMO it is more than just rechartering the WG. AD sponsorship of currently ongoing work is one option. But I believe a bet= ter option is for the scope of MEXT to be continued and not completely shut= down. -Raj From: ext Hui Deng > Date: Tue, 1 Nov 2011 00:00:08 +0800 To: Basavaraj Patil > Cc: ext Arkko >, "mext@ie= tf.org" > Subject: Re: [MEXT] the future of the MEXT working group Hi Raj, >From my reading of the AD's email, 1. DMM has been already in mext charter before, I don't see why we need BOF= process, it is just about rechartering. 2. AD has already said that other left work could be sponsored by AD, so it= doesn't kick out any extension of MIP6/DSMIP6 if there is. Thanks -Hui 2011/10/31 > Hi Jari, A couple of quick questions: 1. Is this a recharter of the MEXT WG or the formation of a new WG to= deal with DMM? If it is the latter I would be concerned that a WG is being= formed without going through the IETF BoF process. I realize that DMM was = in the scope of the MEXT WG. But proposed new charter pretty much throws ev= erything else w.r.t MIP6/DSMIP6 out of this new WG. 2. There needs to be a WG and home for continued work w.r.t improveme= nts to MIP6/DSMIP6 protocol in terms of extensions, deployability improveme= nts etc. The proposed charter does not consider this at all. -Basavaraj From: mext-bounces@ietf.org [mailto:mext-boun= ces@ietf.org] On Behalf Of ext Jari Arkko Sent: Friday, October 28, 2011 7:21 AM To: mext@ietf.org Subject: Re: [MEXT] the future of the MEXT working group And a follow-up on the charter. I'm describing a couple of different takes = on what the new charter could be. Comments and alternative proposals are we= lcome. This is what the current charter says about DMM: The working group will also work on operational considerations on setting up Mobile IPv6 networks so that traffic is distributed in an optimal way, for instance by using existing protocol mechanisms to select the closest home agents for new clients. Oct 2011 - Submit I-D 'Operational considerations for distributed use of = Mobile IPv6' for publication as Informational. Which is admittedly a bit short, but is also very concrete and achievable, = if we work on it. I got another proposal from Hui Deng that extended this a= bit, including going beyond mere operational considerations. In the past decade a fair number of mobility protocols have been standardiz= ed. Although the protocols differ in terms of functions and associated mess= age format, we can identify a few key common features: presence of a centralized mobility anchor providing global reachability and= an always-on experience extensions to optimize handover performance while users roam across wireles= s cells extensions to enable the use of heterogeneous wireless interfaces for multi= -mode terminals (e.g. cellular phones) The presence of the centralized mobility anchor allows a mobile device to b= e reachable when it is not connected to its home domain. The anchor, among = other tasks, ensures forwarding of packets destined to or sent from the mob= ile device. As such, most of the deployed architectures today have a small = number of centralized anchors managing the traffic of millions of mobile su= bscribers. To optimize handovers for mobile users, the base protocols have been extend= ed to efficiently handle packet forwarding between the previous and new poi= nts of attachment. These extensions are necessary when applications impose = stringent requirements in terms of delay. Notions of localization and distr= ibution of local agents have been introduced to reduce signalling overhead.= Unfortunately today we witness difficulties in getting such protocols depl= oyed, often leading to sub-optimal choices. Moreover, all the availability = of multi-mode devices and the possibility to use several network interfaces= simultaneously have motivated the development of more new protocol extensi= ons. Mobile users are, more than ever, consuming Internet content, and impose ne= w requirements on mobile core networks for data traffic delivery. When this= traffic demand exceeds available capacity, service providers need to imple= ment new strategies such as selective traffic offload (e.g. 3GPP work items= LIPA/SIPTO) through alternative access networks (e.g. WLAN). Moreover, the= localization of content providers closer to the Mobile/Fixed Internet Serv= ice Providers network requires taking into account local Content Delivery N= etworks (CDNs) while providing mobility services. As long as demand exceeds capacity, both offloading and CDN techniques coul= d benefit from the development of more flat mobile architectures (i.e., few= er levels of routing hierarchy introduced into the data path by the mobilit= y management system). This view is reinforced by the shift in users=92 traf= fic behaviour, aimed at increasing direct communications among peers in the= same geographical area. The development of truly flat mobile architectures= would result in anchoring the traffic closer to point of attachment of the= user and overcoming the suboptimal routing issues of a centralized mobilit= y scheme. While deploying today=92s mobile networks, service providers face new chall= enges. More often than not, mobile devices remain attached to the same poin= t of attachment, in which case specific IP mobility management support is n= ot required for applications that launch and complete while connected to th= e same point of attachment. However, the mobility support has been designed= to be always on and to maintain the context for each mobile subscriber as = long as they are connected to the network. This can result in a waste of re= sources and ever-increasing costs for the service provider. Infrequent mobi= lity and intelligence of many applications suggest that mobility can be pro= vided dynamically, thus simplifying the context maintained in the different= nodes of the mobile network. The proposed charter will address two complementary aspects of mobility man= agement procedures: the distribution of mobility anchors to achieve a more = flat design and the dynamic activation/deactivation of mobility protocol su= pport as an enabler to distributed mobility management. The former has the = goal of positioning mobility anchors (HA, LMA) closer to the user; ideally,= these mobility anchors could be collocated with the first hop router. The = latter, facilitated by the distribution of mobility anchors, aims at identi= fying when mobility must be activated and identifying sessions that do not = impose mobility management -- thus reducing the amount of state information= to be maintained in the various mobility anchors of the mobile network. Th= e key idea is that dynamic mobility management relaxes some constraints whi= le also repositioning mobility anchors; it avoids the establishment of non = optimal tunnels between two anchors topologically distant. Considering the above, the working group will: Define the problem statement and associated requirements for distributed mo= bility management. This work aims at defining the problem space and identif= ies the key functional requirements. Produce a gap analysis mapping the above requirements against existing solu= tions. Give best practices for the deployment of existing mobility protocols in a = distributed mobility management and describe limitations of each such appro= ach. Describe extensions, if needed, to current mobility protocols for their app= lication in distributed mobility architectures Comments? Jari _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext --_000_CAD4426112F00basavarajpatilnokiacom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <776FF6136E936847A623BF0681DD7103@nokia.com> Content-Transfer-Encoding: quoted-printable

Hi Hui,

I will let Jari respond and explain his intent. I recognize that DMM w= as part of the charter of MEXT as I mentioned in my email. The new charter = is basically nothing but DMM and IMO it is more than just rechartering the = WG. 
AD sponsorship of currently ongoing work is one option. But I believe = a better option is for the scope of MEXT to be continued and not completely= shutdown.

-Raj

From: ext Hui Deng <denghui02@gmail.com>
Date: Tue, 1 Nov 2011 00:00:08 += ;0800
To: Basavaraj Patil <basavaraj.patil@nokia.com>
Cc: ext Arkko <jari.arkko@piuha.net>, "mext@ietf.org" <mext@ietf.org>
Subject: Re: [MEXT] the future of t= he MEXT working group

Hi Raj,
 
From my reading of the AD's email,
1. DMM has been already in mext charter before, I don't see why we nee= d BOF process, it is just about rechartering.
2. AD has already said that other left work could be sponsored by AD, = so it doesn't kick out any extension of MIP6/DSMIP6 if there is.

Thanks
 
-Hui
 
2011/10/31 <Basavaraj.Patil@nokia.com>

<= /u> 

Hi J= ari,

<= /u> 

A co= uple of quick questions:

<= /u> 

1.       Is this a recharter of the MEXT WG or the formation of a new WG to deal wi= th DMM? If it is the latter I would be concerned that a WG is being formed = without going through the IETF BoF process. I realize that DMM was in the scope of the MEXT WG. But proposed = new charter pretty much throws everything else w.r.t MIP6/DSMIP6 out of thi= s new WG.

2.       There needs to be a WG and home for continued work w.r.t improvements to M= IP6/DSMIP6 protocol in terms of extensions, deployability improvements etc.= The proposed charter does not consider this at all.

<= /u> 

-Bas= avaraj

<= /u> 

mext-bounces@iet= f.org [mailto:mext-bounces@ietf.org] On Behalf Of ext Jari Arkko
Sent: Friday, October 28, 2011 7:21 AM
To: mext@ietf.org=
Subject: Re: [MEXT] the future of the MEXT working group

 

And a follow-up on the charter. I'm describing a cou= ple of different takes on what the new charter could be. Comments and alter= native proposals are welcome. This is what the current charter says about D= MM:


  The working group will also work on operation= al considerations on
  setting up Mobile IPv6 networks so that traffic is distributed
  in an optimal way, for instance by using existing protocol mechanism= s
  to select the closest home agents for new clients.

  Oct 2011 - Submit I-D 'Operational considerations for distributed us= e of Mobile IPv6' for publication as Informational.


Which is admittedly a bit short, but is also very concrete and achievable, = if we work on it. I got another proposal from Hui Deng that extended this a= bit, including going beyond mere operational considerations.


In the past decade a fair number of mobility protoco= ls have been standardized. Although the protocols differ in terms of functi= ons and associated message format, we can identify a few key common feature= s:
presence of a centralized mobility anchor providing global reachability and= an always-on experience
extensions to optimize handover performance while users roam across wireles= s cells
extensions to enable the use of heterogeneous wireless interfaces for multi= -mode terminals (e.g. cellular phones)
The presence of the centralized mobility anchor allows a mobile device to b= e reachable when it is not connected to its home domain. The anchor, among = other tasks, ensures forwarding of packets destined to or sent from the mob= ile device. As such, most of the deployed architectures today have a small number of centralized anchors ma= naging the traffic of millions of mobile subscribers.

To optimize handovers for mobile users, the base protocols have been extend= ed to efficiently handle packet forwarding between the previous and new poi= nts of attachment. These extensions are necessary when applications impose = stringent requirements in terms of delay. Notions of localization and distribution of local agents have be= en introduced to reduce signalling overhead. Unfortunately today we witness= difficulties in getting such protocols deployed, often leading to sub-opti= mal choices. Moreover, all the availability of multi-mode devices and the possibility to use several network interface= s simultaneously have motivated the development of more new protocol extens= ions.

Mobile users are, more than ever, consuming Internet content, and impose ne= w requirements on mobile core networks for data traffic delivery. When this= traffic demand exceeds available capacity, service providers need to imple= ment new strategies such as selective traffic offload (e.g. 3GPP work items LIPA/SIPTO) through alternative acce= ss networks (e.g. WLAN). Moreover, the localization of content providers cl= oser to the Mobile/Fixed Internet Service Providers network requires taking= into account local Content Delivery Networks (CDNs) while providing mobility services. 

As long as demand exceeds capacity, both offloading and CDN techniques coul= d benefit from the development of more flat mobile architectures (i.e., few= er levels of routing hierarchy introduced into the data path by the mobilit= y management system). This view is reinforced by the shift in users=92 traffic behaviour, aimed at increas= ing direct communications among peers in the same geographical area. The de= velopment of truly flat mobile architectures would result in anchoring the = traffic closer to point of attachment of the user and overcoming the suboptimal routing issues of a centralized = mobility scheme.

While deploying today=92s mobile networks, service providers face new chall= enges. More often than not, mobile devices remain attached to the same poin= t of attachment, in which case specific IP mobility management support is n= ot required for applications that launch and complete while connected to the same point of attachment. Howev= er, the mobility support has been designed to be always on and to maintain = the context for each mobile subscriber as long as they are connected to the= network. This can result in a waste of resources and ever-increasing costs for the service provider. Infrequen= t mobility and intelligence of many applications suggest that mobility can = be provided dynamically, thus simplifying the context maintained in the dif= ferent nodes of the mobile network.

The proposed charter will address two complementary aspects of mobility man= agement procedures: the distribution of mobility anchors to achieve a more = flat design and the dynamic activation/deactivation of mobility protocol su= pport as an enabler to distributed mobility management. The former has the goal of positioning mobility ancho= rs (HA, LMA) closer to the user; ideally, these mobility anchors could be c= ollocated with the first hop router. The latter, facilitated by the distrib= ution of mobility anchors, aims at identifying when mobility must be activated and identifying sessions th= at do not impose mobility management -- thus reducing the amount of state i= nformation to be maintained in the various mobility anchors of the mobile n= etwork. The key idea is that dynamic mobility management relaxes some constraints while also repositioning mobi= lity anchors; it avoids the establishment of non optimal tunnels between tw= o anchors topologically distant.

Considering the above, the working group will:

Define the problem statement and associated requirements for distributed mo= bility management. This work aims at defining the problem space and identif= ies the key functional requirements.

Produce a gap analysis mapping the above requirements against existing solu= tions.

Give best practices for the deployment of existing mobility protocols in a = distributed mobility management and describe limitations of each such appro= ach.

Describe extensions, if needed, to current mobility protocols for their app= lication in distributed mobility architectures


Comments?

Jari


_______________________________________________
MEXT mailing list
MEXT@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/mext


 --_000_CAD4426112F00basavarajpatilnokiacom_-- From jari.arkko@piuha.net Mon Oct 31 12:59:02 2011 Return-Path: X-Original-To: mext@ietfa.amsl.com Delivered-To: mext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 670A821F8D9E for ; Mon, 31 Oct 2011 12:59:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m3sgqNPP9naH for ; Mon, 31 Oct 2011 12:59:01 -0700 (PDT) Received: from p130.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by ietfa.amsl.com (Postfix) with ESMTP id 90AFC21F8D9D for ; Mon, 31 Oct 2011 12:59:01 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id E0C502CC45; Mon, 31 Oct 2011 21:59:00 +0200 (EET) X-Virus-Scanned: amavisd-new at piuha.net Received: from p130.piuha.net ([127.0.0.1]) by localhost (p130.piuha.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TW2lo9oM4rIL; Mon, 31 Oct 2011 21:59:00 +0200 (EET) Received: from [127.0.0.1] (p130.piuha.net [IPv6:2001:14b8:400::130]) by p130.piuha.net (Postfix) with ESMTP id E8E4B2CC31; Mon, 31 Oct 2011 21:58:59 +0200 (EET) Message-ID: <4EAEFE03.3010900@piuha.net> Date: Mon, 31 Oct 2011 21:58:59 +0200 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: Ryuji Wakikawa References: <4EAA9B4A.3020208@piuha.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "jouni.korhonen@nsn.com" , "mext@ietf.org" Subject: Re: [MEXT] the future of the MEXT working group X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Oct 2011 19:59:02 -0000 Did it successfully complete WGLC? With sufficient support for taking the document forward? If yes, the chairs can either send it immediately to me as a WG output. Or I can AD sponsor it later. The offer to AD sponsor is also valid for other documents. They need to be in reasonable shape, naturally. Jari On 31.10.2011 19:08, Ryuji Wakikawa wrote: > Jari > > Thanks for this update. I want to clarify plan of the existing activity, HA reliability doc, in MEXT. > This document completed WGLC and went nowhere after all. > It supposes to be proposed standard RFC. > Do you want to finish this work with AD sponsor? or just trash it? > > thanks > ryuji > > On 2011/10/28, at 5:08, Jari Arkko wrote: > >> All, >> >> We are making some changes to the working group. While we have successfully published a large number of specifications in recent years, recently it has been difficult to make progress in the group. The chairs and ADs have looked at the situation and we believe we need a new focus and a bit of new organization as well. We are terminating the working group and moving the one remaining active work item to a new working group, the "DMM" working group. Here's what is going to happen: >> >> o Jouni Korhonen and Julien Laganier will become the chairs of the group. >> >> o The group will meet in Taipei (there is a MEXT slot in the agenda). >> >> o The charter of the group will be changed to focus only on the distributed mobility effort. We should discuss the details of this charter change both on the list and in the meeting. The meeting agenda should reserve some time both for technical discussions as well as the charter discussion. >> >> o Once the discussion on the list and in the meeting has finished, we will rename the group to "DMM" and put the new charter in effect. >> >> o If there are any other specifications that people would like to publish beyond the distributed mobility work, we can offer to AD sponsor them to RFCs outside the new working group. If there is some significant new activity, we can create new working groups for that. >> >> Comments and feedback and/or alternate suggestions on this plan are welcome. >> >> We would like to thank Marcelo for your many years of service in MEXT. We could not have completed all the work we did without your energy and push for high quality results. We would also like to thank Jouni for taking on this new challenge, and Julien for continuing the work in this space. >> >> Jari and Ralph >> >> _______________________________________________ >> MEXT mailing list >> MEXT@ietf.org >> https://www.ietf.org/mailman/listinfo/mext > From julien.ietf@gmail.com Mon Oct 31 13:33:08 2011 Return-Path: X-Original-To: mext@ietfa.amsl.com Delivered-To: mext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A152C11E8241 for ; Mon, 31 Oct 2011 13:33:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.011 X-Spam-Level: X-Spam-Status: No, score=-3.011 tagged_above=-999 required=5 tests=[AWL=0.273, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, SARE_MILLIONSOF=0.315] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ncKiOSOBLmTj for ; Mon, 31 Oct 2011 13:33:07 -0700 (PDT) Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by ietfa.amsl.com (Postfix) with ESMTP id 94AE111E8242 for ; Mon, 31 Oct 2011 13:33:07 -0700 (PDT) Received: by qadc10 with SMTP id c10so6787423qad.31 for ; Mon, 31 Oct 2011 13:33:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=zof/lku/XMQNKfiVYNHIsevZMqFctZTr9slsB1W6140=; b=xbp19sjTS0aUNjZ7jiIU72sCn2ie7obRWWBxuJ9sASju7UlVzqKv058s8QI58IQQgv kVSnwfvN5i0GgBDlerDqaHtz2ynhmnmqxdoiOmZ6hQ/t3qEoA0oir4oYD635bH87WGod /D8cEjWgpdvrEEzxXg6RR2ptyGsfnYSHO4MbI= MIME-Version: 1.0 Received: by 10.68.15.170 with SMTP id y10mr4765378pbc.76.1320093186588; Mon, 31 Oct 2011 13:33:06 -0700 (PDT) Received: by 10.142.62.2 with HTTP; Mon, 31 Oct 2011 13:33:06 -0700 (PDT) In-Reply-To: <21E7D9BD69CC7241AAE00F4EA183B719014CE67F@008-AM1MPN1-071.mgdnok.nokia.com> References: <4EAA9B4A.3020208@piuha.net> <4EAA9E34.2080903@piuha.net> <21E7D9BD69CC7241AAE00F4EA183B719014CE67F@008-AM1MPN1-071.mgdnok.nokia.com> Date: Mon, 31 Oct 2011 13:33:06 -0700 Message-ID: From: Julien Laganier To: Basavaraj.Patil@nokia.com Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Cc: jari.arkko@piuha.net, mext@ietf.org Subject: Re: [MEXT] the future of the MEXT working group X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Oct 2011 20:33:08 -0000 Hi Raj, This is a rechartering of the WG. --julien On Mon, Oct 31, 2011 at 7:47 AM, wrote: > > > Hi Jari, > > > > A couple of quick questions: > > > > 1.=A0=A0=A0=A0=A0=A0 Is this a recharter of the MEXT WG or the formation = of a new WG to > deal with DMM? If it is the latter I would be concerned that a WG is bein= g > formed without going through the IETF BoF process. I realize that DMM was= in > the scope of the MEXT WG. But proposed new charter pretty much throws > everything else w.r.t MIP6/DSMIP6 out of this new WG. > > 2.=A0=A0=A0=A0=A0=A0 There needs to be a WG and home for continued work w= .r.t > improvements to MIP6/DSMIP6 protocol in terms of extensions, deployabilit= y > improvements etc. The proposed charter does not consider this at all. > > > > -Basavaraj > > > > From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] On Behalf Of e= xt > Jari Arkko > Sent: Friday, October 28, 2011 7:21 AM > To: mext@ietf.org > Subject: Re: [MEXT] the future of the MEXT working group > > > > And a follow-up on the charter. I'm describing a couple of different take= s > on what the new charter could be. Comments and alternative proposals are > welcome. This is what the current charter says about DMM: > > > =A0 The working group will also work on operational considerations on > =A0 setting up Mobile IPv6 networks so that traffic is distributed > =A0 in an optimal way, for instance by using existing protocol mechanisms > =A0 to select the closest home agents for new clients. > > =A0 Oct 2011 - Submit I-D 'Operational considerations for distributed use= of > Mobile IPv6' for publication as Informational. > > Which is admittedly a bit short, but is also very concrete and achievable= , > if we work on it. I got another proposal from Hui Deng that extended this= a > bit, including going beyond mere operational considerations. > > > In the past decade a fair number of mobility protocols have been > standardized. Although the protocols differ in terms of functions and > associated message format, we can identify a few key common features: > presence of a centralized mobility anchor providing global reachability a= nd > an always-on experience > extensions to optimize handover performance while users roam across wirel= ess > cells > extensions to enable the use of heterogeneous wireless interfaces for > multi-mode terminals (e.g. cellular phones) > The presence of the centralized mobility anchor allows a mobile device to= be > reachable when it is not connected to its home domain. The anchor, among > other tasks, ensures forwarding of packets destined to or sent from the > mobile device. As such, most of the deployed architectures today have a > small number of centralized anchors managing the traffic of millions of > mobile subscribers. > > To optimize handovers for mobile users, the base protocols have been > extended to efficiently handle packet forwarding between the previous and > new points of attachment. These extensions are necessary when application= s > impose stringent requirements in terms of delay. Notions of localization = and > distribution of local agents have been introduced to reduce signalling > overhead. Unfortunately today we witness difficulties in getting such > protocols deployed, often leading to sub-optimal choices. Moreover, all t= he > availability of multi-mode devices and the possibility to use several > network interfaces simultaneously have motivated the development of more = new > protocol extensions. > > Mobile users are, more than ever, consuming Internet content, and impose = new > requirements on mobile core networks for data traffic delivery. When this > traffic demand exceeds available capacity, service providers need to > implement new strategies such as selective traffic offload (e.g. 3GPP wor= k > items LIPA/SIPTO) through alternative access networks (e.g. WLAN). Moreov= er, > the localization of content providers closer to the Mobile/Fixed Internet > Service Providers network requires taking into account local Content > Delivery Networks (CDNs) while providing mobility services. > > As long as demand exceeds capacity, both offloading and CDN techniques co= uld > benefit from the development of more flat mobile architectures (i.e., few= er > levels of routing hierarchy introduced into the data path by the mobility > management system). This view is reinforced by the shift in users=92 traf= fic > behaviour, aimed at increasing direct communications among peers in the s= ame > geographical area. The development of truly flat mobile architectures wou= ld > result in anchoring the traffic closer to point of attachment of the user > and overcoming the suboptimal routing issues of a centralized mobility > scheme. > > While deploying today=92s mobile networks, service providers face new > challenges. More often than not, mobile devices remain attached to the sa= me > point of attachment, in which case specific IP mobility management suppor= t > is not required for applications that launch and complete while connected= to > the same point of attachment. However, the mobility support has been > designed to be always on and to maintain the context for each mobile > subscriber as long as they are connected to the network. This can result = in > a waste of resources and ever-increasing costs for the service provider. > Infrequent mobility and intelligence of many applications suggest that > mobility can be provided dynamically, thus simplifying the context > maintained in the different nodes of the mobile network. > > The proposed charter will address two complementary aspects of mobility > management procedures: the distribution of mobility anchors to achieve a > more flat design and the dynamic activation/deactivation of mobility > protocol support as an enabler to distributed mobility management. The > former has the goal of positioning mobility anchors (HA, LMA) closer to t= he > user; ideally, these mobility anchors could be collocated with the first = hop > router. The latter, facilitated by the distribution of mobility anchors, > aims at identifying when mobility must be activated and identifying sessi= ons > that do not impose mobility management -- thus reducing the amount of sta= te > information to be maintained in the various mobility anchors of the mobil= e > network. The key idea is that dynamic mobility management relaxes some > constraints while also repositioning mobility anchors; it avoids the > establishment of non optimal tunnels between two anchors topologically > distant. > > Considering the above, the working group will: > > Define the problem statement and associated requirements for distributed > mobility management. This work aims at defining the problem space and > identifies the key functional requirements. > > Produce a gap analysis mapping the above requirements against existing > solutions. > > Give best practices for the deployment of existing mobility protocols in = a > distributed mobility management and describe limitations of each such > approach. > > Describe extensions, if needed, to current mobility protocols for their > application in distributed mobility architectures > > Comments? > > Jari > > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext > > From Basavaraj.Patil@nokia.com Mon Oct 31 13:35:16 2011 Return-Path: X-Original-To: mext@ietfa.amsl.com Delivered-To: mext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D763111E8247 for ; Mon, 31 Oct 2011 13:35:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.54 X-Spam-Level: X-Spam-Status: No, score=-102.54 tagged_above=-999 required=5 tests=[AWL=-0.256, BAYES_00=-2.599, SARE_MILLIONSOF=0.315, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9ZfKCYPNgiwY for ; Mon, 31 Oct 2011 13:35:16 -0700 (PDT) Received: from mgw-sa02.nokia.com (smtp.nokia.com [147.243.1.48]) by ietfa.amsl.com (Postfix) with ESMTP id A622B11E8246 for ; Mon, 31 Oct 2011 13:35:15 -0700 (PDT) Received: from vaebh105.NOE.Nokia.com (vaebh105.europe.nokia.com [10.160.244.31]) by mgw-sa02.nokia.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id p9VKZDlj012658; Mon, 31 Oct 2011 22:35:13 +0200 Received: from smtp.mgd.nokia.com ([65.54.30.5]) by vaebh105.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Mon, 31 Oct 2011 22:35:12 +0200 Received: from 008-AM1MMR1-007.mgdnok.nokia.com (65.54.30.23) by NOK-am1MHUB-01.mgdnok.nokia.com (65.54.30.5) with Microsoft SMTP Server (TLS) id 8.2.255.0; Mon, 31 Oct 2011 21:35:12 +0100 Received: from 008-AM1MPN1-071.mgdnok.nokia.com ([169.254.1.235]) by 008-AM1MMR1-007.mgdnok.nokia.com ([65.54.30.23]) with mapi id 14.01.0339.002; Mon, 31 Oct 2011 21:35:11 +0100 From: To: Thread-Topic: [MEXT] the future of the MEXT working group Thread-Index: AQHMlWpmfRWG/cEPIEyACm1+ri2dNZWRi8gAgADD+FCABI0+AIAAEQUw Date: Mon, 31 Oct 2011 20:35:11 +0000 Message-ID: <21E7D9BD69CC7241AAE00F4EA183B719014CEC85@008-AM1MPN1-071.mgdnok.nokia.com> References: <4EAA9B4A.3020208@piuha.net> <4EAA9E34.2080903@piuha.net> <21E7D9BD69CC7241AAE00F4EA183B719014CE67F@008-AM1MPN1-071.mgdnok.nokia.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-tituslabs-classifications-30: TLPropertyRoot=Nokia;Confidentiality=Company Confidential;Project=None; x-titus-version: 3.3.8.1 x-headerinfofordlp: None x-tituslabs-classificationhash-30: VgNFIFU9Hx+/nZJb9Kg7IjQCNpuwNus9ut70eVa/NdKHRZFgdySinxYJu3y3D1U4nE3lPYIuSMwHG9a/XFxQj98oVjMe94TVxZpWS6Yg5Nt4XE2p2VDl4Foyl8CnNlpH5rIyYlGUk6yJPPAfLkB+nQy0tFePtVqQYbiaxn4XdxRjwz2nGF3Qjl2wyWgXRafGjqYhboQAymYT1nge4M/qJnD6KTyE43W6LRP6nEpIDabn6FYOIO7rQAkk2l8z5m5g x-originating-ip: [172.19.59.32] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 31 Oct 2011 20:35:12.0908 (UTC) FILETIME=[971B4CC0:01CC980C] X-Nokia-AV: Clean Cc: jari.arkko@piuha.net, mext@ietf.org Subject: Re: [MEXT] the future of the MEXT working group X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Oct 2011 20:35:17 -0000 Okay.. Then I would hope that the rechartering does not throw out "the baby with t= he bathwater" and keep MIP6/DSMIP6 related extensions and features still in= scope. -Raj -----Original Message----- From: ext Julien Laganier [mailto:julien.ietf@gmail.com]=20 Sent: Monday, October 31, 2011 3:33 PM To: Patil Basavaraj (Nokia-CIC/Dallas) Cc: jari.arkko@piuha.net; mext@ietf.org Subject: Re: [MEXT] the future of the MEXT working group Hi Raj, This is a rechartering of the WG. --julien On Mon, Oct 31, 2011 at 7:47 AM, wrote: > > > Hi Jari, > > > > A couple of quick questions: > > > > 1.=A0=A0=A0=A0=A0=A0 Is this a recharter of the MEXT WG or the formation = of a new=20 > WG to deal with DMM? If it is the latter I would be concerned that a=20 > WG is being formed without going through the IETF BoF process. I=20 > realize that DMM was in the scope of the MEXT WG. But proposed new=20 > charter pretty much throws everything else w.r.t MIP6/DSMIP6 out of this = new WG. > > 2.=A0=A0=A0=A0=A0=A0 There needs to be a WG and home for continued work w= .r.t=20 > improvements to MIP6/DSMIP6 protocol in terms of extensions,=20 > deployability improvements etc. The proposed charter does not consider th= is at all. > > > > -Basavaraj > > > > From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] On Behalf=20 > Of ext Jari Arkko > Sent: Friday, October 28, 2011 7:21 AM > To: mext@ietf.org > Subject: Re: [MEXT] the future of the MEXT working group > > > > And a follow-up on the charter. I'm describing a couple of different=20 > takes on what the new charter could be. Comments and alternative=20 > proposals are welcome. This is what the current charter says about DMM: > > > =A0 The working group will also work on operational considerations on > =A0 setting up Mobile IPv6 networks so that traffic is distributed > =A0 in an optimal way, for instance by using existing protocol=20 > mechanisms > =A0 to select the closest home agents for new clients. > > =A0 Oct 2011 - Submit I-D 'Operational considerations for distributed=20 > use of Mobile IPv6' for publication as Informational. > > Which is admittedly a bit short, but is also very concrete and=20 > achievable, if we work on it. I got another proposal from Hui Deng=20 > that extended this a bit, including going beyond mere operational conside= rations. > > > In the past decade a fair number of mobility protocols have been=20 > standardized. Although the protocols differ in terms of functions and=20 > associated message format, we can identify a few key common features: > presence of a centralized mobility anchor providing global=20 > reachability and an always-on experience extensions to optimize=20 > handover performance while users roam across wireless cells extensions=20 > to enable the use of heterogeneous wireless interfaces for multi-mode=20 > terminals (e.g. cellular phones) The presence of the centralized=20 > mobility anchor allows a mobile device to be reachable when it is not=20 > connected to its home domain. The anchor, among other tasks, ensures=20 > forwarding of packets destined to or sent from the mobile device. As=20 > such, most of the deployed architectures today have a small number of=20 > centralized anchors managing the traffic of millions of mobile=20 > subscribers. > > To optimize handovers for mobile users, the base protocols have been=20 > extended to efficiently handle packet forwarding between the previous=20 > and new points of attachment. These extensions are necessary when=20 > applications impose stringent requirements in terms of delay. Notions=20 > of localization and distribution of local agents have been introduced=20 > to reduce signalling overhead. Unfortunately today we witness=20 > difficulties in getting such protocols deployed, often leading to=20 > sub-optimal choices. Moreover, all the availability of multi-mode=20 > devices and the possibility to use several network interfaces=20 > simultaneously have motivated the development of more new protocol extens= ions. > > Mobile users are, more than ever, consuming Internet content, and=20 > impose new requirements on mobile core networks for data traffic=20 > delivery. When this traffic demand exceeds available capacity, service=20 > providers need to implement new strategies such as selective traffic=20 > offload (e.g. 3GPP work items LIPA/SIPTO) through alternative access=20 > networks (e.g. WLAN). Moreover, the localization of content providers=20 > closer to the Mobile/Fixed Internet Service Providers network requires=20 > taking into account local Content Delivery Networks (CDNs) while providin= g mobility services. > > As long as demand exceeds capacity, both offloading and CDN techniques=20 > could benefit from the development of more flat mobile architectures=20 > (i.e., fewer levels of routing hierarchy introduced into the data path=20 > by the mobility management system). This view is reinforced by the=20 > shift in users' traffic behaviour, aimed at increasing direct=20 > communications among peers in the same geographical area. The=20 > development of truly flat mobile architectures would result in=20 > anchoring the traffic closer to point of attachment of the user and=20 > overcoming the suboptimal routing issues of a centralized mobility scheme= . > > While deploying today's mobile networks, service providers face new=20 > challenges. More often than not, mobile devices remain attached to the=20 > same point of attachment, in which case specific IP mobility=20 > management support is not required for applications that launch and=20 > complete while connected to the same point of attachment. However, the=20 > mobility support has been designed to be always on and to maintain the=20 > context for each mobile subscriber as long as they are connected to=20 > the network. This can result in a waste of resources and ever-increasing = costs for the service provider. > Infrequent mobility and intelligence of many applications suggest that=20 > mobility can be provided dynamically, thus simplifying the context=20 > maintained in the different nodes of the mobile network. > > The proposed charter will address two complementary aspects of=20 > mobility management procedures: the distribution of mobility anchors=20 > to achieve a more flat design and the dynamic activation/deactivation=20 > of mobility protocol support as an enabler to distributed mobility=20 > management. The former has the goal of positioning mobility anchors=20 > (HA, LMA) closer to the user; ideally, these mobility anchors could be=20 > collocated with the first hop router. The latter, facilitated by the=20 > distribution of mobility anchors, aims at identifying when mobility=20 > must be activated and identifying sessions that do not impose mobility=20 > management -- thus reducing the amount of state information to be=20 > maintained in the various mobility anchors of the mobile network. The=20 > key idea is that dynamic mobility management relaxes some constraints=20 > while also repositioning mobility anchors; it avoids the establishment=20 > of non optimal tunnels between two anchors topologically distant. > > Considering the above, the working group will: > > Define the problem statement and associated requirements for=20 > distributed mobility management. This work aims at defining the=20 > problem space and identifies the key functional requirements. > > Produce a gap analysis mapping the above requirements against existing=20 > solutions. > > Give best practices for the deployment of existing mobility protocols=20 > in a distributed mobility management and describe limitations of each=20 > such approach. > > Describe extensions, if needed, to current mobility protocols for=20 > their application in distributed mobility architectures > > Comments? > > Jari > > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext > > From jari.arkko@piuha.net Mon Oct 31 13:44:58 2011 Return-Path: X-Original-To: mext@ietfa.amsl.com Delivered-To: mext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D6C1211E8215 for ; Mon, 31 Oct 2011 13:44:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.442 X-Spam-Level: X-Spam-Status: No, score=-102.442 tagged_above=-999 required=5 tests=[AWL=-0.158, BAYES_00=-2.599, SARE_MILLIONSOF=0.315, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CaDjz7W82m2i for ; Mon, 31 Oct 2011 13:44:58 -0700 (PDT) Received: from p130.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by ietfa.amsl.com (Postfix) with ESMTP id 8AC3411E8192 for ; Mon, 31 Oct 2011 13:44:57 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id D7EAC2CC45; Mon, 31 Oct 2011 22:44:56 +0200 (EET) X-Virus-Scanned: amavisd-new at piuha.net Received: from p130.piuha.net ([127.0.0.1]) by localhost (p130.piuha.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uGTT4jfspM2r; Mon, 31 Oct 2011 22:44:55 +0200 (EET) Received: from [127.0.0.1] (p130.piuha.net [IPv6:2001:14b8:400::130]) by p130.piuha.net (Postfix) with ESMTP id 377932CC31; Mon, 31 Oct 2011 22:44:55 +0200 (EET) Message-ID: <4EAF08C6.6010905@piuha.net> Date: Mon, 31 Oct 2011 22:44:54 +0200 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: Basavaraj.Patil@nokia.com References: <4EAA9B4A.3020208@piuha.net> <4EAA9E34.2080903@piuha.net> <21E7D9BD69CC7241AAE00F4EA183B719014CE67F@008-AM1MPN1-071.mgdnok.nokia.com> <21E7D9BD69CC7241AAE00F4EA183B719014CEC85@008-AM1MPN1-071.mgdnok.nokia.com> In-Reply-To: <21E7D9BD69CC7241AAE00F4EA183B719014CEC85@008-AM1MPN1-071.mgdnok.nokia.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: julien.ietf@gmail.com, mext@ietf.org Subject: Re: [MEXT] the future of the MEXT working group X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Oct 2011 20:44:59 -0000 Basavaraj, It is a recharter (and a rename). We are not considering taking on significant amount of new work (mostly just removing material from the charter), so I do not think a BOF is needed. There has been little need to do work on the other extensions, and slow progress with the specifications that do exist. I think we completed the work that was easy to do and had demand. I think we should leave the rest behind. As noted in the other e-mails, I can AD sponsors docs outside the WGs directly to RFC. If there's something big that requires WG discussion, we can always create new working groups later. For instance, if after some time the various security alternates get enough traction, we could consider creating a working group to standardize one. Jari On 31.10.2011 22:35, Basavaraj.Patil@nokia.com wrote: > Okay.. > Then I would hope that the rechartering does not throw out "the baby with the bathwater" and keep MIP6/DSMIP6 related extensions and features still in scope. > > -Raj > > -----Original Message----- > From: ext Julien Laganier [mailto:julien.ietf@gmail.com] > Sent: Monday, October 31, 2011 3:33 PM > To: Patil Basavaraj (Nokia-CIC/Dallas) > Cc: jari.arkko@piuha.net; mext@ietf.org > Subject: Re: [MEXT] the future of the MEXT working group > > Hi Raj, > > This is a rechartering of the WG. > > --julien > > On Mon, Oct 31, 2011 at 7:47 AM, wrote: >> >> Hi Jari, >> >> >> >> A couple of quick questions: >> >> >> >> 1. Is this a recharter of the MEXT WG or the formation of a new >> WG to deal with DMM? If it is the latter I would be concerned that a >> WG is being formed without going through the IETF BoF process. I >> realize that DMM was in the scope of the MEXT WG. But proposed new >> charter pretty much throws everything else w.r.t MIP6/DSMIP6 out of this new WG. >> >> 2. There needs to be a WG and home for continued work w.r.t >> improvements to MIP6/DSMIP6 protocol in terms of extensions, >> deployability improvements etc. The proposed charter does not consider this at all. >> >> >> >> -Basavaraj >> >> >> >> From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] On Behalf >> Of ext Jari Arkko >> Sent: Friday, October 28, 2011 7:21 AM >> To: mext@ietf.org >> Subject: Re: [MEXT] the future of the MEXT working group >> >> >> >> And a follow-up on the charter. I'm describing a couple of different >> takes on what the new charter could be. Comments and alternative >> proposals are welcome. This is what the current charter says about DMM: >> >> >> The working group will also work on operational considerations on >> setting up Mobile IPv6 networks so that traffic is distributed >> in an optimal way, for instance by using existing protocol >> mechanisms >> to select the closest home agents for new clients. >> >> Oct 2011 - Submit I-D 'Operational considerations for distributed >> use of Mobile IPv6' for publication as Informational. >> >> Which is admittedly a bit short, but is also very concrete and >> achievable, if we work on it. I got another proposal from Hui Deng >> that extended this a bit, including going beyond mere operational considerations. >> >> >> In the past decade a fair number of mobility protocols have been >> standardized. Although the protocols differ in terms of functions and >> associated message format, we can identify a few key common features: >> presence of a centralized mobility anchor providing global >> reachability and an always-on experience extensions to optimize >> handover performance while users roam across wireless cells extensions >> to enable the use of heterogeneous wireless interfaces for multi-mode >> terminals (e.g. cellular phones) The presence of the centralized >> mobility anchor allows a mobile device to be reachable when it is not >> connected to its home domain. The anchor, among other tasks, ensures >> forwarding of packets destined to or sent from the mobile device. As >> such, most of the deployed architectures today have a small number of >> centralized anchors managing the traffic of millions of mobile >> subscribers. >> >> To optimize handovers for mobile users, the base protocols have been >> extended to efficiently handle packet forwarding between the previous >> and new points of attachment. These extensions are necessary when >> applications impose stringent requirements in terms of delay. Notions >> of localization and distribution of local agents have been introduced >> to reduce signalling overhead. Unfortunately today we witness >> difficulties in getting such protocols deployed, often leading to >> sub-optimal choices. Moreover, all the availability of multi-mode >> devices and the possibility to use several network interfaces >> simultaneously have motivated the development of more new protocol extensions. >> >> Mobile users are, more than ever, consuming Internet content, and >> impose new requirements on mobile core networks for data traffic >> delivery. When this traffic demand exceeds available capacity, service >> providers need to implement new strategies such as selective traffic >> offload (e.g. 3GPP work items LIPA/SIPTO) through alternative access >> networks (e.g. WLAN). Moreover, the localization of content providers >> closer to the Mobile/Fixed Internet Service Providers network requires >> taking into account local Content Delivery Networks (CDNs) while providing mobility services. >> >> As long as demand exceeds capacity, both offloading and CDN techniques >> could benefit from the development of more flat mobile architectures >> (i.e., fewer levels of routing hierarchy introduced into the data path >> by the mobility management system). This view is reinforced by the >> shift in users' traffic behaviour, aimed at increasing direct >> communications among peers in the same geographical area. The >> development of truly flat mobile architectures would result in >> anchoring the traffic closer to point of attachment of the user and >> overcoming the suboptimal routing issues of a centralized mobility scheme. >> >> While deploying today's mobile networks, service providers face new >> challenges. More often than not, mobile devices remain attached to the >> same point of attachment, in which case specific IP mobility >> management support is not required for applications that launch and >> complete while connected to the same point of attachment. However, the >> mobility support has been designed to be always on and to maintain the >> context for each mobile subscriber as long as they are connected to >> the network. This can result in a waste of resources and ever-increasing costs for the service provider. >> Infrequent mobility and intelligence of many applications suggest that >> mobility can be provided dynamically, thus simplifying the context >> maintained in the different nodes of the mobile network. >> >> The proposed charter will address two complementary aspects of >> mobility management procedures: the distribution of mobility anchors >> to achieve a more flat design and the dynamic activation/deactivation >> of mobility protocol support as an enabler to distributed mobility >> management. The former has the goal of positioning mobility anchors >> (HA, LMA) closer to the user; ideally, these mobility anchors could be >> collocated with the first hop router. The latter, facilitated by the >> distribution of mobility anchors, aims at identifying when mobility >> must be activated and identifying sessions that do not impose mobility >> management -- thus reducing the amount of state information to be >> maintained in the various mobility anchors of the mobile network. The >> key idea is that dynamic mobility management relaxes some constraints >> while also repositioning mobility anchors; it avoids the establishment >> of non optimal tunnels between two anchors topologically distant. >> >> Considering the above, the working group will: >> >> Define the problem statement and associated requirements for >> distributed mobility management. This work aims at defining the >> problem space and identifies the key functional requirements. >> >> Produce a gap analysis mapping the above requirements against existing >> solutions. >> >> Give best practices for the deployment of existing mobility protocols >> in a distributed mobility management and describe limitations of each >> such approach. >> >> Describe extensions, if needed, to current mobility protocols for >> their application in distributed mobility architectures >> >> Comments? >> >> Jari >> >> _______________________________________________ >> MEXT mailing list >> MEXT@ietf.org >> https://www.ietf.org/mailman/listinfo/mext >> >> > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext > From Basavaraj.Patil@nokia.com Mon Oct 31 13:55:58 2011 Return-Path: X-Original-To: mext@ietfa.amsl.com Delivered-To: mext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7EA4211E8273 for ; Mon, 31 Oct 2011 13:55:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.514 X-Spam-Level: X-Spam-Status: No, score=-102.514 tagged_above=-999 required=5 tests=[AWL=-0.230, BAYES_00=-2.599, SARE_MILLIONSOF=0.315, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Bvv1AW3qOUKp for ; Mon, 31 Oct 2011 13:55:57 -0700 (PDT) Received: from mgw-sa02.nokia.com (smtp.nokia.com [147.243.1.48]) by ietfa.amsl.com (Postfix) with ESMTP id 5036211E818F for ; Mon, 31 Oct 2011 13:55:57 -0700 (PDT) Received: from vaebh104.NOE.Nokia.com (vaebh104.europe.nokia.com [10.160.244.30]) by mgw-sa02.nokia.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id p9VKtjWP002771; Mon, 31 Oct 2011 22:55:50 +0200 Received: from smtp.mgd.nokia.com ([65.54.30.7]) by vaebh104.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Mon, 31 Oct 2011 22:55:43 +0200 Received: from 008-AM1MMR1-003.mgdnok.nokia.com (65.54.30.58) by NOK-AM1MHUB-03.mgdnok.nokia.com (65.54.30.7) with Microsoft SMTP Server (TLS) id 8.2.255.0; Mon, 31 Oct 2011 21:54:34 +0100 Received: from 008-AM1MPN1-071.mgdnok.nokia.com ([169.254.1.235]) by 008-AM1MMR1-003.mgdnok.nokia.com ([65.54.30.58]) with mapi id 14.01.0339.002; Mon, 31 Oct 2011 21:54:23 +0100 From: To: Thread-Topic: [MEXT] the future of the MEXT working group Thread-Index: AQHMlWpmfRWG/cEPIEyACm1+ri2dNZWRi8gAgADD+FCABI0+AIAAEQUw///yRwD//67RAA== Date: Mon, 31 Oct 2011 20:54:23 +0000 Message-ID: In-Reply-To: <4EAF08C6.6010905@piuha.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.13.0.110805 x-originating-ip: [172.19.59.135] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 31 Oct 2011 20:55:43.0681 (UTC) FILETIME=[74B45B10:01CC980F] X-Nokia-AV: Clean Cc: julien.ietf@gmail.com, mext@ietf.org Subject: Re: [MEXT] the future of the MEXT working group X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Oct 2011 20:55:58 -0000 Thanks Jari. Sounds reasonable. Will provide additional comments on the proposed charter separately. -Basavaraj On 10/31/11 3:44 PM, "ext Jari Arkko" wrote: >Basavaraj, > >It is a recharter (and a rename). We are not considering taking on >significant amount of new work (mostly just removing material from the >charter), so I do not think a BOF is needed. > >There has been little need to do work on the other extensions, and slow >progress with the specifications that do exist. I think we completed the >work that was easy to do and had demand. I think we should leave the rest >behind. As noted in the other e-mails, I can AD sponsors docs outside the >WGs directly to RFC. If there's something big that requires WG >discussion, we can always create new working groups later. For instance, >if after some time the various security alternates get enough traction, >we could consider creating a working group to standardize one. > >Jari > >On 31.10.2011 22:35, Basavaraj.Patil@nokia.com wrote: >> Okay.. >> Then I would hope that the rechartering does not throw out "the baby >>with the bathwater" and keep MIP6/DSMIP6 related extensions and features >>still in scope. >> >> -Raj >> >> -----Original Message----- >> From: ext Julien Laganier [mailto:julien.ietf@gmail.com] >> Sent: Monday, October 31, 2011 3:33 PM >> To: Patil Basavaraj (Nokia-CIC/Dallas) >> Cc: jari.arkko@piuha.net; mext@ietf.org >> Subject: Re: [MEXT] the future of the MEXT working group >> >> Hi Raj, >> >> This is a rechartering of the WG. >> >> --julien >> >> On Mon, Oct 31, 2011 at 7:47 AM, wrote: >>> >>> Hi Jari, >>> >>> >>> >>> A couple of quick questions: >>> >>> >>> >>> 1. Is this a recharter of the MEXT WG or the formation of a new >>> WG to deal with DMM? If it is the latter I would be concerned that a >>> WG is being formed without going through the IETF BoF process. I >>> realize that DMM was in the scope of the MEXT WG. But proposed new >>> charter pretty much throws everything else w.r.t MIP6/DSMIP6 out of >>>this new WG. >>> >>> 2. There needs to be a WG and home for continued work w.r.t >>> improvements to MIP6/DSMIP6 protocol in terms of extensions, >>> deployability improvements etc. The proposed charter does not consider >>>this at all. >>> >>> >>> >>> -Basavaraj >>> >>> >>> >>> From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] On Behalf >>> Of ext Jari Arkko >>> Sent: Friday, October 28, 2011 7:21 AM >>> To: mext@ietf.org >>> Subject: Re: [MEXT] the future of the MEXT working group >>> >>> >>> >>> And a follow-up on the charter. I'm describing a couple of different >>> takes on what the new charter could be. Comments and alternative >>> proposals are welcome. This is what the current charter says about DMM: >>> >>> >>> The working group will also work on operational considerations on >>> setting up Mobile IPv6 networks so that traffic is distributed >>> in an optimal way, for instance by using existing protocol >>> mechanisms >>> to select the closest home agents for new clients. >>> >>> Oct 2011 - Submit I-D 'Operational considerations for distributed >>> use of Mobile IPv6' for publication as Informational. >>> >>> Which is admittedly a bit short, but is also very concrete and >>> achievable, if we work on it. I got another proposal from Hui Deng >>> that extended this a bit, including going beyond mere operational >>>considerations. >>> >>> >>> In the past decade a fair number of mobility protocols have been >>> standardized. Although the protocols differ in terms of functions and >>> associated message format, we can identify a few key common features: >>> presence of a centralized mobility anchor providing global >>> reachability and an always-on experience extensions to optimize >>> handover performance while users roam across wireless cells extensions >>> to enable the use of heterogeneous wireless interfaces for multi-mode >>> terminals (e.g. cellular phones) The presence of the centralized >>> mobility anchor allows a mobile device to be reachable when it is not >>> connected to its home domain. The anchor, among other tasks, ensures >>> forwarding of packets destined to or sent from the mobile device. As >>> such, most of the deployed architectures today have a small number of >>> centralized anchors managing the traffic of millions of mobile >>> subscribers. >>> >>> To optimize handovers for mobile users, the base protocols have been >>> extended to efficiently handle packet forwarding between the previous >>> and new points of attachment. These extensions are necessary when >>> applications impose stringent requirements in terms of delay. Notions >>> of localization and distribution of local agents have been introduced >>> to reduce signalling overhead. Unfortunately today we witness >>> difficulties in getting such protocols deployed, often leading to >>> sub-optimal choices. Moreover, all the availability of multi-mode >>> devices and the possibility to use several network interfaces >>> simultaneously have motivated the development of more new protocol >>>extensions. >>> >>> Mobile users are, more than ever, consuming Internet content, and >>> impose new requirements on mobile core networks for data traffic >>> delivery. When this traffic demand exceeds available capacity, service >>> providers need to implement new strategies such as selective traffic >>> offload (e.g. 3GPP work items LIPA/SIPTO) through alternative access >>> networks (e.g. WLAN). Moreover, the localization of content providers >>> closer to the Mobile/Fixed Internet Service Providers network requires >>> taking into account local Content Delivery Networks (CDNs) while >>>providing mobility services. >>> >>> As long as demand exceeds capacity, both offloading and CDN techniques >>> could benefit from the development of more flat mobile architectures >>> (i.e., fewer levels of routing hierarchy introduced into the data path >>> by the mobility management system). This view is reinforced by the >>> shift in users' traffic behaviour, aimed at increasing direct >>> communications among peers in the same geographical area. The >>> development of truly flat mobile architectures would result in >>> anchoring the traffic closer to point of attachment of the user and >>> overcoming the suboptimal routing issues of a centralized mobility >>>scheme. >>> >>> While deploying today's mobile networks, service providers face new >>> challenges. More often than not, mobile devices remain attached to the >>> same point of attachment, in which case specific IP mobility >>> management support is not required for applications that launch and >>> complete while connected to the same point of attachment. However, the >>> mobility support has been designed to be always on and to maintain the >>> context for each mobile subscriber as long as they are connected to >>> the network. This can result in a waste of resources and >>>ever-increasing costs for the service provider. >>> Infrequent mobility and intelligence of many applications suggest that >>> mobility can be provided dynamically, thus simplifying the context >>> maintained in the different nodes of the mobile network. >>> >>> The proposed charter will address two complementary aspects of >>> mobility management procedures: the distribution of mobility anchors >>> to achieve a more flat design and the dynamic activation/deactivation >>> of mobility protocol support as an enabler to distributed mobility >>> management. The former has the goal of positioning mobility anchors >>> (HA, LMA) closer to the user; ideally, these mobility anchors could be >>> collocated with the first hop router. The latter, facilitated by the >>> distribution of mobility anchors, aims at identifying when mobility >>> must be activated and identifying sessions that do not impose mobility >>> management -- thus reducing the amount of state information to be >>> maintained in the various mobility anchors of the mobile network. The >>> key idea is that dynamic mobility management relaxes some constraints >>> while also repositioning mobility anchors; it avoids the establishment >>> of non optimal tunnels between two anchors topologically distant. >>> >>> Considering the above, the working group will: >>> >>> Define the problem statement and associated requirements for >>> distributed mobility management. This work aims at defining the >>> problem space and identifies the key functional requirements. >>> >>> Produce a gap analysis mapping the above requirements against existing >>> solutions. >>> >>> Give best practices for the deployment of existing mobility protocols >>> in a distributed mobility management and describe limitations of each >>> such approach. >>> >>> Describe extensions, if needed, to current mobility protocols for >>> their application in distributed mobility architectures >>> >>> Comments? >>> >>> Jari >>> >>> _______________________________________________ >>> MEXT mailing list >>> MEXT@ietf.org >>> https://www.ietf.org/mailman/listinfo/mext >>> >>> >> _______________________________________________ >> MEXT mailing list >> MEXT@ietf.org >> https://www.ietf.org/mailman/listinfo/mext >> > >_______________________________________________ >MEXT mailing list >MEXT@ietf.org >https://www.ietf.org/mailman/listinfo/mext From sarikaya2012@gmail.com Mon Oct 31 14:33:55 2011 Return-Path: X-Original-To: mext@ietfa.amsl.com Delivered-To: mext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A06711F0C9C for ; Mon, 31 Oct 2011 14:33:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.606 X-Spam-Level: X-Spam-Status: No, score=-2.606 tagged_above=-999 required=5 tests=[AWL=-0.674, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, SARE_HTML_USL_OBFU=1.666] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZVT3YQIKCMAE for ; Mon, 31 Oct 2011 14:33:54 -0700 (PDT) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id BF2EB1F0C8B for ; Mon, 31 Oct 2011 14:33:54 -0700 (PDT) Received: by gyh20 with SMTP id 20so7613291gyh.31 for ; Mon, 31 Oct 2011 14:33:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=+R0IkLieEYru16BWh/yzNGoiFSPCU3lCOiS8zEXDZ2s=; b=OWUKFZxnMm1NaMoNI3wzHvOdumCfdyHIAvvb81NCH4ix3FEUAiKUQK/f6E0ft88x2z HyBt09qM1Ai7x/ICSU2PJ1S7PPOfOHkREAGxe+29XjXPI0Lz/QE1+Cl69mLFzBSSAnxB I3yQYgMYXDW8Z619tZsKq6Qt+BIJqrHu8JUQc= MIME-Version: 1.0 Received: by 10.236.154.137 with SMTP id h9mr19114917yhk.26.1320096834372; Mon, 31 Oct 2011 14:33:54 -0700 (PDT) Received: by 10.236.110.39 with HTTP; Mon, 31 Oct 2011 14:33:54 -0700 (PDT) In-Reply-To: <4EAEFE03.3010900@piuha.net> References: <4EAA9B4A.3020208@piuha.net> <4EAEFE03.3010900@piuha.net> Date: Mon, 31 Oct 2011 16:33:54 -0500 Message-ID: From: Behcet Sarikaya To: Jari Arkko Content-Type: multipart/alternative; boundary=20cf303b4427e1c50304b09efe25 Cc: "jouni.korhonen@nsn.com" , "mext@ietf.org" Subject: Re: [MEXT] the future of the MEXT working group X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: sarikaya@ieee.org List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Oct 2011 21:33:55 -0000 --20cf303b4427e1c50304b09efe25 Content-Type: text/plain; charset=ISO-8859-1 Hi Jari, draft-xia-mext-hioptv4-03.txt is for the charter item: Sep 2011 - Submit I-D 'Home agent discovery in IPv4-only networks via DHCP' to IESG for publication as Proposed Standard. This is the only draft offered as a solution for this charter item. The draft has received comments by DHCP experts like Ted Lemon and Tomek Mrugalski and revised accordingly. I think that it is ready for publication. What should we do? Regards, Behcet On Mon, Oct 31, 2011 at 2:58 PM, Jari Arkko wrote: > Did it successfully complete WGLC? With sufficient support for taking the > document forward? If yes, the chairs can either send it immediately to me > as a WG output. > > Or I can AD sponsor it later. The offer to AD sponsor is also valid for > other documents. They need to be in reasonable shape, naturally. > > Jari > > > On 31.10.2011 19:08, Ryuji Wakikawa wrote: > >> Jari >> >> Thanks for this update. I want to clarify plan of the existing activity, >> HA reliability doc, in MEXT. >> This document completed WGLC and went nowhere after all. >> It supposes to be proposed standard RFC. >> Do you want to finish this work with AD sponsor? or just trash it? >> >> thanks >> ryuji >> >> On 2011/10/28, at 5:08, Jari Arkko wrote: >> >> All, >>> >>> We are making some changes to the working group. While we have >>> successfully published a large number of specifications in recent years, >>> recently it has been difficult to make progress in the group. The chairs >>> and ADs have looked at the situation and we believe we need a new focus and >>> a bit of new organization as well. We are terminating the working group and >>> moving the one remaining active work item to a new working group, the "DMM" >>> working group. Here's what is going to happen: >>> >>> o Jouni Korhonen and Julien Laganier will become the chairs of the >>> group. >>> >>> o The group will meet in Taipei (there is a MEXT slot in the agenda). >>> >>> o The charter of the group will be changed to focus only on the >>> distributed mobility effort. We should discuss the details of this charter >>> change both on the list and in the meeting. The meeting agenda should >>> reserve some time both for technical discussions as well as the charter >>> discussion. >>> >>> o Once the discussion on the list and in the meeting has finished, we >>> will rename the group to "DMM" and put the new charter in effect. >>> >>> o If there are any other specifications that people would like to >>> publish beyond the distributed mobility work, we can offer to AD sponsor >>> them to RFCs outside the new working group. If there is some significant >>> new activity, we can create new working groups for that. >>> >>> Comments and feedback and/or alternate suggestions on this plan are >>> welcome. >>> >>> We would like to thank Marcelo for your many years of service in MEXT. >>> We could not have completed all the work we did without your energy and >>> push for high quality results. We would also like to thank Jouni for taking >>> on this new challenge, and Julien for continuing the work in this space. >>> >>> Jari and Ralph >>> >>> ______________________________**_________________ >>> MEXT mailing list >>> MEXT@ietf.org >>> https://www.ietf.org/mailman/**listinfo/mext >>> >> >> > ______________________________**_________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/**listinfo/mext > --20cf303b4427e1c50304b09efe25 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Jari,

draft-xia-mext-hioptv4-03.txt is = for the charter item:

Sep 2011 - Submit I-D 'Home agent discover= y in IPv4-only networks via DHCP' to IESG for publication as Proposed S= tandard.

This is the only draft offered as a solution for this charter item.
=
The draft has received comments by DHCP experts like Ted Lemon and Tome= k Mrugalski and revised accordingly.

I think that it is ready for pu= blication.

What should we do?

Regards,

Behcet

On Mon, Oct 31, 2011 at 2:58 PM, Jari Arkko &= lt;jari.arkko@piuha.net> wrote:
Did it successfully complete WGLC? With suf= ficient support for taking the document forward? If yes, the chairs can eit= her send it immediately to me as a WG output.

Or I can AD sponsor it later. The offer to AD sponsor is also valid for oth= er documents. They need to be in reasonable shape, naturally.

Jari


On 31.10.2011 19:08, Ryuji Wakikawa wrote:
Jari

Thanks for this update. =A0I want to clarify plan of the existing activity,= HA reliability doc, =A0in MEXT.
This document completed WGLC and went nowhere after all.
It supposes to be proposed standard RFC.
Do you want to finish this work with AD sponsor? or just trash it?

thanks
ryuji

On 2011/10/28, at 5:08, Jari Arkko wrote:

All,

We are making some changes to the working group. While we have successfully= published a large number of specifications in recent years, recently it ha= s been difficult to make progress in the group. The chairs and ADs have loo= ked at the situation and we believe we need a new focus and a bit of new or= ganization as well. We are terminating the working group and moving the one= remaining active work item to a new working group, the "DMM" wor= king group. Here's what is going to happen:

o =A0Jouni Korhonen and Julien Laganier will become the chairs of the group= .

o =A0The group will meet in Taipei (there is a MEXT slot in the agenda).
o =A0The charter of the group will be changed to focus only on the distribu= ted mobility effort. We should discuss the details of this charter change b= oth on the list and in the meeting. The meeting agenda should reserve some = time both for technical discussions as well as the charter discussion.

o =A0Once the discussion on the list and in the meeting has finished, we wi= ll rename the group to "DMM" and put the new charter in effect.
o =A0If there are any other specifications that people would like to publis= h beyond the distributed mobility work, we can offer to AD sponsor them to = RFCs outside the new working group. If there is some significant new activi= ty, we can create new working groups for that.

Comments and feedback and/or alternate suggestions on this plan are welcome= .

We would like to thank Marcelo for your many years of service in MEXT. We c= ould not have completed all the work we did without your energy and push fo= r high quality results. We would also like to thank Jouni for taking on thi= s new challenge, and Julien for continuing the work in this space.

Jari and Ralph

_______________________________________________
MEXT mailing list
MEXT@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/mext


_______________________________________________
MEXT mailing list
MEXT@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/mext

--20cf303b4427e1c50304b09efe25-- From charles.perkins@earthlink.net Mon Oct 31 15:11:18 2011 Return-Path: X-Original-To: mext@ietfa.amsl.com Delivered-To: mext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB1F911E80D7 for ; Mon, 31 Oct 2011 15:11:18 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LyhO126rLOA5 for ; Mon, 31 Oct 2011 15:11:18 -0700 (PDT) Received: from elasmtp-mealy.atl.sa.earthlink.net (elasmtp-mealy.atl.sa.earthlink.net [209.86.89.69]) by ietfa.amsl.com (Postfix) with ESMTP id D402711E81F1 for ; Mon, 31 Oct 2011 15:11:17 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=AFYSASJTVEbnf7IEH3xHBugc91oCA0syTwLcLiAB/PdWPGxgAx27iD2uu4x6538r; h=Received:Message-ID:Date:From:Organization:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding:X-ELNK-Trace:X-Originating-IP; Received: from [138.111.58.2] (helo=[172.17.96.136]) by elasmtp-mealy.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1RL04a-0003qr-AO; Mon, 31 Oct 2011 18:11:16 -0400 Message-ID: <4EAF1D00.6040801@earthlink.net> Date: Mon, 31 Oct 2011 15:11:12 -0700 From: "Charles E. Perkins" Organization: Wichorus Inc. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: Behcet Sarikaya References: <4E39847B.7080803@earthlink.net> <1313079931.10204.YahooMailNeo@web111414.mail.gq1.yahoo.com> In-Reply-To: <1313079931.10204.YahooMailNeo@web111414.mail.gq1.yahoo.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956d5d4673fe7faad86cc2a53e4ff412f3d29d243410b00a9c9350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 138.111.58.2 Cc: Behcet Sarikaya , mext Subject: Re: [MEXT] draft-perkins-mext-hatunaddr-01 X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Oct 2011 22:11:19 -0000 Hello Behcet, The Alternate Home Agent Tunnel Address is what the mobile node would use as the _home agent's_ IP address for the tunnel, when the mobile node is exchanging data to/from a correspondent node through the home agent. For control signaling (Binding Update, etc.) the mobile node still would use the "regular" home agent address. Regards, Charlie P. On 8/11/2011 9:25 AM, Behcet Sarikaya wrote: > Hi Charlie, > I took a look at this draft. > Regarding control plane data plane separation, what is the difference between > > Alternate Home Agent Tunnel Address > that you defined and > > > Alternate Care-of Address > > > defined in RFC 6275? > > I remember there was some discussion in the past by Vijay, et al. for a similar use? Maybe you remember the details and you can shed some light into this? > > Regards, > > Behcet >> >> Hello folks, >> >> I have revised and resubmitted my earlier draft proposing >> a split between the control and data plane addresses of >> the home agent. For some reason, the Internet Draft >> submission process seems to have hung when I made the >> formal submission, and I don't know when I will get the >> verification email. In the meantime, here is a URL: >> >> http://www.psg.com/~charliep/txt/ietf81/draft-perkins-mext-hatunaddr-01.txt >> >> I also added text for the same idea with Mobile IPv4. >> >> Regards, >> Charlie P. >> >> _______________________________________________ >> MEXT mailing list >> MEXT@ietf.org >> https://www.ietf.org/mailman/listinfo/mext >> > From charles.perkins@earthlink.net Mon Oct 31 15:16:31 2011 Return-Path: X-Original-To: mext@ietfa.amsl.com Delivered-To: mext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF7061F0CDD for ; Mon, 31 Oct 2011 15:16:31 -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=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5zpiIR9KKc5j for ; Mon, 31 Oct 2011 15:16:31 -0700 (PDT) Received: from elasmtp-mealy.atl.sa.earthlink.net (elasmtp-mealy.atl.sa.earthlink.net [209.86.89.69]) by ietfa.amsl.com (Postfix) with ESMTP id 112C01F0CB3 for ; Mon, 31 Oct 2011 15:16:31 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=mArDMxUfERx+UOkW5bJ8Vrg472EVSu8YemSyN2g/U273BD1Sor3pY8lgeslRDRqf; h=Received:Message-ID:Date:From:Organization:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding:X-ELNK-Trace:X-Originating-IP; Received: from [138.111.58.2] (helo=[172.17.96.136]) by elasmtp-mealy.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1RL09c-0000Uj-Qx; Mon, 31 Oct 2011 18:16:29 -0400 Message-ID: <4EAF1E39.3020209@earthlink.net> Date: Mon, 31 Oct 2011 15:16:25 -0700 From: "Charles E. Perkins" Organization: Wichorus Inc. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: charliep@computer.org References: <20110803185832.21283.61262.idtracker@ietfa.amsl.com><4E399F6E.8090508@computer.org><75B8624B-6C94-4B7F-9487-DCF0E06B5256@us.toyota-itc.com> <4EAB1A93.8050605@computer.org> In-Reply-To: <4EAB1A93.8050605@computer.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956d5d4673fe7faad8694315bf17ce129ffaf98d2718731a7d1350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 138.111.58.2 Cc: mext Subject: Re: [MEXT] New Version Notification fordraft-perkins-mext-hatunaddr-01.txt X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Oct 2011 22:16:32 -0000 Hello again Romain, I didn't have time to do the specification for any new extension for the suggested options revised from RFC 3957. I'll try to do it later this week, but the result can't be officially submitted until I get to the IETF. Anyway, traffic to/from the mobile node <--> home agent doesn't always have to be protected, especially looking at the relative proportion of data traffic today that is sent via IPsec. It seems to me that the problem is important, and must be solved, but not a showstopper. Regards, Charlie P. On 10/28/2011 2:11 PM, Charles E. Perkins wrote: > Hello Romain, > > Thank you for reminding me about this point. It had been > raised previously during some related discussions for DMM > late last year, and I plainly forgot to fill in any details > about the problem. > > After looking over RFC 3957, I think the most efficient way > towards solution will be to define a new extension similar > to the Generalized MN-HA Key Generation Nonce Request and > Generalized MN-HA Key Generation Nonce Reply extensions. > It's not a perfect fit, but it's pretty close. If there is > any interest for an IPv4-based solution, I could easily > write up a new subtype for the RFC 3957 (IPv4) extensions. > > The formula for calculating the key in Section 5 needs to be > updated, perhaps to the following: > key = HMAC-SHA1 (HA-key, > {Key Generation Nonce || > mobile node identifier || > HA-D IPv6_address}) > > A similar formula would apply for any specification > in which the key nonce was generated by AAA instead of > the [control-plane] Home Agent [HA-C]. > > The manner in which the HA-D get the corresponding > configuration information doesn't have to be specified > in the ...mext-hatunaddr... draft. > > I'll try to get an updated draft out before the draft > deadline on Monday. Thanks for your comment. While > mostly straightforward, the update will take a pretty > good bit of carefully written text. > > Regards, > Charlie P. > > > On 8/4/2011 11:39 AM, Romain KUNTZ wrote: >> Hello Charlie, >> >> If the MN has to tunnel data to a different HA than the one to which >> it sends the BU, then it also needs an IPsec SA with that HA. How >> would the MN create such SA as it does not know in advance what HA it >> may use for tunneling? My guess is that the MN is supposed to trust >> the address received in the option and create the SA upon reception of >> the option. Similarly, all of the HA tunneling box would also need to >> be configured with the corresponding SA. Some considerations about >> that may be needed in the draft. >> >> Regards, >> romain >> >> >> On Aug 3, 2011, at 12:20, Charles E. Perkins wrote: >> >>> >>> Hello folks, >>> >>> My draft has now made it through the submission process. >>> Please excuse the repeat notification... >>> >>> Comments will be appreciated. >>> >>> Regards, >>> Charlie P. >>> >>> >>> -------- Original Message -------- >>> Subject: New Version Notification for >>> draft-perkins-mext-hatunaddr-01.txt >>> Date: Wed, 03 Aug 2011 11:58:32 -0700 >>> From: >>> To: >>> CC: >>> >>> A new version of I-D, draft-perkins-mext-hatunaddr-01.txt has been >>> successfully submitted by Charles Perkins and posted to the IETF >>> repository. >>> >>> Filename: draft-perkins-mext-hatunaddr >>> Revision: 01 >>> Title: Alternate Tunnel Source Address for Home Agent >>> Creation date: 2011-08-03 >>> WG ID: Individual Submission >>> Number of pages: 10 >>> >>> Abstract: >>> Widely deployed mobility management systems for wireless >>> communications have isolated the path for forwarding data from the >>> control plane signaling for mobility management. To realize this >>> requirement with Mobile IP requires that the control functions of the >>> home agent be addressable at a different IP address than the source >>> IP address of the tunnel between the home agent and mobile node. >>> Similar considerations hold for mobility anchors implementing >>> Hierarchical Mobile IP or PMIP. >>> >>> >>> >>> >>> The IETF Secretariat >>> >>> _______________________________________________ >>> MEXT mailing list >>> MEXT@ietf.org >>> https://www.ietf.org/mailman/listinfo/mext >> >> > > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext > From h.anthony.chan@huawei.com Mon Oct 31 15:57:42 2011 Return-Path: X-Original-To: mext@ietfa.amsl.com Delivered-To: mext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 64A3611E835B for ; Mon, 31 Oct 2011 15:57:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rH9RitNjBQsZ for ; Mon, 31 Oct 2011 15:57:40 -0700 (PDT) Received: from szxga01-in.huawei.com (szxga01-in.huawei.com [119.145.14.64]) by ietfa.amsl.com (Postfix) with ESMTP id 88A1911E8359 for ; Mon, 31 Oct 2011 15:57:40 -0700 (PDT) Received: from huawei.com (szxga05-in [172.24.2.49]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LTY0095HD3V9T@szxga05-in.huawei.com> for mext@ietf.org; Tue, 01 Nov 2011 06:57:31 +0800 (CST) Received: from szxrg01-dlp.huawei.com ([172.24.2.119]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LTY00KF0D3U8J@szxga05-in.huawei.com> for mext@ietf.org; Tue, 01 Nov 2011 06:57:31 +0800 (CST) Received: from szxeml208-edg.china.huawei.com ([172.24.2.119]) by szxrg01-dlp.huawei.com (MOS 4.1.9-GA) with ESMTP id AEV31415; Tue, 01 Nov 2011 06:57:29 +0800 Received: from SZXEML403-HUB.china.huawei.com (10.82.67.35) by szxeml208-edg.china.huawei.com (172.24.2.60) with Microsoft SMTP Server (TLS) id 14.1.270.1; Tue, 01 Nov 2011 06:57:26 +0800 Received: from SZXEML505-MBS.china.huawei.com ([169.254.2.127]) by szxeml403-hub.china.huawei.com ([10.82.67.35]) with mapi id 14.01.0270.001; Tue, 01 Nov 2011 06:57:19 +0800 Date: Mon, 31 Oct 2011 22:57:18 +0000 From: h chan X-Originating-IP: [10.192.11.138] To: mext , "rute.sofia@ulusofona.pt" Message-id: <6E31144C030982429702B11D6746B98C1927D219@SZXEML505-MBS.china.huawei.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-language: en-US Content-transfer-encoding: 7BIT Accept-Language: en-US, zh-CN Thread-topic: [MEXT] Requirements of DMM Thread-index: AQHMkqj4VRCLKPw5n0KDwoB/mXv0HpWO5jxAgAgxcMA= X-MS-Has-Attach: X-MS-TNEF-Correlator: X-CFilter-Loop: Reflected References: <6E31144C030982429702B11D6746B98C1927B7F1@SZXEML505-MBS.china.huawei.com> <4F9AFA4F247D458BA29A91606B71716B@knucpl> Subject: Re: [MEXT] Requirements of DMM X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Oct 2011 22:57:42 -0000 A draft of requirements have been added to the problem statement document: Problem statement for distributed and dynamic mobility management Draft-chan-distributed-mobility-ps-04 This problem statement document is the joint work of my following co-authors and contributors: Dapeng Liu Pierrick Seite Hidetoshi Yokota Charles E. Perkins Melia Telemaco Elena Demaria Wassim Michel Haddad Hui Deng Seok Joo Koh Rute Sofia et al Anyone interested to contribute to the future versions are welcome. H Anthony Chan -----Original Message----- From: h chan Sent: Wednesday, October 26, 2011 1:20 PM To: 'Seok-Joo Koh'; mext Subject: RE: [MEXT] Requirements of DMM Seok-Joo, I agree that the distinguishing feature of DMM needs to be clarified, but I don't know whether we can call that local MM. If the first part of the sentence is taken alone: "The mobility management functions in interconnecting networks may be distributed over a number of smaller networks," One can possibly "disintegrate" into that in a number of smaller networks which support mobility independently. Then the MM in each network may or may not be local depending on which protocol is used. Yet if each network has its own HA using the host-based MIP, the range to which the MN can move is still global. The distinction of DMM is in the second part of the sentence: "and the mobility anchor for a session in a mobile node may be moved from one network to another network to avoid unnecessarily long route as the node moves." If seems that the problem of triangle route is of highest interest. I think Raj had emphasized on this problem in his draft. If we don't want limiting to "to avoid unnecessarily long route," we can add other things such as "to minimize traffic overhead." But then there are other things it can achieve. An example is to enable the capability to better support mobility in the flat network by having a mobility anchor closer to the access network to which the MN is attached, (as pointed out in Sri's email) An alternative is not to mention the advantage at all. The second part of the sentence will simply be "and the mobility anchor for a session in a mobile node may be moved from one network to another network as the node moves." The advantages can then be mentioned separately, but not part of the concise requirement statement. H Anthony Chan -----Original Message----- From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] On Behalf Of Seok-Joo Koh Sent: Monday, October 24, 2011 6:57 PM To: mext Subject: Re: [MEXT] Requirements of DMM Anthony, Good initiation for discussion. As for the Distributed MM, it seems that some people are still confused with "Distributed MM" and "Local MM". What is the difference between them ? In the current sentence, it seems that the objective of DMM is "for route optimization".. Does it include "minimization of the traffic overhead in the control and data plane ? I think it is helpful to clarify the following issues.. - Terms (or definitions) of Distributed, Localized, Dynamic.. - Route optimization, minimization of traffic overhead, resource utilization,... Regards, ************************* Seok-Joo Koh http://protocol.knu.ac.kr/ ************************* ----- Original Message ----- From: "h chan" To: "mext" Sent: Tuesday, October 25, 2011 2:42 AM Subject: [MEXT] Requirements of DMM > > There were discussions on the requirements of DMM in July. > > I think the email from Sri on the thread "LISP as a solution for some part of the DMM requirement" > (which is also attached below) has also elaborated the DMM requirements. > > Let me try to rephrase in the following: > > 1. Distributed mobility requirement: The mobility management > functions in interconnecting networks may be distributed over a > number of smaller networks, and the mobility support for a > session in a mobile node may be moved from one network to another > network to avoid unnecessarily long route as the node moves. > > 2. Dynamic mobility requirement: A network supporting a mix of > mobile nodes some of which may be stationary for extended time > while others may be actively mobile may optimize its resources to > avoid unnecessary mobility support. > > Comments please. > > H Anthony Chan > > -----Original Message----- > From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] On Behalf Of Sri Gundavelli > Sent: Monday, August 01, 2011 10:23 PM > To: Seok-Joo Koh; Charles E. Perkins; mext > Cc: dino@cisco.com > Subject: Re: [MEXT] LISP as a solution for some part of the DMM requirement > > With respect to the solutions, there are multiple approaches that are on the > table. To me, to achieve a flat distributed model, we need: > > - the ability to select a mobility anchor closer to the access network where > the mobile node is attached. 3GPP Rel-10 has done quite a few enhancements > on the aspects of gateway selection. Using the parameters eNB, APN, RNC-ID, > BSC-ID, ...etc > > - the ability to re-anchor a session, or create a new session on a new > anchor closer to the new attachment point > > - the ability to allow the mobile node to identify the assigned IP address > properties, distinguish between an address assigned in the previous access > network, from an address assigned in the current access network, so it can > continue to use the new address for new sessions and phase out the older > address/mobility session on the previous anchor over a period of time. In > other words, enhancing the SAS rules with mobility awareness will give the > needed session re-anchoring capabilities > > This approach gives me the gateway selection closer to the access network > where the mobile node is attached and the needed optimized routing path. So, > I'm trying to understand what are the expectation from the DMM efforts, > beyond this. > > > Sri > > > > > On 8/1/11 8:13 PM, "Sri Gundavelli" wrote: > >> Hi Charlie, >> >> I agree, we have to look at other approaches and bring any value added >> features to MIPv6/PMIPv6 protocols that its missing today. But, I've to say, >> I'm still trying to understand the DMM problem statement and what DMM should >> translate to: >> >> - Is it about optimized routing path ? This is very subjective and the >> requirement may vary based on the use-case. Very much depends on the placement >> of the anchor point. No solution on the table can ever solve this, unless we >> assume the target site where the CN is located, or the ISP above is providing >> some new location functions. This new location function, sure, can be a proxy >> home agent at the global internet level too, for the argument sake, providing >> direct path to the access network where the MN is currently attached. We also >> have talked some time back on the Global HAHA, as an approach of session >> re-anchoring. >> >> - Is it about moving from a centralized one box model to more distributed >> zillion box model ? This sounds very promising on the paper. But, as we >> discussed during the DMM BOF, rolling out a zillion pizza box type box anchors >> sounds very cool. Sure, but we bring back ten-fold complexity in the form of >> building distributed charging, Legal Intercept, DPI, Inline services, >> hotlining, high-availability ...etc etc, which are now part of that one >> central anchor box. It is to be noted, we have not seen a true distributed >> service deployed in the internet today, other than DNS. But, I agree, if this >> about building a true internet, who the heck cares about all of these >> functions, in the true spirit. >> >> Either way, I assumed any of the new solution will be bound by the following >> parameters: >> >> - The signaling protocol will continue to be based on MIPv6/PMIPv6 signaling >> semantics. >> >> - We will not introduce a new client, what is now MIP client struggling to >> make it to every variants of operating systems. >> >> - Any client-based solution will be an extension on top of DSMIP. Any >> network-based solution will be an extension to PMIPv6 >> >> >> >> I hope we can discuss the solution approaches in the next meeting and bring >> new extension to MIPv6/PMIPv6 protocols. >> >> >> >> >> Regards >> Sri >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> On 8/1/11 4:50 PM, "Seok-Joo Koh" wrote: >> >>> Dear Charles, >>> >>> I think the LISP can also be considered as a promising candidate >>> in the design of DMM solutions. Several works are being progressed >>> to use or extend the LISP for mobility support, which inlcude LISP-MN draft >>> and many research papers. Actually, I am also considering how to extend >>> the LISP scheme in the DMM perspective. >>> >>> LISP is a network-based ID-LOC separation scheme and thus it may give some >>> advantages for effective mobility support. On the other hand, it is noted >>> that >>> the current version of LISP and LISP-MN may need to be more enhanced >>> in terms of scalability in the mobile environment. For example, one concern >>> of >>> LISP >>> is that the LISP EIDs may not be aggregated anymore in the mobile networks, >>> since >>> each mobile node will have its own distinctive EIDs that do not conform the >>> concerned mobile domain. >>> This may decrease the scaling benefits of original LISP. >>> We may need to design a new enhanced EID structure to be used for mobile >>> environment. >>> Nontheless, it is worthwhile to consider LISP as a promisng candidate in the >>> disign of DMM, I think. >>> >>> By the way, as I already said in this IETF DMM ad hoc meeting, the urgent >>> action item of DMM is >>> to make one or more introductory I-Ds with WG consensus, which may include >>> the problem statements and requirements for DMM, use cases/scenarios, and >>> comparison matrix, etc. >>> >>> Regards, >>> >>> ************************* >>> Seok-Joo Koh >>> http://protocol.knu.ac.kr/ >>> ************************* >>> > > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext